SEKI (関, a checkpoint) · a2a-admission-v0

Before the agent acts, the door decides. Afterwards, anyone can check the door.

An AI agent asks to pay, order or change something under a contract both parties signed. The system it is about to act on runs one function first and gets one of three answers: admit, escalate to a named approver, or refuse. It signs that answer. After the act, settlement reads what was done against what was admitted, with the same public evaluator, and anyone can run that check.

What this is not. It does not issue identities and it is not a certificate authority. HORIZON SHIELD does not sit in the path of the action and stops nothing: the relying party runs the door on its own system, for its own resources. HORIZON SHIELD anchors the records it is sent and settles after the fact. It renders no verdict of its own.

The flow

Five steps, each one a record someone signed

01	Two parties sign a contract with a grant.	`a2a-contract-v0`: what the agent may do, what it may never do, what needs an approver, and optionally `grant.limits`, a maximum amount per action, inside the bytes both parties signed.
02	The agent asks before acting.	A signed action request: the action, the target, the amount, a nonce and an expiry height, bound to the contract by sha256.
03	The relying party's door answers.	`admit`, `escalate` or `refuse`, with a reason from a closed list. A request without what the door needs gets `403 application/problem+json` that says what to bring. Results the agent computed about itself are refused, not believed.
04	The door signs what it decided.	`a2a-admission-v0`, signed with a key served on the relying party's own domain. It names, by sha256, the clause evaluator it ran.
05	After the act, settlement checks both.	`settle v1.11` and `v1.12`: was there an admission, did it say admit, is what ran what was admitted, was the admission anchored before the act, was the amount inside the signed limit, and did the door wave through something outside the grant.

Why the two halves agree

One evaluator before the act and after it

A gate that says yes before the act and an audit that says no afterwards would tell the relying party something false. So the door and the settlement read the grant with the same file, clause_eval_v0.py, which is public. Every admission record carries that file's sha256, so a reader can see which reading was applied.

limits

A limit lives in the grant both parties signed, never in what the agent presents. An approval does not lift it.

revocation

A revocation signed by the principal is obeyed by the door even before it is anchored. Refusing is the safe direction.

replay

Each admission is bound to one action digest and one nonce. Running something else under it, or running it twice, is a deviation.

existing contracts

A contract without an admission requirement and without limits settles byte for byte as it did before (the first settled execution run0002, the outside parties' contract d7118f28, and the 18 scenario corpus).

Check it yourself

The record is public. The door is not.

The implementation of the door is not published. The record format, the evaluator, the settlement and a verifier are, so that nobody has to trust the operator of the door, or us.

pip install "nenrin-verify>=0.5.2"
musubi-verify admission_verify_v0 --selftest
musubi-verify settle_v1_12 --selftest

The record, and how to check it JSON Schema MUSUBI, the contract layer it sits on

Limits

What an admission record does not show

Stated at the same size as the claim.

✗Not that the agent is who it says it is, beyond what the presented signatures and keys on its own domain show.
✗Not that the action was lawful, safe or wise. Only that it was inside or outside the grant both parties signed.
✗Not that a revocation published after the door's view of the chain was known. The record says which revocations the door saw and whether each was anchored.
✗Not a legal authorization, and not a finding of liability. It anchors facts by which others may judge.
✗Not yet any identity format other than a signed MUSUBI contract. Other formats are read only once they can be checked against their issuer's own fixed test vectors. Until then they are reported as unverified, and the door does not admit on them.

Putting a door in front of your system

Talk to us

The door runs on your side, in front of your own API or MCP tools, in Python or JavaScript. We set it up with you and operate the anchoring and the after-the-fact settlement. What is charged is the work of recording and checking. Nothing is charged as a share of a transaction, and nothing depends on whether an action is admitted. Write to contact@the-horizons-innovation.com.