AI Agents as Confused Deputies with Niki Aimable Niyikiza

Summary: AI Agents, “Confused Deputy” Threats, and Tenual

Topic Framing: Why AI Agents Enable “Confused Deputy” Threats

The speaker argues that AI agents have a different architectural reality than systems security teams are typically used to—for example, environments with:

• Microservices and predictable call graphs
• Static identities and more stable authority boundaries

A central claim is that agent behavior is nondeterministic at deployment time. In practice, what an agent does later can vary based on:

• Prompts and user inputs
• System prompts
• Multi-agent delegation / delegation patterns

Because of this, the “authority” granted to an agent when it is deployed may not match what the agent ends up doing later. This mismatch can create confused deputy–style vulnerabilities:

Attackers can manipulate inputs so an agent uses its granted authority in unintended ways—without privilege escalation, but via action/intent mismatch.

---

Why Common Guard Rails Are Insufficient

Early defenses such as model output guard rails (e.g., filtering model text) are criticized because they:

• Focus on what the model says, not what the agent actually does
• Are probabilistic/black-box (difficult to guarantee deterministic safety for production actions)
• Provide weak auditability and limited ability to explain why an action was allowed or denied

The speaker’s emphasis: security must control actions at the tool boundary, not model thoughts or outputs.

---

Core Proposal: Task-Bound, Capability-Based Authorization (with Delegation Awareness)

The talk proposes a capability-based approach inspired by the classic confused deputy “valet key” analogy:

• Don’t give an agent a “master key” (identity-bound authority that can be misused)
• Instead, provide a constrained “warrant” bound to the specific task with limited scope

The speaker’s research direction is mentioned as “Tenual”.

Key idea for multi-agent / multi-hop delegation: authorization must be designed so that it is:

1. More deterministic by narrowing authority to the task
2. Context-aware of the delegation chain
3. Attenuated at each delegation hop (authority shrinks as delegation continues)

---

Capability Tokens vs. Role/Identity-Based Access

The speaker contrasts:

• Role/identity-based access control
  • Authority tied to who is acting
  • Works best when the call graph is stable
• Capability-based access control
  • Authority tied to what action/task
  • Safer when agents may take unexpected actions or when delegation is complex

Inspiration and related work mentioned include:

• “Macaroons” (Google, 2014): delegated capabilities with attenuating caveats
• A 2025 DeepMind paper: capability-based access control is presented as a good fit for agent authorization in the confused deputy problem

---

Tenual Warrants: Features and Properties

A Tenual warrant is likened to a legal warrant:

• It defines the mission/task and its limitations, not just the holder identity.

The subtitles describe six properties (as stated) including:

• Cryptographic signing and issuer/holder binding
  • e.g., asymmetric encryption / “proof of possession” semantics
• Tool-call specificity
  • Scoped to specific tool calls and explicit action constraints
  • Example style: “visit this URL,” “read this directory,” not broad “access email”
• Ephemerality / TTL
  • Warrants expire
• Offline verification
  • Verifiable without contacting a central authorization service (similar to certificate verification)
• Delegation chain / regression awareness
  • Preserves delegation chain context for auditing (trace back to earlier hops)

---

Token Misuse vs. Delegation Chain Correctness

The speaker distinguishes between different failure classes:

• Authorization bugs
  • Incorrect interpretation/implementation of permissions
• Identity propagation bugs
  • Identity/credential misuse or sprawl (delegation without proper derivation)
• Capability design flaws
  • Capabilities not properly holder-bound
  • Missing attenuation across delegation hops

A key emphasis: delegation must derive new attenuated credentials/artifacts, not “hand over master authority,” otherwise confused deputy risks persist.

---

Constraint Interpretation Vulnerabilities (“Semantic Problems”)

Even with strong cryptography and deterministic authorization logic, failures can occur if the constraint language and execution semantics don’t align with real-world interpretation.

Examples mentioned:

• Path traversal
  • “Allowed base path” checks can fail if traversal encoding like /../../ is used
• URL/hostname parsing tricks
  • Domain vs IP vs representation mismatch (“map vs territory” analogy)
• TOCTOU / stream interpretation
  • If verification happens on partial streamed output, the agent may switch targets mid-stream
• Homograph attacks / human-in-the-loop mismatch
  • Human perception of approval must match what the system actually interprets
• DNS vs IP resolution mismatch
  • Symlink/real-path issues: authorization must reflect what will truly be executed

As mitigation, the speaker argues for:

• Normalization primitives, including:
  • path normalizer
  • URL normalizer
• Tight coupling between:
  • authorization evaluation and the execution environment
  • e.g., using sandbox/integration so both components interpret reality identically

---

Performance and Deployment Approach

The talk mentions tool boundary checks with low overhead—authorization decisions around:

• ~55 microseconds

Deployment patterns described include:

• Framework integration via pre tool hooks/middleware (proxying tool calls and verifying warrants)
• Sidecar / MCP proxy approach (verify warrants before tool calls)
• Gateway-level verification (check warrants passing in/out)

Implementation details:

• Tenual implemented in Rust
• Described as open source
• Uses Ed25519, with an extensible design

---

Demo Concept: Delegation with Attenuated Warrants

The demo is described as a conceptual simulation:

Architecture flow

1. A control plane delegates a top-level task to a manager agent using an initial warrant with broad capabilities
   • (e.g., web search, read/write file—broad enough for the manager’s role)
2. The manager agent delegates to sub-agents using attenuated sub-warrants:
   • A research agent gets narrower authority:
     • read web + read files only in a specific directory
     • write-file is dropped
3. Later, manager delegates to a writer agent with a warrant restricting writes to a specific output location

Demo goal

Prevent:

• Accidental out-of-scope reads/writes
• Hallucinated authority (agents taking unintended actions)
• Temporal mismatch issues via warrant expiration/renewal

Warrant “anatomy” shown

• Warrant ID
• Holder (agent identity shown; verification uses key binding)
• Public key binding
• Per-tool constraints (allow domains, deny semantics)
• TTL
• Validation at tool call time

---

Human-in-the-Loop via Cryptographic Approval

The system can add approval gates using cryptographic signatures, supporting threshold schemes like:

• n-of-m signatures

Approval requires signing artifact(s), not just calling a simple approve endpoint.

---

Crypto Receipts and Auditability

For each authorization decision, Tenual generates a cryptographic receipt proving why an action was allowed/denied.

This is positioned as stronger than relying on:

• logs alone
• a black-box policy engine

---

Wrapping Up: Threat Model and Blast-Radius Control

The speaker argues that unsafe agent tool invocation can scale exploitation far beyond traditional systems. Therefore:

• Bounding the blast radius via outbound authorization checks at tool boundaries is crucial.

---

Main Speakers / Sources

• Main speaker: Nikki (Nakiza / “Nikki” in subtitles), VP of Security at Snap
  • Security researcher focused on infrastructure/agent security and the Tenual project
• Host / moderator: The “off-by1” security stream host (name not shown in subtitles)

Mentioned external sources / inspiration

• “Macaroons” (Google, 2014)
• DeepMind paper (2025): capability-based access control fits agent authorization for confused deputy
• Mentions of related agent security issues and patterns, including:
  • SSRF
  • delegation-related confused deputy patterns