The Identity Problem Is Solved. The Trust Problem Isn't.
There's a wave of new protocols solving agent identity. Agents get cryptographic keys, sign their requests, prove who they are without pre-registration or shared secrets. This is good work and it's needed — bearer tokens and API keys were never designed for autonomous software making decisions on your behalf.
But here's what we keep seeing in production: an authenticated agent is not a trusted agent.
Identity answers "who is this?" Trust answers "what should this agent be allowed to do, right now, with this amount, to this recipient?"
If you're building a chatbot that calls APIs, identity is enough. If you're building an agent that moves money, it's not even close.
The Gap: What Happens After Authentication
Consider an agent that's been fully authenticated — valid cryptographic identity, signed request, proof-of-possession confirmed. The agent is who it says it is. Now it wants to initiate a $50,000 payment to a company in Dubai.
What does your authentication layer tell you about whether this should proceed?
Nothing. Authentication is binary. You're verified or you're not. But the real questions are graduated:
- Has this agent earned the right to make transactions of this size? A new agent shouldn't have the same spending authority as one that's completed 10,000 successful transactions.
- Is the recipient on a sanctions list? OFAC, EU, UK — there are thousands of sanctioned entities. Your identity layer doesn't screen them.
- Has this agent exceeded its daily limit? Even trusted agents need guardrails.
- Can we kill this agent instantly if something goes wrong? Not revoke its certificate in 24 hours. Kill it now.
- Is the message itself untampered? Not just the transport — the actual JSON-RPC payload inside the MCP envelope.
Trust Levels: L0 Through L4
We've been building this at CyberSecAI for the past year, and the model that works in practice is graduated trust levels:
| Level | Label | What It Means |
|---|---|---|
| L0 | Untrusted | Identified but cannot transact. Read-only. |
| L1 | Restricted | Micro-payments only. $10/tx, $50/day. |
| L2 | Standard | Normal transactions within limits. |
| L3 | Elevated | High-value transactions. Additional monitoring. |
| L4 | Full Access | Maximum authority. Every transaction audited. |
New agents start at L0. They earn trust through verified identity, successful transactions, and time. Trust can be revoked instantly — not through certificate expiry, but through a kill switch that takes effect on the next request.
This maps directly to how financial services actually work. A new employee doesn't get the same trading limits as a senior trader on day one. Why would we give a new agent unlimited spending authority just because it has a valid certificate?
What a Payment Stack Actually Needs
Here's the full chain for an agent making a payment:
- Identity — Is this agent who it claims to be? (Cryptographic verification)
- Trust — What is this agent's trust level? (L0-L4, dynamic scoring)
- Integrity — Is this specific message authentic and untampered? (ECDSA P-256 envelope signing, nonce, timestamp)
- Enforcement — Does this transaction fall within the agent's limits? (Per-tx, daily, scope-based)
- Compliance — Is the counterparty sanctioned? (OFAC/EU/UK screening in real-time)
- Execution — Generate the payment file. (ACH/NACHA for US rails)
- Audit — Tamper-evident record of the entire chain. (Hash-linked entries)
Most agent auth protocols handle step 1. Some handle step 3. Nobody else handles 2 through 7.
The Kill Switch Problem
Certificate revocation is too slow for agent payments. CRLs update on schedules. OCSP adds latency and a single point of failure. If an agent is compromised at 2:47 PM and your revocation mechanism runs hourly, that's up to 60 minutes of unauthorised transactions.
A kill switch is different. It's a flag checked on every single request:
Agent authenticated? Yes.
Certificate valid? Yes.
Kill switch active? YES → DENY. Immediately. No transaction processed.
Per-agent and per-customer kill switches. If a customer's entire fleet of agents needs to stop, one flag stops them all. This doesn't exist in any identity-only protocol because identity protocols don't model the concept of "trusted but suspended."
Sanctions Screening Is Not Optional
If an agent is making payments on behalf of a regulated entity, every counterparty needs to be screened against sanctions lists. This isn't a nice-to-have — it's a legal requirement under AML regulations in virtually every jurisdiction.
We integrated with Fintech and the result is that every payment goes through real-time screening before the ACH file is generated. An authenticated agent with L4 trust still gets blocked if the recipient matches a sanctioned entity.
No identity protocol does this. It's not their job. But if you're building agent payments and you stop at identity, you've built a system that can authenticate an agent making a payment to a sanctioned entity with full cryptographic proof that the payment was legitimate. That's worse than no security at all — it's auditable evidence of a compliance failure.
Keycloak Integration: Enterprise Identity Meets Agent Trust
For enterprises that already run Keycloak (or any OIDC provider), adding trust levels is straightforward. We built a Keycloak protocol mapper that embeds MCPS trust claims directly into standard JWTs:
{
"sub": "agent_abc123",
"mcps": {
"trust_level": 2,
"trust_label": "L2 -- Standard",
"payment_enabled": true,
"tx_limit": 10000,
"day_limit": 50000,
"scopes": "payment_initiate,sanctions_screen"
}
}
Keycloak roles (mcps-l0 through mcps-l4) map to trust levels. Your existing IAM infrastructure — SSO, role management, audit logs — stays exactly as it is. Agent trust becomes another claim in the token your systems already validate.
This means you don't need to choose between your enterprise identity provider and agent trust enforcement. They compose.
The Standards Are Coming
The OWASP AISVS 1.0 (releasing June 2026) includes requirements for cryptographically bound agent identity, message signing with nonce and timestamp verification, and fail-closed enforcement. The OpenAPI Extensions Registry now includes x-agent-trust for declaring agent authentication schemes in API specifications.
These standards don't mandate trust levels specifically, but they mandate the building blocks: proof-of-possession, integrity verification, and policy enforcement. Once you have those requirements in an audit checklist, "the agent was authenticated" is no longer a sufficient answer to "was this payment authorised?"
What Comes Next
Agent identity protocols are essential infrastructure. They solve a real problem — agents need to prove who they are without pre-registration and shared secrets. That work is valuable and the ecosystem needs it.
But identity is layer one. Trust, integrity, enforcement, compliance, and audit are layers two through six. If agents are going to move money — and they will — we need all six layers, not just the first one.
The question isn't whether an agent can prove its identity. It's whether an agent has earned the right to do what it's asking to do.
Raza Sharif is CEO of CyberSecAI Ltd, author of "Breach 20/20", and a CISSP/CSSLP. He maintains the MCPS (MCP Secure) protocol (IETF draft), the x-agent-trust OpenAPI extension, and contributes to OWASP AISVS. Contact: contact@agentsign.dev
Top comments (0)