Agents need a signature, not just a scope.
OAuth scopes prove an agent is allowed to call an API. They don't prove that a human freely consented to this specific action, in this specific scope, at this specific moment. As AI agents start to pay invoices, execute trades, and move money on a user's behalf, banks and regulators need portable cryptographic evidence that the underlying human consent was real, in scope, and not the product of prompt injection or account compromise. RTScale's SoM Signature is that evidence — bound to the moment of delegation, carried through every downstream call the agent makes.
The agent has permission. Does the user have a record?
Existing agent-to-API plumbing was designed for read-mostly workloads, not consequential financial action. Three gaps surface the moment money starts to move.
Scope without consent provenance.
OAuth tokens prove the agent is allowed to call the API. They prove nothing about the human's underlying state of mind when delegation was granted — whether consent was freely given, freely scoped, or even given at all. Cap-and-scope tokens are a permission model, not an evidence model.
Prompt injection at the action layer.
Agents read documents the user didn't write — emails, invoices, files, web pages. A malicious invoice can redirect a payment to the wrong account. The bank sees a legitimate API call from a credentialed agent. The user sees a fraudulent transfer. There is no record of what the human authorized vs. what the agent inferred.
Audit-trail blindness when things go wrong.
Today's audit trail for an agent action shows API calls and timestamps. It does not show the moment of delegation — what the user said, in what state, with what understanding. Five years from now, when a regulator asks "how did this $50,000 payment get authorized," the answer cannot be "trust me, the OAuth token was valid."
Agent has the keys. No one has the receipt.
Agent acts on a valid OAuth token. If the user disputes the action, the only evidence is application logs. If prompt injection redirected the payment, the logs show a legitimate-looking API call. The bank's liability is unclear; the customer's recourse is slow; the regulator's question is unanswerable. Each side has plausible deniability and zero shared evidence.
Agent carries cryptographic proof of consent.
The signature binds the moment of delegation — affective state, scope, TTL, agent identity — into a hardware-attested artifact. Every downstream call carries it. The bank verifies it. The regulator can re-verify it offline, years later. One shared evidence record. Disputes have data.
How the signature travels with the agent.
A user delegates monthly invoice payments to an AI financial assistant. The agent processes the queue, hits a scope boundary, and the system handles re-authorization without breaking the flow.
did:agent:abc · provenance: clear consent.
Sealed 402 step_up_required with the specific mismatch detail.
Step-up required A signature an agent can carry, a bank can verify, a regulator can replay.
The Authorization class extends the SoM Signature with scope, time-to-live, and agent binding. Everything an agent's runtime needs to forward, and a bank's fraud platform needs to verify.
"class": "authorization",
"scope": {
"action": "payment.ach",
"payee_did": "did:legal:us:acme-construction-llc",
"amount_cap": { "value": 10000, "currency": "USD" },
"call_limit": 5
},
"time": {
"issued_at": "2026-05-12T14:23:18Z",
"expires_at": "2026-05-13T14:23:18Z"
},
"binding": {
"agent_id": "did:agent:fin-assistant-v2:abc123",
"principal_id": "did:human:pseudo:xyz789" // pseudonymous
},
"provenance": {
"capture_class": "deep_scan_30s",
"consent_clarity": "clear", // decomposed indicators in /provenance.full
"hardware_root": "secure_enclave",
"attestation": "apple.aaguid:..."
},
"signature": {
"alg": "EdDSA",
"sig": "MEUCIQDq2...", // signed by Secure Enclave
"chain": "[device_attestation, tenant_ca, rtscale_root]"
}
}
Scope
What actions the signature authorizes. Specific payee, action type, amount cap, call limit. Banks verify on every downstream call, not just at delegation.
Time
Issued-at and expires-at, plus call-counter exhaustion. Narrower TTL for narrower scope; broader TTL for routine batches. The agent cannot extend either.
Binding
Bound to a specific agent identifier and a specific principal. A leaked signature cannot be replayed by a different agent. A compromised agent cannot reuse another principal's signature.
Provenance
Decomposed affective indicators at the moment of delegation, hardware-attested. A reviewer or regulator can read consent clarity offline, years later, without re-deriving from raw biometrics.
Framework-agnostic. SDK-mediated. Standards-tracking.
The signature is a payload, not a framework. RTScale provides agent-side SDKs and bank-side verification libraries; the rest is your stack's plumbing.
Agent-side SDK · call getSoMSignature(scope, ttl)
Drop-in for any agent framework that supports tool-calling. The SDK surfaces the consent prompt on the user's authenticated device, returns the sealed signature, and binds it to the agent's outbound calls.
Bank-side verification · webhook or library
Your payment API accepts the signature as an extension header. Verification library returns scope-match, freshness, and consent-clarity in a single call. Or run it as a sidecar webhook into your existing fraud platform.
Standards alignment
Signature serialization uses W3C Verifiable Credentials. Refresh flow follows OAuth 2.0 Step-Up Authentication Challenge Protocol. Card flows ride EMV 3DS extension data. We're active in the IETF GNAP working group for next-generation agent delegation primitives.
What the signature defends against.
Agentic workflows open a small set of new attack surfaces. The SoM Signature isn't a silver bullet, but the bindings make several specific attacks materially harder.
Prompt injection redirecting the action
A malicious document or webpage instructs the agent to redirect payment to an attacker-controlled account. The agent constructs a syntactically valid API call.
Stolen API credentials, no fresh consent
An attacker exfiltrates the agent's OAuth token. They attempt to replay it to drain the principal's account.
Replayed signature outside TTL
An attacker captures a valid signature in transit and attempts to replay it later or against a different action.
Agent acting after consent revoked
The principal changes their mind. They want to stop the agent from completing in-flight actions.
Scope creep through follow-on actions
The agent encounters an adjacent action ("pay this related invoice from a different vendor") and tries to extend the original signature.
Coerced delegation
The principal is being coached, scammed, or coerced at the moment of delegation. They produce a syntactically valid consent.
Builder questions, answered.
Pulled from conversations with agent-framework teams, fintech security leads, and bank API platform owners.
Yes — the signature is a payload, not a framework. Our agent-side SDK exposes a single primitive: getSoMSignature(scope, ttl). Drop it into any tool-calling loop. We have reference integrations for LangChain, AutoGen, Vercel AI SDK, OpenAI Assistants, and Anthropic Claude tools. The SDK handles the user-facing consent surface and returns the sealed signature; you decide how to forward it.
That's the whole point of the TTL + scope model. Pre-issued signatures with bounded scope and time-to-live let an agent act asynchronously within the principal's pre-authorized envelope. Outside that envelope, the agent can't proceed — it has to wait, step-up, or fail. The user trades certainty (they know exactly what the agent can do for the next 24 hours) for asynchrony (they don't have to be there for every call).
Two signatures meet at the transaction. The paying agent carries its principal's authorization signature. The receiving agent's principal has been onboarded with their own attestation chain (which may be a different signature class — Confirmation or Presence). The two are verified independently by the rails or banks involved. Neither agent is implicitly trusted by the other; both sides have evidence.
The EBA's RTS for agent-initiated payments under PSD3 is still being finalized — public consultation is ongoing. RTScale's signature satisfies the "something the user is" factor (affective biometric, hardware-attested), and composes with traditional possession and knowledge factors that the agent's runtime can carry. We're tracking the consultation closely and have submitted positions on the relationship between TTL-bounded authorization and dynamic linking. Production guidance arrives as the RTS firms up.
A compromised agent can replay an existing valid signature only inside its scope and within TTL. Prompt-injected scope expansion is caught at the bank's verification step (the new payee or amount won't match the signed scope). Credential theft of the agent's API token does not grant the attacker the principal's hardware root — they cannot mint a fresh signature. The blast radius of an agent compromise is bounded by the active signatures' scopes and TTLs, not by the agent's full credential set.
Quick Scan refresh: ~200 ms p95 on-device. Deep Scan re-authorization (for raising amount caps or broadening scope): 30 s. The agent's runtime can prefetch likely refresh prompts when it sees scope-boundary signals in its plan, so the user-facing pause is the scan duration, not scan + round-trip. Most production agent UIs we've seen surface the consent prompt inside their existing chat surface — no separate app required.
No. Capture is on-device, inside a hardware-attested context — Mobile SDK on the user's phone, Desktop SDK on the user's machine, Web SDK in the user's browser. The agent receives the signed signature, which is a small cryptographic artifact containing decomposed affect indicators and provenance, not raw biometric data. The agent runtime does not see, store, or have any path to the raw frames or audio. This is by design and contractual.
The principal can revoke through their user portal or banking app. Revocation is pushed to the bank's verification path and to the agent's runtime within seconds. The agent's next API call after revocation fails verification and the agent is informed it has lost authority. In-flight calls already accepted by the bank's queue may still settle — once a wire is committed to the rail, RTScale can't claw it back, and we wouldn't claim otherwise.
Bring your agent. We'll show you what consent provenance looks like in your stack.
The 30-minute demo runs your agent against a sandbox bank with a real RTScale verification path. Watch the signature get sealed at delegation, ride along through downstream calls, and trigger step-up at the scope boundary. No deck, no theoretical "imagine if" — your code, our SDK, working signatures.