Who Verifies the Agents?

AI agents are starting to act on their own. They write and deploy code, file support tickets, query internal databases, trigger workflows, move money, and increasingly call other agents to get work done. The interesting shift isn't that an agent can do these things — it's that it can do them without a human pressing confirm on every step.

That raises a question that sounds simple and isn't: when an autonomous agent shows up at your system asking to do something, how do you decide whether to let it?

I've spent the last several months building Airlock to work through that question carefully. This post is the honest version of what I learned — including where existing standards already have good answers, and where there's a real gap worth filling.

The question is actually three questions

"Can I trust this agent?" collapses three distinct things that security people keep deliberately separate. Getting them muddled is the fastest way to build the wrong thing:

• Authentication — who is this agent? Proving the agent is who it claims to be.
• Authorization — what is it allowed to do? Mapping a verified identity to a set of permitted actions.
• Runtime risk — is it behaving? Whether this particular agent, right now, is acting within its normal envelope or doing something anomalous.

The first two are largely solved problems with mature standards. The third is messier, and it's where agents create genuinely new pressure. Let me give existing work its due before claiming any gap.

What existing standards already solve

If you're going to build in this space, you have to know the landscape — and credit it honestly. Here's the part of the problem that is not open:

So no — "nothing handles trust" would be wrong. Risk-based authentication is a mature commercial category. Reputation algorithms go back decades. If anyone tells you this is a greenfield, they haven't read the field.

So where's the actual gap?

The gap isn't that these pieces don't exist. It's that, for autonomous, delegating, cross-organization agents, they don't come integrated into one agent-native flow, and three things in particular are awkward to assemble from today's parts:

• Delegation chains with real revocation. Agent A asks Agent B, which asks Agent C. If A is compromised and revoked, what happens to B and C? In most setups: nothing — their tokens stay valid until they expire. That's a genuine hole.
• A behavioral risk signal scoped to agents. CAEP shares signals between enterprise identity providers. There's no widely-adopted equivalent for "this autonomous agent has a track record, here's a score you can weight or ignore."
• Tamper-evident audit as a first-class output. When an agent acts on your behalf, you want a record that survives scrutiny — every verification, every delegation, in a form that can't be quietly edited later.

Airlock is an attempt to integrate the right primitives for the agent case — not to reinvent identity. That framing matters, so I'll be precise about what's load-bearing and what's just a signal.

How Airlock works

An agent that wants to act through Airlock goes through five phases. The cryptographic path is fast; the verdict carries an identity, a delegation scope, and a risk signal.

Identity — the load-bearing part

Agents authenticate one of two ways: an Ed25519 signature tied to a W3C Decentralized Identifier (did:key), or an OAuth 2.1 / OIDC bearer token from an identity provider you already run. The OAuth path uses private_key_jwt client authentication (RFC 7523) — no shared secrets. This half needs no trust in Airlock: the signatures verify on their own math.

Delegation — the strongest card

Airlock implements RFC 8693 Token Exchange. When Agent A delegates to Agent B, A exchanges its token for a narrower-scoped one for B — B can only do what it was explicitly granted, never inherit A's full authority. And the chain supports cascade revocation: revoke A, and every token A delegated, transitively, dies with it. This is the part I'd defend in front of anyone, because it solves a concrete multi-agent failure that scoped tokens alone don't.

The behavioral score — one signal, not the root of trust

Each agent has a four-tier reputation that moves with its behavior: successful interactions raise it, failures lower it, inactivity decays it. But this is a signal a relying party can weight or ignore — exactly like a CAEP risk signal — not a verdict you're forced to accept. The cryptographic identity and the signed delegation are what's verifiable; the score is advisory. I'm deliberate about this distinction because reputation systems have well-known limits (cold start, gaming, and the question of who computes the score), and overselling it would be the wrong move.

Audit — the seal

Every verification, pass or fail, is written to a hash-chained audit trail: each record carries the hash of the previous one, so altering history breaks the chain and the tampering is detectable. That's the record that survives a compliance review.

How this relates to what already exists

The honest positioning — the thing I'd want an identity engineer to nod at — is that Airlock sits alongside these standards, not on top of a strawman:

• vs. OIDC: use it for the "who." Airlock consumes OIDC/OAuth tokens; it doesn't replace them.
• vs. SPIFFE/SPIRE: great for workload identity inside a trust domain. Airlock leans toward cross-organization agents and adds delegation + risk semantics on top.
• vs. CAEP / Shared Signals: CAEP shares events between IdPs; Airlock's score is a similar idea aimed at autonomous agents across org boundaries.
• vs. MCP / A2A auth: these define how agents talk and authorize. Airlock plugs in as the trust-and-audit layer — it ships an MCP server and an A2A adapter for exactly this.
• vs. Visa TAP / Mastercard Agent Pay: the networks are building agent identity into their own rails, for purchases — validation that these primitives (signed identity, user mandate, auditable record) are the right ones. Airlock aims the same primitives at everything that isn't a payment rail: your tools, your data, your infrastructure, agents across org boundaries.

This isn't about one industry

The same gap shows up everywhere autonomous agents act with delegated authority. A few concrete shapes:

• Software & DevOps: a coding agent opening a PR, or a deploy agent it delegated to — which one acted, and was it in scope?
• Customer operations: a support agent issuing refunds or accessing account data on a user's behalf.
• Data & analytics: an agent querying sensitive datasets — verifiable identity plus an auditable record of every access.
• Finance back-office: agents touching ledgers, reconciliation, treasury workflows — where scope and a tamper-evident trail aren't optional. (Consumer payment rails enforce their own limits; the exposed surface is everything around them.)
• Healthcare & regulated sectors: agents touching protected records, where "who did what, under whose authority" must survive an audit.
• Multi-agent platforms: any system where agents call agents, and a compromised one shouldn't quietly keep its delegated reach.

The common thread isn't a vertical — it's the shift from "a human clicked this" to "an agent did this on someone's behalf." Once that's true, identity, scoped delegation, a risk signal, and an audit trail stop being nice-to-haves.

What's actually built

This is a working implementation, not a concept paper:

• 853 automated tests — unit, integration, property-based (Hypothesis), and security-focused
• Full OAuth 2.1 authorization server — client credentials, RFC 8693 token exchange, introspection, dynamic registration, discovery
• Ed25519 identity over W3C did:key, with dual-mode (signature or bearer-token) verification
• Delegation chains with scope narrowing and cascade revocation
• Hash-chained audit trail and a compliance/reporting module
• Integrations — an MCP server, an A2A adapter, plus LangChain / OpenAI / Anthropic SDK hooks
• Python SDK (pip install airlock-protocol) and a hosted registry (private beta)