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 undefined: which resource, which amount, which destination, how many times.
How it works
Define
What exact effect is being requested? It is normalized into one canonical operation with explicit parameters, read from provider state rather than from the model.
Authorize
That effect is bound to a signed, single-use grant, at the authority the operation requires and inside the policy you signed.
Verify
Execution happens at a point you control, and closes with a signed receipt that recomputes offline.
What you get
Exact-effect control
Software never receives open authority. One effect, one authority, one expiry.
Your policy is the ceiling
SecureStamp can narrow an authorization. It cannot make it broader than the policy your organization signed and installed locally.
Credential isolation
Provider credentials stay in your environment. SecureStamp Cloud does not receive downstream provider credentials.
Single use
A grant never becomes a reusable permission. A replayed grant is rejected before any provider is contacted.
Verifiable evidence
Protected executions produce a signed evidence chain describing what was authorized and what outcome could be established.
Independent verification
Receipts can be verified offline without contacting SecureStamp. Verification does not depend on a live SecureStamp service.
Unknown stays unknown
An ambiguous provider response remains indeterminate until reconciliation. Mutating operations are not blindly retried.
Works with what you have
It does not replace identity, policy engines, approval workflows or provider APIs. It binds their approved decisions to exact executable effects.
When Execution Authorization matters
This is a control proportional to risk, not a tax on every tool call. It earns its place when an action has any of these properties:
- It is irreversible or costly to reverse
- It moves money
- It changes privileges
- It modifies infrastructure
- It produces external effects
- It affects multiple resources
- It requires approval or quorum
- It has regulatory consequences
Read-only or low-impact actions may not need execution authorization at all.
Connect an agent
The MCP service is remote and always on. Point any MCP-compatible client — Claude Desktop, Cursor, your own agent — at the endpoint with an agent-kind API key from your dashboard.
POST https://mcp.securestamp.online/mcp
Authorization: Bearer ss_live_...
{ "jsonrpc": "2.0", "id": 1, "method": "tools/list" }Every guard call consumes one protected action from your plan quota. Read-only proof and status tools do not.
What your plan includes
A protected action is one successfully evaluated SecureStamp guard call, billed against your monthly quota. Auth failures, invalid requests and rate limits are never billed.
See plans and quotasEvidence 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.
The protocol
Action Proof is the protocol that produces the verifiable chain. Its specification, contracts and offline verifier live on the foundation site.
Read Action Proof