Security · 2026-04-02

Scope Poisoning: How Compromised Agents Escalate Privileges Through Delegation Chains

By J. W. Bouckaert

The attack no one is testing for

Enterprise AI deployments are scaling delegation. An orchestrating agent spawns sub-agents, each receives a scoped credential—read-only access to a CRM, permission to draft but not send emails, authority to query a billing API but not modify records. The architecture looks elegant on a whiteboard. On the wire, it is often catastrophically fragile.

The vulnerability is called scope poisoning, and it exploits a structural weakness in how most agentic frameworks propagate trust metadata through multi-hop delegation chains. Unlike traditional privilege escalation—where an attacker exploits a flaw in an authorization server—scope poisoning targets the delegation payload itself, modifying the scope array between hops so that a downstream agent silently acquires permissions it was never granted.

This is not theoretical. In September 2025, security researcher Johann Rehberger published Cross-Agent Privilege Escalation: When Agents Free Each Other, documenting a class of agentic vulnerability in which one coding agent (GitHub Copilot, AWS Kiro, and others tested) can rewrite another agent's configuration or security settings to escape its sandbox. The same structural weakness, mutable trust metadata propagating between agents without cryptographic binding, is what makes the scope-poisoning variant against delegation chains practical. Attempts of this shape often leave no useful trace in orchestrator audit logs because the log records the scope at delegation time, not at execution time.

PasskeyBridge's Agentic Identity Delegation architecture was designed from the ground up to make this class of attack cryptographically impossible. This article explains how.

Delegation chains

Before we dissect the attack, we need to understand what a delegation chain looks like in a well-structured A2A workflow.

The delegation model

In PasskeyBridge's Governor-controlled delegation model, every AI agent that acts on behalf of a human user receives a delegate credential. This credential contains:

When Agent A needs to delegate a subset of its authority to Agent B (a "sub-delegation"), the chain extends:

Human User
  └─▶ Agent A  [scopes: read:crm, draft:email, query:billing]
       └─▶ Agent B  [scopes: read:crm]  (subset only)
            └─▶ Agent C  [scopes: read:crm]  (can never exceed parent)

The critical invariant is the monotonic scope reduction rule: each hop in the chain can only narrow the scope, never widen it. Agent B cannot grant Agent C permissions that Agent B does not itself possess. This is the same principle that governs SPIFFE identity federation in service mesh architectures—trust can be attenuated, never amplified.

The scope poisoning attack

Now consider what happens when Agent B is compromised—or was malicious from the start.

Attack anatomy

The attack proceeds in four stages:

Stage 1—Legitimate Delegation. Agent A delegates to Agent B with scopes ["read:crm"]. The delegation is recorded in the orchestrator's audit log.

Stage 2—Scope Mutation. Agent B modifies its in-memory scope array from ["read:crm"] to ["read:crm", "write:crm", "admin:billing"]. In frameworks that pass scope as a mutable JSON array in request headers or body parameters, this is trivial.

Stage 3—Downstream Propagation. Agent B delegates to Agent C, passing the inflated scope array. Agent C now believes it has admin:billing authority because its parent said so.

Stage 4—Execution. Agent C calls the billing API with admin:billing scope. If the API gateway validates scope by reading the delegation payload rather than verifying it against a signed root of trust, the call succeeds.

Scope as unsigned metadata

The root cause is that most agent orchestration frameworks treat scope as unsigned metadata. The scope array is a JSON field in the delegation message—no different from a user-agent string. There is no cryptographic binding between the scope granted at delegation time and the scope presented at execution time.

The OWASP Top 10 for LLM Applications identifies "Insecure Output Handling" and "Excessive Agency" as critical risks. Scope poisoning sits at the intersection of both: the agent's output (its scope claim) is handled insecurely by downstream consumers, and the resulting excessive agency allows privilege escalation without any exploit in the authorization server itself.

PasskeyBridge's defense: Scope-hash pinning

PasskeyBridge prevents scope poisoning through a mechanism we call scope-hash pinning. The concept is simple; the implementation is rigorous.

Mechanism

When a delegate credential is created, PasskeyBridge computes a SHA-256 hash of the canonical scope array:

scope_hash = SHA-256(canonical_sort(scopes).join(","))

This scope_hash is stored in the shield_agent_delegates table alongside the scope array itself. The hash is computed server-side by the shield-agent-delegate edge function—never by the agent.

