What you can use today
- Authorization of one exact effect, live now through the MCP service: one operation, one authority, one expiry, one use.
- Signed evidence of what was authorized and what the Guardian could establish, verifiable offline with no account.
- Six provider operations, each at an authority the protocol fixes and a caller cannot lower.
What a mandate fixes
Five questions, answered before the agent starts.
A delegation you cannot read is a delegation you cannot revoke. The contract turns it into an artifact: five axes, all explicit, all signed together.
What may change
Each step names one canonical operation and the exact parameters bound to it. Not a capability, not a scope, not a category of action — one effect, identified by digest.
Over which resources
Steps carry their resource list. A step approved for one account, one role or one customer does not carry over to another, and the Guardian rejects the mismatch before the provider is contacted.
For how long
The contract has an issue time and an expiry. After it, no new step is sent — there is no grace window and no renewal from inside the task.
Under which approvals and budget
Authority is set per operation by the protocol, not chosen by the caller. The budget is durable and atomic per tenant, task, revision and step: committed means consumed plus anything reserved and still uncertain.
How the result is checked
The adapter reads the provider back to establish what happened. A timeout is reconciled, never retried blind, and an ambiguous outcome stays indeterminate instead of being rounded up to success.
How it runs
Review
A person reads the mandate: the steps, the resources, the window, the approvals and the budget. Nothing runs while it is a draft.
Approve
Approval fixes a revision. Changing any step produces a new revision to review — an approved contract is never edited in place.
Run inside it
The agent proposes steps. Each one still produces its own single-use Execution Grant and its own Action Receipt. Anything outside the contract is refused.
The limits, stated plainly
What a mandate does not do.
It never lowers an authority threshold
Approving a mandate does not turn a step that needs MFA or quorum into one that does not. Authority is set per operation by the protocol; a longer task does not buy a cheaper approval.
There is no subdelegation
One mandate, one Guardian, one budget. An agent inside a contract cannot hand part of it to another agent, and a task cannot spawn a second execution point.
What it reads cannot widen it
Documents, tool output, web content and memory are inputs, never authority. An instruction found inside content the agent read is data — it does not extend the contract, whatever it claims.
A signed mandate can still be a harmful one
Authorization is not proof of truth, benignity or correctness. A contract bounds authority; it does not establish that approving it was a good idea.
Who this is for
The person carrying the risk is usually not the one who approved the task.
When an agent issues a refund, changes someone's access or edits infrastructure, the consequence lands on a customer, a colleague or a third party who was never in the room. A mandate is worth having because they can read it too: what may change, over which resources, for how long, and what happens if it goes wrong. A limit only the vendor can inspect is a limit that protects the vendor.
SecureStamp reads what an action is asking for. It does not judge whether the person asking is right, it does not decide which content is true, and it requires no professional credential to use. Bounding what software may cause is not the same as bounding what anyone may say.
Budget
A security budget is not billing. It is durable and atomic per tenant, task, revision and step — not a counter in memory and not one per agent. Committed means consumed plus anything reserved whose outcome is still pending or uncertain, so the same grant can never reserve twice. If storage or revocation is unavailable, no new effects are sent.
States
A task is always in exactly one of these, and the transition is what the ledger records.
- draft
- approved
- running
- paused
- completed
- revoked
- expired
What the local reader does, and does not
A local reader explains what a request is asking for. It does not authorize, and in this profile an isolated finding, an abstention or a partial read does not block, revoke or force extra approvals on an effect that was already approved and is within the contract. It is rule-based over a bounded amount of text, so truncation and non-evaluation are shown rather than hidden. Absence of a finding is never permission — an out-of-contract effect is refused whether or not the reader saw anything.
Evidence boundary
An Action Receipt proves what passed through an enrolled Guardian and the outcome that Guardian was able to establish. It does not prove that no action occurred outside that path, and it does not establish legal ownership of the provider account. Threats outside the guarantee are named rather than implied: the host administrator, a compromised Guardian or signer, actions taken outside the enrolled path, an unobserved side channel, and harm the mandate itself already permitted.
Status
This page describes a design. The contract schema exists and its limits are enforced in tests; execution of a delegated mandate against a real provider has not been evaluated, and until it is, this profile is labelled simulated. We do not extrapolate a result from a mock or from a different connector, and approval fixtures are not real MFA or quorum.
The specification
Contract fields, canonicalization, the binding between mandate, step and effect, the state machine and revocation are specified on the foundation site.
Read the specificationAlready available
Single-effect authorization — one exact effect, one authority, one expiry, one use — is live today through the MCP service.
See Execution Authorization for agents