Enforcement
A notary only matters if the work actually stops to use it. AGLedger is built to sit in front of consequential automated actions — buying hardware, provisioning a user, moving funds — so the record is a precondition of the work, not a hope about it. A gate in front of your systems makes the agent clear AGLedger before the action runs.
One thing to be clear about: the gate is yours — your own policy engine, or an agent-governance toolkit. AGLedger never blocks your systems; it holds the signed record the gate checks. “Fail-closed” is a policy you set at that gate, not something AGLedger does to you. AGLedger the service only ever records.
No record, no action · Validated, not just present · Fail-closed by default
Last updated: 2026-06-03 · API v0.27.2
Why before, not after
A log records what happened. It cannot record what was meant.
After-the-fact logging captures the action. It cannot capture what the agent meantto do, or whose authority it claimed — because by the time you ask, the agent has lost the context and will reconstruct a plausible story that may never have been true. Intent and authority are only honest when they are signed at the moment they are real: before the action. Capture them afterward and you have recorded half the story and made up the other half.
That is why a record carries more than the action. It names what was intended, and who stands behind it — the principalAgentId accountable for the work and the requestedBy human or upstream system that asked for it — signed before the consequential step, not narrated after it.
How a gate enforces it
No record, no action
A gate in front of your systems — your own policy engine, or an off-the-shelf agent-governance toolkit — intercepts the consequential tool call and refuses it until a valid record exists. The rejection is not a dead end; it is a directive the agent can act on.
- The agent calls the tool — buy the laptop, add the user — with no record.
- The gate finds none and returns the directive above.
- The agent discovers the API, learns the contract type, and notarizes what it intends and on whose authority.
- It retries the tool call, now carrying the record ID.
- The gate validates that ID against AGLedger — not just that a string is present — and only then lets the action proceed.
An agent with no prior knowledge of AGLedger completes this loop on its own, taught entirely by the gate directive and the API's own responses. See the full first-contact trace in the agent-governance-toolkit walkthrough.
Validate, do not just check for presence
An agent will fabricate any string you only check for presence
If the gate only checks that a record ID fieldis filled in, an agent under pressure to complete its task will invent one that satisfies the requirement. The gate has to confirm the record actually exists, against the AGLedger API, before it trusts it. It is a single read — on the order of 50 to 200 milliseconds, negligible against model inference — and it is the difference between a control and a checkbox.
Fail-closed by default
If AGLedger is unreachable, the action does not run
When the gate cannot reach AGLedger to validate a record, it has to choose: block the action (fail-closed, safer) or allow it (fail-open, more available). The reference implementation fails closed — the consequential step waits rather than proceeding unrecorded. Configure it to your own risk tolerance, but the default is the one that keeps the trail complete.
The record is also for the agent
A mandate that outlives the memory of it
The same signed record the gate enforces is something the agent can read back. When an agent loses context — a reset, a hand-off, a fresh session picking up long-running work — it does not have to remember what it was doing. It reads its records and recovers what it was required and authorized to do, byte-for-byte, signed. Conversation history evaporates; the chain does not. The constraint the agent agreed to before the action is still there to be read after it.
The decision stays yours
The gate enforces. AGLedger holds the record. We are not the judge.
AGLedger does not decide whether your agent may act. The gate enforces the policy; your principal, or your rules engine, renders the verdict; AGLedger holds the signed record of both the intent and the decision. Where the action crosses a delegation boundary and someone other than the doer must accept or reject the delivery, that verdict path is the Gate. The enforcement point is how you make reaching it mandatory.
Two ways to put a gate in front
Your own policy engine
A thin check at the point an agent invokes a consequential tool: does a valid AGLedger record exist for this action? Reject and return the directive if not; validate and proceed if so.
An agent-governance toolkit
Already running a governance layer? A small adapter maps its policy decisions to AGLedger records and enriches its denials with the retry directive — no system-prompt changes. See the integration walkthrough.
Related