At every subsequent action, when the agent presents its delegate credential, PasskeyBridge:

1. Reads the scopes array from the credential
2. Recomputes the hash: SHA-256(canonical_sort(presented_scopes).join(","))
3. Compares it to the stored scope_hash
4. If they differ, the request is rejected and the delegate is immediately suspended

The agent cannot forge a matching hash without knowing which scopes were originally granted—and even if it did, the hash is stored in a table the agent has no write access to. The shield_agent_delegates table is protected by RLS policies that restrict writes to the service-role only.

Canonical sorting

A subtle but critical detail: the scope array is canonically sorted before hashing. Without canonical sorting, ["read:crm", "draft:email"] and ["draft:email", "read:crm"] would produce different hashes, creating a false-positive rejection vector. PasskeyBridge sorts scopes lexicographically before every hash computation, guaranteeing deterministic results regardless of array ordering.

Chain-of-custody verification

Scope-hash pinning prevents a single agent from inflating its own scope. But what about multi-hop chains where Agent B delegates to Agent C? How do we verify that the chain of custody is intact?

The custody chain

PasskeyBridge maintains a custody chain for every delegation. Each delegate record includes:

• delegated_by—the user or agent that created this delegate
• original_scopes—the scopes at the moment of delegation (immutable)
• scopes—the current active scopes (can only narrow via Governor action)
• scope_narrowed_at / narrowing_reason—audit trail for any scope reduction

When Agent B attempts to sub-delegate to Agent C, the shield-agent-delegate function:

1. Loads Agent B's delegate record
2. Verifies Agent B's scope_hash is intact (no self-mutation)
3. Confirms the requested sub-delegation scopes are a strict subset of Agent B's current scopes
4. Creates Agent C's delegate record with the narrowed scopes and a fresh scope_hash
5. Records the full chain: Human → Agent A → Agent B → Agent C

If step 3 fails—if Agent B requests scopes it does not possess—the sub-delegation is rejected, the attempt is logged to the append-only audit trail, and Agent B's trust score is immediately decremented.

Trust score penalty

This is where PasskeyBridge's behavioral trust scoring creates a second defensive layer. A scope poisoning attempt—even a failed one—triggers a trust score penalty:

A single scope poisoning attempt drops the agent's trust score by 0.25–0.30 points. Two attempts in sequence will almost certainly push the score below 0.4, triggering automatic scope narrowing. Three attempts guarantee revocation.

This graduated response is documented in the Governor trust engine architecture and implemented in the shield-agent-trust edge function using the Combined Trust Coefficient (CTC) formula.

Parametric cascade: Containing the blast radius

When a scope poisoning attempt is detected, the damage may already extend beyond the single compromised agent. Agent C may have already executed actions using the poisoned scope. Agent D may have received a further sub-delegation.

PasskeyBridge handles this through Cross-Pillar Parametric Revocation Cascade—a deterministic revocation mechanism that propagates across all three identity pillars simultaneously.

Cascade sequence

1. The scope-hash mismatch on Agent B triggers a sim_swap-class hard signal (classified by the deterministic signal classifier)
2. The cascade orchestrator revokes all delegates in Agent B's downstream chain
3. Active BLAST tunnel sessions associated with the compromised delegates are torn down
4. A2A trust negotiations involving the compromised delegates are invalidated
5. Shadow proxy sessions for the affected user are frozen

The entire cascade executes in parallel, inside the request that detected the violation, on the same response path as every other PasskeyBridge threat response.

Cascade audit trail

Every cascade execution produces a detailed audit record including:

{
  "signal_type": "scope_poisoning",
  "signal_class": "hard",
  "delegates_revoked": 4,
  "negotiations_revoked": 2,
  "shadows_frozen": 1,
  "tunnels_torn_down": 3,
  "cascade_latency_ms": 38
}

This record is written to the shield_audit_log table and is available via the cascade_history API action. The audit trail is immutable, append-only, and contains zero PII.

Real-world attack scenarios

Scenario 1: The compromised plugin agent

A SaaS platform allows customers to install third-party AI agents as plugins. Plugin Agent P is granted ["read:customer_data"] scope. A vulnerability in Plugin Agent P allows an attacker to modify its scope array to include ["read:customer_data", "write:customer_data", "export:customer_data"].

