Subra
Lifecycle activePayments Operations AgentAccountable ownerPayments Operationspayments.initiatePermanent AIN01AR Z3ND EKTS V4RR
Subra binds each consequential action to the identity presented, the organisation, the accountable owner, the declared scope, and the policy and model versions in force - then produces signed evidence that can be checked independently later, by someone else.
The identifier never changes. The scope and the accountable role do. Earlier versions are kept, so what the agent was allowed to do last March is still answerable.
Portable agent identity
Move through signed identity records for operational agents. Each card keeps ownership, declared scope and a permanent AIN bound together.
Payments Operations Agent selected
Identity, authority, ownership, policy and model versions often live in different systems. Runtime logs show what happened, but not always what the agent was authorised to do.
Held by IAM or an agent protocol.
Stored in policies and approval records.
Model and policy versions change over time.
Often a role maintained in a spreadsheet.
Logs show what happened, but may not prove the authority relied upon.
Audit teams assemble these fragments manually after the event.
Subra doesn't replace the systems you already use to establish identity and authority. It sits alongside them, and turns each completed action into a signed record.
MechanismAccepts the identity already presented via ARIA, DID/VC, OAuth/OIDC or your enterprise IAM.
MechanismResolves the organisation, named owner and declared scope.
MechanismCaptures the completed action and its stated intent.
MechanismBinds the policy and model version snapshot at the time of action.
MechanismIssues a signed, tamper-evident receipt.
MechanismReceipts assemble into evidence packages, re-verifiable at any later point.
Compatibility
ARIA, DID/VC, OAuth/OIDC and enterprise identity systems establish how an agent presents itself. Subra sits alongside that layer. It doesn't compete with it, replace it, or ask you to adopt something new in its place.
External identity and control
Subra
Independent use
The action receipt
Every action produces a receipt like this. Human-readable first, with the underlying cryptography available one layer down for anyone who needs to check it.
Subra
Action receiptCompleted action
Stated intentSettle approved invoice INV-2048 for £18,450.00
sha256:5bc14f79d31e472bc71af26c3c8a75f3bff847e2d494597aa4fd41c690b2e118sha256:8d42e58e93bf0c87c9909f7988d2e01c6ce2d7d5bc0a2d87cb2b0f617a8d09c4kid:subra-example-receipts-2026-07Evidence packages
A package brings the identity, accountability, scope, receipts, versions and verification results for a given period into one signed manifest. It is reviewable on its own, without needing access to Subra.
Request private previewPayments operations
The package connects the accountable context and versions in force to every included action receipt for the selected period.
Integrity
A record you can argue with is not evidence. Each receipt is linked to the one before it. Changing any field breaks the chain, visibly.
Independent chain check
Payments operations · 24 July 2026Test the evidence yourself.
Change the payment amount in record 2 and watch the verifier recalculate the chain.The same fields are always placed in the same order and format, so the same record always produces the same result.
Each formatted record is converted into a unique digital fingerprint and includes the fingerprint of the record before it.
The fingerprint is signed by Subra. An independent verifier can check who signed it and whether it has changed.
Verification recalculates the record. Nothing is simply trusted from storage.
Where this applies
Three examples of the high-stakes workflows Subra is designed for, organised by the action taken, not by industry vertical.
Thirty minutes is usually enough to see where your agents sit against this.
Security and boundaries
Subra is built to record the minimum evidence necessary, not to become a second copy of your operational logs.
Subra records the identity, accountable context, action, scope result and versions needed to explain an action. Customer payloads are excluded by default.
Select any statement to inspect its boundary in context.
The identity presented, the organisation, the accountable owner, the action and its intent, the declared authority and scope result, the policy and model versions in force, and a signature over the whole record.
Yes. Verification recalculates the record from its contents rather than trusting a stored result. Evidence packages are designed to be checked independently, including when the originating system is unavailable.
Scope result is a classification recorded on the evidence, "inside declared scope" or "outside declared scope", not a decision Subra makes about whether the action is allowed to happen.
The change is recorded as a new version. Historical receipts remain bound to the version that was in force when the action occurred.
No. Subra accepts the identity your systems already present through ARIA, DID/VC, OAuth/OIDC or your enterprise IAM, and builds accountability and evidence around it.
No. Subra is never a required dependency for an agent to act. It records evidence after an action has occurred.
The minimum evidence necessary for the record, including identity references, accountability, scope, version and receipt data. Runtime logs are referenced by pointer, not copied in.
No. Subra produces evidence intended to help your organisation answer accountability questions. It does not certify compliance and is not a regulator.
We're working with a limited number of regulated organisations that operate real AI-agent workflows and need stronger evidence around authority, accountability and actions.