Authorize the effect, not just access to the tool.
Access control limits what software can reach. Execution Authorization bounds the exact effect it may cause. Action Proof is the protocol that produces the verifiable chain: a signed, single-use grant for one canonical operation, enforced at a point you control, and closed with evidence anyone can check offline.
Cryptographic proof of authorization. Signed evidence of execution outcome. An Execution Grant proves what was authorized; an Action Receipt preserves signed evidence of the outcome the enrolled Guardian was able to establish.
Cloud authorizes, your Guardian executes
Tenant-scoped keys, least-privilege credentials
Signed receipts, verifiable offline
POST https://mcp.securestamp.online/mcp
Authorization: Bearer ss_live_...
{ "jsonrpc":"2.0", "id":1, "method":"tools/list" }Access is not authorization to act
Access to the payment processor is not the same as authorization for a specific refund.
Access
Agent may call the payment processor's refund APIs
Execution Authorization
refund.create charge ch_89172 amount USD 1,427.00 destination original_payment_method maxUses 1 expires 14:02 UTC
Resource authorization answers what a principal may access. Execution Authorization answers what transaction-specific effect it may cause. Fine-grained access still leaves the transaction itself undefined: which resource, which amount, which destination, how many times.
Three steps
Define
What exact effect is being requested? The Guardian — not the model — reads provider state and normalizes it into a canonical operation with explicit parameters.
Authorize
Bind that effect to a signed, single-use Execution Grant inside your policy, at the authority the protocol demands for that operation.
Verify
Execute at a point you control and keep a signed Action Receipt that recomputes offline.
read_message_request
Returns what a message is asking for, from signals only. Message bodies never leave the device.
analyze_message_intent
Maps abstract signals to sensitive action intents. Signals only; no raw message text.
verify_counterparty
Checks whether a sender or counterparty matches the tenant registry.
get_safe_next_step
Computes the safest next step from declared registry facts.
authorize_action
Returns an Action Verdict, Safe Next Step and receipt before a sensitive action.
create_action_challenge
Creates a manual dual-control challenge for a known counterparty.
issue_action_receipt
Issues a signed Action Receipt for already-computed facts.
get_source_envelope
Retrieves the device-signed envelope that a human actually saw and approved.
request_execution_grant
Requests a single-use grant to execute one exact effect. Returns a HOLD until the required human or quorum authority approves.
get_execution_status
Reports where an execution stands, including outcomes that are still genuinely undetermined.
Execution layer
The grant is not permission to improvise
An Execution Grant is bound to one effect digest and to the policy version in force, expires, and can be used exactly once. Your Guardian re-reads provider state immediately before mutating, claims the grant against its own ledger, and signs the outcome — including outcomes that are ambiguous. A replayed grant never reaches a provider.
- Grants are single-use and bound to one exact effect digest. maxUses is 1, always.
- The required authority is fixed by the protocol; a caller cannot downgrade it.
- Every privilege grant requires M-of-N quorum, and the requester can never approve their own request.
- Quorum profiles are signed policy snapshots, not authority values: the proof relies on the threshold, the approver roster and the policy hash.
- Outcomes are succeeded, failed_no_effect or indeterminate — ambiguity is never rounded up.
- Proof bundles verify offline, with no call back to SecureStamp.
Parable 3
The agent pauses before changing an account
A workflow receives a vendor bank-change request. Instead of updating the account, it calls authorize_action through the remote MCP Guard with a hash and abstract signals. SecureStamp returns needs_confirmation and a Safe Next Step: challenge the counterparty. Nothing executes until a human answers.
The agent detects a sensitive action
It identifies a bank-account change and sends only structured signals plus a sourceMessageHash.
SecureStamp checks tenant facts
The API key scopes the lookup to one owner graph, declared policies, and registered instructions.
The agent receives a verdict
The response is a decision record with Safe Next Step and receiptId, not permission to execute.
Humans or counterparties confirm
If needed, create_action_challenge opens a manual confirmation path before the operation proceeds.
Local authorization ceiling
Cloud authorization is necessary, but never sufficient on its own.
A grant only becomes an execution if it also fits the policy your organization signed and installed beside the Guardian. That policy is deny-only: it pins tenant, gateway, operations, adapter manifests, accepted authorities and policy versions, resources, parameters, monetary limits, concurrency and network destinations. Production mode refuses to start without one.
effective permission =
cloud grant
∩ signed local policy
∩ adapter constraints
∩ kill switchesSecureStamp Cloud can make an authorization narrower. It cannot make it broader than what your organization allowed locally.
Contracts
What the verifier recomputes
ExecutionGrantV1The authorization artifact. Carries the effect digest, the authority, the policy version (apol_v1:) and the expiry. maxUses is 1.
ActionReceiptV2 / V3The evidence artifact. V3 adds the policy version and the digest of the signed local policy (gpol_v1:) that bounded the execution. V2 stays byte-compatible for history.
ActionProofBundleV1 / V2Everything a third party needs to recompute the chain. V2 adds the signed local policy and the connector assurance descriptor.
AdapterManifestV1A self-contained, immutable descriptor of one connector operation. The verifier checks the manifest in the bundle instead of regenerating it, so new operations never invalidate old proofs.
Verify a receipt offline
The verifier is a separate published package with no network access, and it ships ahead of the artifacts it verifies. Receipts can be verified offline without contacting SecureStamp, and verification does not depend on a live SecureStamp service.
npx --package @securestamp/action-proof-verify action-proof-verify bundle.json
Evidence boundaries
An Action Receipt proves what passed through an enrolled Guardian and the outcome that Guardian could establish. It does not prove that no action occurred outside SecureStamp, nor does it establish legal ownership of the provider account. The evidence boundary is the enrolled execution path.