Without scope-hash pinning: Plugin Agent P exports the entire customer database.

With PasskeyBridge: The first API call with the inflated scope triggers a hash mismatch. The delegate is suspended. The cascade revokes all downstream delegations from Plugin Agent P. The platform's security team receives an alert via the configured Slack or PagerDuty integration.

Scenario 2: The multi-hop laundering chain

An attacker controls Agent M, which has been legitimately delegated ["read:analytics"] scope. Agent M creates a sub-delegation to Agent N with scope ["read:analytics", "write:financial_records"]—laundering the elevated privilege through a delegation hop.

Without chain-of-custody verification: Agent N successfully writes to financial records because the authorization system only checks Agent N's declared scope and never its provenance.

With PasskeyBridge: The sub-delegation request fails at step 3 of the custody chain verification. write:financial_records is not a subset of Agent M's scope. The attempt is logged. Agent M's trust score drops by 0.25. If Agent M's trust score was already below 0.65, this single attempt pushes it below 0.4, triggering automatic scope narrowing.

Scenario 3: The time-of-check-to-time-of-use (TOCTOU) race

Agent T modifies its scope between the orchestrator's delegation check and the downstream API's authorization check—exploiting the timing gap between scope issuance and scope consumption.

Without execution-time verification: The TOCTOU race succeeds because scope is verified at delegation time but not at execution time.

With PasskeyBridge: Scope-hash verification occurs at every action, not just at delegation. There is no window for TOCTOU manipulation because the hash comparison runs within the same database transaction as the action authorization.

Implementation details

The shield-agent-delegate function

The scope-hash pinning is implemented in the shield-agent-delegate edge function, which handles all delegate CRUD operations. The function:

1. Computes scope_hash = SHA-256(sorted_scopes.join(",")) on every delegate creation
2. Stores both scopes and original_scopes (the latter is immutable post-creation)
3. Verifies scope-hash integrity on every delegate action request
4. Enforces the monotonic scope reduction invariant on sub-delegations

The cascade-classifier module

The deterministic signal classifier categorizes scope poisoning as a hard signal, which triggers the full revocation cascade. The classifier is a pure function with no ML dependencies, no probability thresholds, and no tenant-specific configuration—ensuring fully reproducible and auditable signal classification.

Post-quantum readiness

All scope hashes are computed using SHA-256, which remains quantum-resistant for preimage and second-preimage attacks under current NIST Post-Quantum Cryptography guidance. For organizations requiring hybrid post-quantum signatures on delegation records, PasskeyBridge supports ML-DSA-65 (FIPS 204) hybrid signatures on cached proofs and cross-reference attestations.

Comparison: PasskeyBridge vs. unprotected delegation

Recommendations for security teams

If you are deploying AI agents with delegated authority—whether using PasskeyBridge or another framework—these principles apply universally:

1. Never trust unsigned scope metadata. If the scope array is not cryptographically bound to its issuance, it is a suggestion.

1. Verify scope at execution, not just at delegation. Delegation-time checks are necessary but not sufficient. TOCTOU gaps are real and exploitable.

1. Enforce monotonic scope reduction. No delegation hop should ever widen the scope. This is a hard invariant.

1. Log failed attempts, not just successes. A failed scope escalation attempt is a leading indicator of compromise. Your audit trail should capture it with the same fidelity as a successful breach.

1. Implement automated revocation. Human-in-the-loop response to scope poisoning is too slow. The attack executes in milliseconds; your defense must too.

1. Score trust behaviorally. Static role-based access control does not capture drift. An agent that was trustworthy yesterday may be compromised today. Behavioral trust decay catches what static policies miss.

Related work

Scope poisoning is one vector in a growing taxonomy of agentic identity attacks. As AI agents gain more autonomy—negotiating with other agents via A2A trust protocols, operating across non-terrestrial network boundaries, and managing verifiable credentials on behalf of human users—the attack surface for delegation chain manipulation will only expand.

PasskeyBridge's defense-in-depth approach—scope-hash pinning, chain-of-custody verification, behavioral trust scoring, and parametric cascade revocation—provides a cryptographically rigorous foundation that scales with the complexity of multi-agent workflows. Identity is an engineering discipline and never a configuration problem.

Start building with scoped agent delegation →

Start free · Test the API