Skip to main content
Amla Labs
← back to blog

Proof of Continuity: Why Token Theft Becomes Useless

Traditional security asks what you possess. Capability security asks who you are in the transaction.

security cryptography proof-of-continuity technical

When security researchers discuss agent authorization, they typically focus on scope: limiting what an agent can access. Short-lived tokens. Fine-grained permissions. Principle of least privilege.

These measures are required—but they’re not enough on their own.

The deeper problem isn’t scope—it’s continuity. In multi-hop agent workflows, how do you prove that a request is the legitimate next step in an authorized transaction, rather than a replay or injection by an attacker who intercepted credentials somewhere in the chain?

This question points toward a different security model: one where authority isn’t a thing you possess, but a relationship you continue.

The Problem With Possession

OAuth, JWT, and most enterprise authorization systems operate on a possession model. You present a token. The system validates the token. If valid, access is granted.

The diagram below illustrates the possession model: a token passes from Agent A to B to C, eventually reaching an API. At each hop, the same token is forwarded. The API validates the token and grants access—but has no visibility into the delegation path, no constraints accumulated along the way, and no way to detect if the token was stolen mid-chain.

sequenceDiagram
    participant A as Agent A
    participant B as Agent B
    participant C as Agent C
    participant API

    A->>B: [token]
    B->>C: [token]
    C->>API: [token]
    API-->>API: Valid token ✓<br/>Has permission ✓
    API-->>C: Grant access

⚠️ Problems: Token can be stolen at any hop. No record of delegation path. Permissions can accumulate.

This works for single-hop, synchronous requests where the token issuer can verify context at the moment of use. It breaks in multi-hop, asynchronous agent workflows for three reasons:

Tokens accumulate: When Agent A delegates to Agent B, and B delegates to C, what prevents C from combining permissions it received from multiple delegation paths? In possession-based models, nothing structural.

Context evaporates: By the third delegation hop, the token may still validate, but there’s no cryptographic trail showing who delegated access, under what constraints, or whether the original context still applies.

Interception enables replay: If an attacker captures a valid token in transit, they can present it themselves. The token is bearer-based—whoever possesses it can use it.

Research quantifies the last problem: credentials stay active an average of 47 days after they’re no longer needed. That’s 47 days where a stolen token grants access regardless of whether the legitimate holder should still have authority.

From Possession to Continuity

Capability-based security inverts the model. Instead of asking “do you possess valid authority?”, it asks “are you the authorized continuation of this transaction?”

The continuity model works differently. Agents declare continuation criteria, and the Trust Plane—the infrastructure layer that holds credentials and enforces constraints—verifies those criteria and signs the chain to the next executor. When Agent C presents the chain to the Trust Plane, it verifies: (1) the chain is cryptographically valid, (2) Agent C matches the designated executor criteria, and (3) Agent C signed the request. An attacker who intercepts the chain cannot forge Agent C’s signature, so interception is useless.

sequenceDiagram
    participant A as Agent A
    participant TP as Trust Plane
    participant B as Agent B
    participant C as Agent C

    A->>TP: delegate (criteria: B)
    TP->>B: [chain] signed by TP
    B->>TP: delegate (criteria: C)
    TP->>C: [chain] signed by TP
    C->>TP: request + sig(C)
    TP-->>TP: Chain valid ✓<br/>Executor: C ✓<br/>Signed by C? ✓
    TP-->>C: Execute

✓ Security: Trust Plane signs all chain extensions. Agents prove identity by signing requests. Interception useless—attacker can’t sign as C.

The distinction is subtle but consequential.

In a possession model:

Agent → [presents token] → Trust Plane
Trust Plane: "Is this token valid? ✓"
Trust Plane: "Does the bearer have permission? ✓"
Trust Plane: → [grants access]

In a continuity model:

Agent → [presents chain + signed request] → Trust Plane
Trust Plane: "Is this chain valid? ✓"
Trust Plane: "Who is designated to continue this transaction?"
Trust Plane: "Is this request signed by that designated party?"
Trust Plane: → [grants or denies based on signature verification]

The chain contains the history: who authorized the transaction, through which agents it flowed, what constraints accumulated at each hop. But the chain alone doesn’t grant access. The requester must prove they ARE the designated next step by signing the request with their private key.

This is Proof of Continuity. Not “do you have the token?” but “are you the transaction’s continuation?”

Why Interception Becomes Useless

Consider an attack scenario. The Trust Plane sends a capability chain to Agent B. An attacker intercepts the chain in transit and attempts to use it directly against the Trust Plane.

The diagram below shows what happens: the attacker presents the valid chain to the Trust Plane with a request. The Trust Plane confirms the chain is cryptographically valid and identifies Agent B as the designated executor. But when the Trust Plane verifies the request signature, the attacker cannot provide Agent B’s signature—they lack Agent B’s private key. The request is rejected.

sequenceDiagram
    participant A as Agent A
    participant TP as Trust Plane
    participant X as Attacker
    participant B as Agent B

    A->>TP: delegate (criteria: B)
    TP->>B: [chain]
    Note over X: Intercepts chain
    X->>TP: [chain] + bad signature
    TP-->>TP: Chain valid? ✓<br/>Designated: B<br/>Signed by B? ✗
    TP--xX: REJECTED

