Authorise every agent payment before execution. Prove every decision independently.
Inntris evaluates the exact proposed payment against your organisation’s current policy before execution. It allows the payment, blocks it or requires human approval — with signed evidence bound to the exact action.
The payment rail records that money moved. Inntris records the policy decision that allowed or prevented it.
- Exact-action binding — The decision is tied to the amount, asset, recipient, purpose and relevant payment-protocol requirements.
- Policy before execution — Limits, approved recipients, cumulative spend and approval requirements are evaluated before the rail is called.
- Independent evidence — Signed receipts can be checked outside the system that produced them.
- Rail-independent control — Inntris does not hold funds, issue wallets or replace the payment provider.
Decision and receipt signing
Execution pattern
Evidence-pack anchoring
Public x402 reference
The problem
A valid payment credential does not prove a valid payment decision.
An agent may authenticate correctly and still exceed a limit, pay an unapproved recipient, reuse stale authority or act after company policy has changed.
A settlement record proves that the rail processed the payment. It is not the same as a portable record of the organisation’s policy decision immediately before execution.
The credential is valid
The agent has access to the payment API, wallet or card credential. Authentication has succeeded, but the exact payment has not yet been evaluated against organisational policy.
The decision is time-sensitive
Limits, recipients, approval state and policy versions can change between an initial request and execution.
The consequences are immediate
Once money moves, an after-the-fact log can explain the event. It cannot retroactively authorise it.
Reconstructing authority after settlement is not the same as proving it before settlement.
How Inntris works
One independent decision point before the payment rail.
Inntris sits between agent intent and the execution boundary. It evaluates the exact proposed payment, records the result and provides evidence the executor can check before allowing the rail to proceed.
Inntris does not hold funds, issue payment credentials, sign payment transactions or settle payments. It decides and proves; the payment rail executes.
Agent payment protocols
One organisational policy layer across emerging agent-payment protocols.
Inntris publishes reference implementations built against pinned official protocol SDKs and types. The x402 adapter also validates payment objects using the official runtime schemas.
Exact-payment authorisation
The decision binds the proposed payment to the x402 payment requirements it answers. Changing the amount, recipient or payment challenge changes the binding and causes the guard to refuse settlement.
Public MIT Phase 1 reference implementation
Verified mandate, current company policy
The reference gate verifies the merchant checkout and open mandate constraints, then applies the organisation's current policy. A valid protocol mandate cannot override a company-policy block or approval requirement.
Public follow-on reference package
Settlement finality before delegation
The reference gate binds the payment to the A2A task and requires a verified approval plus confirmed settlement finality before one delegated execution can proceed.
Public follow-on reference package
An approval does not rewrite an old decision.
A human-approval-required result remains immutable and cannot reach settlement. When the human responds, Inntris re-evaluates the action against the policy that is current at that moment and issues a new signed result that supersedes the original.
A stale human “yes” cannot override a limit or policy that has since changed. A refusal produces a signed block with a recorded reason, and resolution is single-use.
Verdict names in the reference implementation
Decision envelopes emit ALLOW, BLOCK and REQUIRE_APPROVAL. These are the literal values in the signed artifact and in the public verifier output.
The market shift
Agent payments are becoming a protocol layer.
x402 activates HTTP 402 for programmatic, machine-to-machine payments, including payments initiated by AI agents.
Google launched the Agent Payments Protocol in September 2025 as an open, payment-agnostic framework that uses cryptographically signed mandates to represent a user’s instructions and an agent’s authority to transact. Google donated AP2 to the FIDO Alliance in April 2026 and released AP2 version 0.2 with support for autonomous, human-not-present transactions.
Visa and Mastercard are introducing payment infrastructure for recognised agents, tokenised credentials, user consent, spending conditions and agent-initiated transactions.
OpenAI and Stripe released the Agentic Commerce Protocol as an open standard in September 2025, defining how an agent completes checkout against a merchant it does not own — while the merchant remains merchant of record and retains responsibility for accepting, processing and fulfilling the order.
As agent-payment execution becomes easier and more standardised, enterprises still need their own portable answer to one question:
Was this exact payment authorised under our current organisational policy?
Inntris is designed to provide that answer across agents, execution environments and payment rails.
Sources: x402 documentation; Google AP2 announcement, 16 September 2025; Google and FIDO Alliance AP2 v0.2 announcement, April 2026; Visa Intelligent Commerce and Trusted Agent Protocol; Mastercard Verifiable Intent and Agent Pay for Machines; OpenAI and Stripe Agentic Commerce Protocol, 29 September 2025. Verified 31 July 2026.
Live verification receipts
One allowed request. One blocked request.
Both receipts are live, signed platform records for financial-transaction requests. Each shows the policy decision applied before the proposed action was allowed or blocked.
Amount $750.0 exceeds per-action limit of $100.00.
The payment request was blocked and the receipt records the verdict and policy reason.
Agent
Corporate Card Agent
Inntris Card Demo
Action
financial_transactionSignature
Valid Ed25519
Anchored on Base L2
Receipt ID
975151ca-834e-4919-9ef6-d9e80803e5f1Generated 36 days ago · 2026-07-22 15:43 UTC
All verification checks passed
The receipt records the agent, action, policy result and cryptographic proof.
Agent
Corporate Card Agent
Inntris Card Demo
Action
financial_transactionSignature
Valid Ed25519
Anchored on Base L2
Receipt ID
65cc4da3-3774-495d-9748-865a7ff98d40Generated 36 days ago · 2026-07-22 15:43 UTC
What the receipt proves
The agent request was cryptographically signed.
The policy verdict and reason were recorded.
The receipt is protected by its fingerprint and policy hash.
The receipt was included in a Merkle batch anchored to Base L2.
The receipt proves the recorded Inntris decision. Settlement confirmation remains the responsibility of the external payment rail.
Verify without trusting us
Separate proof artifacts. Separate public verifiers.
Verification that routes through the company producing the evidence is circular. Inntris publishes both verification paths outside the production service so it never has to.
Artifact 01 · Evidence pack
Evidence packs
What it verifies: the signed pack manifest, every file hash in both directions, receipt fingerprints, agent signatures and Merkle inclusion proofs. An optional check queries a Base mainnet RPC node chosen by the verifier.
Properties
- Python 3.10 or later
- Standard library only — nothing to install
- No Inntris endpoint, library or account required
- Single file, auditable in one sitting
Artifact 02 · Decision envelope
Payment decisions
What it verifies: the decision schema, fingerprint, Ed25519 signature, action hash, action binding, expiry at a supplied execution time, policy version and payment-requirements binding.
Properties
- Offline by default
- No Inntris account required
- Makes no network request unless a key registry URL is supplied explicitly
A verifier is only as independent as the key it checks against.
Signing keys are published in two independently controlled channels: the verifier repository and inntris.com/.well-known/inntris-keys.txt. Pin the key from one and cross-check it against the other. An attacker must compromise both to substitute a key.
Without a pinned key, a signature proves the artifact is internally consistent — not that Inntris produced it. On any discrepancy between the two channels, treat verification as failed and contact sales@inntris.com.
Key registry and reportingAn evidence pack and a decision envelope are different artifacts with different verifiers.
The evidence-pack verifier does not verify decision envelopes. The decision verifier does not verify evidence packs. Neither one substitutes for the other, and we do not claim otherwise.
Additional use cases
Payments first. Every consequential agent action next.
Payments are the first product because errors are immediate, financial and difficult to reverse. The same pre-execution policy model can govern other actions an organisation should not allow an agent to take unchecked.
Code and CI/CD
Require a policy decision before repository changes, CI/CD edits, protected-branch merges or production deployments.
Sensitive data
Gate customer-data access, bulk exports, PII reads and cross-boundary transfers before the query or export runs.
Administration and infrastructure
Control permission grants, production configuration, resource provisioning, key rotation and destructive operations.
APIs, tools and communications
Apply policy before external API calls, MCP tool execution, outbound emails and other actions that affect third-party systems.
Start with agent spend. Expand along the organisation’s risk surface using the same agent identity, policy model and evidence layer.
Operate and prove
One control layer. Four operating surfaces.
Admin Console
For platform and security teams
Manage agents, policies, credentials and approval boundaries from one place.
Explore ConsoleAgent Portal
For developers and operators
Register agents, test policy evaluation in the sandbox and inspect policy outcomes.
Explore PortalAudit Explorer
For investigations and compliance
Search verification records by agent, action, time and verdict, then inspect their integrity evidence.
Explore Audit ExplorerPublic Verify
For customers, partners and auditors
Share a receipt link so another party can inspect its signature, policy hash and anchor evidence.
Verify a receiptIndependent by design
The party executing a payment should not be the only party proving it was authorised.
Payment rails provide settlement, fraud controls and network evidence. Model and agent platforms provide execution environments. Identity systems establish who or what is acting.
Inntris adds the organisation’s transaction-specific policy decision immediately before execution and produces evidence that can travel beyond any one platform.
Rails and agent platforms will keep adding native controls, and should. What they cannot produce is a neutral record of your policy decision that holds up outside their own boundary. Inntris complements the rail, the model provider and the identity stack — it is simply not one of them.
Published boundaries
The public implementation is a reference architecture, not evidence of HSM custody, distributed spend accounting or production performance. AP2 and A2A are public reference packages rather than hosted production integrations. Review the complete limitations in our technical documentation.
Full limitationsDesign-partner pilot
Start with one agent payment workflow.
In 14 days, Inntris instruments one high-risk agent-payment workflow with a defined policy boundary and verifiable evidence for approved and blocked actions.
Fixed scope. One workflow. Clear production recommendation.
Pilot deliverables
- One agent-payment workflow mapped and instrumented
- Agent identity and policy boundary configured
- Approve, block and human-approval-required paths tested
- Fail-closed enforcement at the execution boundary
- Verifiable evidence for each policy result
- Pilot findings and production-rollout recommendation
Get in touch
Talk to us about an agent payment workflow.
Tell us what the agent can pay for, which system executes the payment and which limits or approvals must be enforced.
Whether you're exploring a design-partner pilot, verifying a receipt, or working out how Inntris fits in front of your payment rail, this is the address.
Commercial, technical and security
sales@inntris.comResponse time
Within one business day
Design-partner and technical enquiries are answered within one business day.
Design partners, technical questions, security reports and key verification: sales@inntris.com