The attacker has the chain but lacks B’s private key. They cannot sign a valid request.

  1. Agent A requests delegation to Agent B via the Trust Plane
  2. Trust Plane creates and signs a chain designating Agent B as executor
  3. Trust Plane sends the chain to Agent B
  4. Attacker intercepts the chain in transit
  5. Attacker presents the chain to the Trust Plane with a forged request

In a possession model, the attacker succeeds. They have the token. The token is valid.

In a continuity model:

Attacker: [presents intercepted chain]
Trust Plane: "Chain valid? ✓"
Trust Plane: "Designated executor: Agent_B_pubkey"
Trust Plane: "Sign this request to prove you ARE Agent B."
Attacker: [cannot sign—doesn't have Agent B's private key]
Trust Plane: → REJECTED

The attacker has everything that was transmitted: the chain, the signatures, the constraints. What they don’t have is Agent B’s private key. Without it, they cannot prove they are the designated continuation.

Token interception doesn’t work because there’s nothing to steal. The chain isn’t authority you can possess—it’s a record of who IS authorized to continue.

Important caveat: This protection assumes the attacker cannot compromise the designated agent itself. If an attacker can induce Agent B to sign malicious requests—via prompt injection, session smuggling, or other agent-level attacks—then the signature verification passes. This is why tight constraints matter: even if the agent is tricked into signing, the Trust Plane enforces the bounds. Interception protection and constraint enforcement work together.

Structural Attenuation

Continuity solves interception. Attenuation solves privilege escalation.

When Agent A delegates to Agent B, the delegation must narrow permissions. This is the principle of least privilege applied to delegation chains. But in policy-based systems, attenuation is advisory: the policy says “B should have fewer permissions than A,” but nothing structural prevents B from claiming more.

Capability-based attenuation makes escalation structurally impossible.

The capability chain below shows how attenuation works in practice. Block 0 is the root, signed by the Trust Plane, granting Agent A both “refunds” and “payments” capabilities. When Agent A requests delegation to Agent B, the Trust Plane verifies Agent A is the current executor, validates the constraints narrow permissions, and signs Block 1 designating Agent B. Agent B later requests delegation to Agent C with tighter constraints. The Trust Plane signs all blocks—agents prove their authority by signing requests, not chain blocks.

flowchart TB
    subgraph Block0["Block 0: ROOT"]
        b0["capabilities: [refunds, payments]<br/>constraints: {}<br/>executor: Agent_A_pubkey<br/>signed_by: Trust Plane"]
    end

    subgraph Block1["Block 1: DELEGATION"]
        b1["capabilities: [refunds] ← narrowed<br/>constraints: {amount_max: 500} ← added<br/>executor: Agent_B_pubkey<br/>prev_hash: hash(Block 0)<br/>requested_by: Agent_A_sig<br/>signed_by: Trust Plane"]
    end

    subgraph Block2["Block 2: DELEGATION"]
        b2["capabilities: [refunds]<br/>constraints: {amount_max: 100} ← tightened<br/>executor: Agent_C_pubkey<br/>prev_hash: hash(Block 1)<br/>requested_by: Agent_B_sig<br/>signed_by: Trust Plane"]
    end

    Block0 -->|"Agent A requests delegation<br/>Trust Plane verifies & signs"| Block1
    Block1 -->|"Agent B requests delegation<br/>Trust Plane verifies & signs"| Block2

Trust Plane signs all blocks after verification. Agents sign delegation requests to prove authority. Permissions can only narrow, never expand.

The Trust Plane is the signing authority for all chain blocks. Agents prove they’re the current executor by signing delegation requests—the Trust Plane verifies these signatures before extending the chain. To add a block with expanded permissions, you’d need to either forge the current executor’s delegation request or compromise the Trust Plane itself.

Agent B cannot:

  • Claim payments capability (not delegated to them—Trust Plane won’t sign a block that expands permissions)
  • Remove the amount_max: 500 constraint (Trust Plane validates attenuation before signing)
  • Designate themselves as executor of a higher-privilege block (would require compromising the Trust Plane)

Escalation doesn’t require detection and response. It’s prevented by cryptographic structure.

Constraint Enforcement at the Trust Plane

Capabilities and constraints travel with the chain. But they’re enforced at the Trust Plane, not by the agent.

This matters because agents are increasingly code-executing systems. An agent with access to a Stripe API key might simply call stripe.refunds.create(amount=50000) directly, bypassing any if-statements in wrapper functions.

In a capability model, the agent never has the API key. The Trust Plane has the key. The agent has a capability chain that authorizes specific operations with specific constraints.

The architecture diagram below shows this separation. The agent holds only a capability chain and its own private key for signing requests. The Trust Plane holds the actual API credentials (Stripe API key, database passwords, etc.). When the agent wants to execute an operation, it sends the chain and a signed request to the Trust Plane. The Trust Plane verifies the chain, confirms the agent is the designated executor, evaluates all constraints against the requested operation, and only then executes using its own credentials.

flowchart LR
    subgraph Agent["Agent"]
        A1["Has: Capability chain<br/>Has: Private key (to sign)"]
        A2["Lacks: API credentials<br/>Lacks: Direct API access"]
    end

    subgraph TP["Trust Plane"]
        creds["Stripe API Key<br/>Database passwords"]
        verify["1. Verify chain<br/>2. Check executor<br/>3. Evaluate constraints<br/>4. Execute with creds"]
    end

    Agent -->|"chain + signed request"| TP
    TP -->|"executes"| Stripe["Stripe API"]

Agent can’t bypass constraints—it never has the credentials.

Trust Plane Evaluation:
1. Verify chain integrity (hash chain unbroken)
2. Verify Agent_B_signature matches designated executor
3. Extract constraints: {amount_max: 500}
4. Evaluate: 300 <= 500? ✓
5. Execute refund with Trust Plane's Stripe credentials

The agent never touches the credential. The Trust Plane enforces the constraint. Code execution can’t bypass what the agent never had access to.

Multi-Organization Delegation

The hardest case is cross-organizational: Agent A in Organization 1 delegates to Agent B in Organization 2. No shared identity provider. No common trust root.

The diagram below shows how capability chains handle this. Organization 1’s Trust Plane issues a chain to Agent A. When Agent A needs to delegate to Agent B in Organization 2, Agent A requests delegation through Trust Plane 1, which signs the new block designating Agent B. Agent B presents this chain to Organization 2’s Trust Plane. The chain is self-verifying—Organization 2’s Trust Plane can verify every signature using the public keys embedded in the chain, without needing federation with Organization 1’s identity provider.

flowchart TB
    subgraph Org1["Organization 1"]
        TP1["Trust Plane 1"]
        AgentA["Agent A"]
    end

    subgraph Org2["Organization 2"]
        TP2["Trust Plane 2"]
        AgentB["Agent B"]
    end

    TP1 -->|"1. issues root chain"| AgentA
    AgentA -->|"2. requests delegation"| TP1
    TP1 -->|"3. sends signed chain<br/>designating B"| AgentB
    AgentB -->|"4. presents chain"| TP2
    TP2 -->|"verifies chain"| TP2

No shared IdP needed. The chain is self-verifying.

OAuth handles this through federation, but federation establishes identity across boundaries—not capability constraints. By the time the token crosses organizational boundaries, its delegation history is typically lost.

Capability chains solve this by making the chain self-verifying. Each signature is verifiable against the public key embedded in the chain. You don’t need a shared IdP to verify that:

  1. The root was signed by a known Trust Plane
  2. Each delegation block was signed by the Trust Plane after verifying the previous executor’s request
  3. The final request was signed by the current designated executor

Trust is established by the cryptographic chain, not by organizational federation.

See Cross-Organizational Agent Trust in 30 Seconds for a concrete example of this in healthcare.

What Changes

Adopting continuity-based authorization changes operational assumptions:

Credential management simplifies: Agents don’t manage API keys. Trust Planes hold credentials. Agents hold capability chains.

Breach scope narrows: Compromising an agent yields their private key, which lets attackers continue transactions designated to that agent—with whatever constraints apply. It doesn’t yield credentials to all systems the agent accessed.

Audit improves: Every operation includes its full provenance chain. You can trace any action to its original authorization.

Human oversight focuses: Instead of approving every sensitive operation, humans approve delegation chains. High-risk constraints require human signature in the chain.

Revocation propagates: Revoking a Trust Plane’s root key invalidates all chains it signed. Revocation doesn’t require chasing tokens across systems.

The Confused Deputy Cannot Be Formulated

There’s a classic security problem called the confused deputy: a privileged entity is tricked into misusing its authority on behalf of an attacker. The deputy “has” authority that can be misused because authority is detached from context.

In Proof of Continuity, the confused deputy cannot be formulated. Not mitigated—impossible to express.

There’s nothing to “have” that could be misused. The transaction designates who continues it. Proving you’re that continuation requires cryptographic proof of identity. There’s no ambient authority sitting around waiting to be confused.

This isn’t a new insight. The only commercial operating system to achieve true capability-based security was the AS/400—and it averaged 99.99%-99.999% uptime with no significant security compromises. The model works. It just never made it into the authorization layer for networked systems.

Until now.

The Path Forward

Proof of Continuity isn’t theoretical. The cryptographic primitives exist. The security model has decades of research behind it (capability-based security dates to the 1960s; seL4’s capability model has formal verification).

What’s missing is infrastructure: Trust Planes that enforce capability chains, SDKs that make chain construction simple, and integration points with existing orchestration platforms like MCP and LangChain.

The enterprises deploying agents today face authorization gaps that identity providers aren’t designed to fill. Proof of Continuity offers a model where interception is useless, escalation is impossible, and constraints are enforced at execution time.

Authority that can’t be stolen. Delegation that can’t be forged. Constraints that can’t be bypassed.

That’s the security model agents deserve.

This is the third in a series on AI agent security. Next: See Proof of Continuity in action with insurance claims and cross-organizational healthcare workflows.