AI Agents and the Security Nightmare Nobody's Solving

Zero Trust for Multi-Agent Systems

When One Agent Isn't Enough

Single-agent systems are already hard to secure. Multi-agent systems - where agents delegate to other agents, share context, and coordinate actions - are an order of magnitude harder.

Consider a typical multi-agent workflow in a modern enterprise. A user asks a planning agent to "prepare the quarterly infrastructure review." The planning agent breaks this into subtasks and delegates to specialized agents:

User Request: "Prepare quarterly infrastructure review"
         |
         v
  Planning Agent
    |         |           |              |
    v         v           v              v
  Cloud     Security    Cost          Report
  Inventory  Scanner    Analyzer      Generator
  Agent      Agent      Agent         Agent
    |         |           |              |
    v         v           v              v
  AWS/GCP   Vuln DB,    Billing       Confluence,
  APIs       Config     APIs          Email
             checks

Each agent in this chain needs its own credentials, its own permissions, and its own access to enterprise systems. The planning agent needs to trust the results from each subordinate agent. Each subordinate agent needs to verify that the planning agent is authorized to make the request. And the entire chain needs to be auditable back to the original human user.

This is the multi-agent authorization problem, and it's where zero trust principles become not just useful but essential.

The Authorization Explosion

Here's the math that makes multi-agent security so challenging.

With a single agent, you have one authorization decision: should this agent be allowed to perform this action? Binary. Manageable.

With two agents, you have three possible authorization scenarios: Agent A acting alone, Agent B acting alone, or Agent A delegating to Agent B.

With three agents, you have seven scenarios. With five agents, thirty-one. With ten agents, the number of possible authorization combinations is 1,023.

The formula is 2^n - 1, where n is the number of agents. This is exponential growth in authorization complexity.

Number of    |   Possible Authorization
Agents       |   Combinations
-------------|---------------------------
     1       |          1
     2       |          3
     3       |          7
     5       |         31
    10       |      1,023
    15       |     32,767
    20       |  1,048,575

No human can manually define policies for a million authorization combinations. This is why multi-agent security requires automated, policy-driven authorization - not manual configuration.

Warning

If your multi-agent authorization strategy involves manually defining who-can-delegate-to-whom rules, you will hit a wall. The complexity grows exponentially, and manual approaches break down at around 5-7 agents. You need policy-based, automated authorization from the start.

Delegation Chains: Who Authorized What?

In a multi-agent system, every action is the result of a delegation chain - a sequence of authorizations that starts with a human and passes through one or more agents.

A properly constructed delegation chain looks like this:

Human (Alice)
  --> authorizes Planning Agent (scope: infrastructure review)
    --> delegates to Cloud Inventory Agent (scope: read cloud resources)
      --> calls AWS API (scope: ec2:Describe*, s3:List*)

Every link in this chain must satisfy three properties:

1. Permission Diminishment

Each delegation must reduce permissions, never expand them. If Alice has admin access but authorizes the planning agent for "infrastructure review" only, the planning agent cannot delegate admin access to the cloud inventory agent. The delegation chain must monotonically decrease in privilege.

Permission Level at Each Link:

Human Alice:      [ADMIN - full access to everything]
                        |
                   (diminish)
                        |
Planning Agent:   [READ infrastructure, WRITE reports]
                        |
                   (diminish)
                        |
Inventory Agent:  [READ cloud inventory only]
                        |
                   (diminish)
                        |
AWS API Call:     [ec2:Describe*, s3:ListBuckets only]

This principle is fundamental to zero trust in multi-agent systems. Without it, agents can launder permissions - taking a narrow authorization from a human and expanding it through delegation.

2. Verifiable Provenance

Every agent in the chain must be able to prove who authorized it and what scope was granted. This requires cryptographic evidence - not just a claim in a log file, but a signed token or certificate chain that can be independently verified.

The technology for this exists in concept (think certificate chains in TLS), but the tooling for agent-specific delegation chains is still maturing. The core requirements are:

  • Each delegation produces a signed token containing the delegator's identity, the delegatee's identity, the granted scope, and an expiration time
  • The token is cryptographically chained to the previous delegation in the sequence
  • Any system receiving a request can verify the entire chain back to the human principal

3. Temporal Boundaries

Delegations must expire. An agent authorized to perform a task at 2 PM shouldn't still have that authorization at 2 AM. Short-lived delegations force re-authorization, which provides opportunities to revoke access, update policies, and verify that the agent's behavior remains within expected bounds.

Applying Zero Trust Principles to Multi-Agent Systems

Zero trust - "never trust, always verify" - was designed for network security. Applying it to multi-agent systems requires reinterpreting each principle for the agent context.

Principle 1: Verify Explicitly

In network security, this means authenticating every request regardless of source. In multi-agent systems, it means:

  • Every agent-to-agent interaction requires authentication
  • Agent identity is verified cryptographically, not by network location or shared secret
  • The delegation chain is verified end-to-end for every request
  • Authentication happens continuously, not just at session establishment

Principle 2: Least Privilege Access

In network security, this means giving users the minimum access needed. In multi-agent systems, it means:

  • Agents receive permissions scoped to their current task, not their potential tasks
  • Permissions are granted just-in-time and revoked as soon as the task completes
  • Delegation always diminishes scope
  • Agents cannot self-provision additional permissions

Principle 3: Assume Breach

In network security, this means designing as if the perimeter is already compromised. In multi-agent systems, it means:

  • Any agent in the chain could be compromised, manipulated, or malfunctioning
  • Design authorization so that a compromised agent cannot escalate privileges or expand access
  • Monitor agent behavior for anomalies even after successful authentication
  • Segment agent access so that compromise of one agent doesn't grant access to all systems
Tip

The "assume breach" principle is particularly important for multi-agent systems because agents can be manipulated through prompt injection, tool poisoning, or adversarial inputs without any traditional security compromise. An agent can be "breached" through conversation, not just through code exploitation.

Cryptographic Identity Verification for Agents

Agents need stronger identity than API keys and OAuth tokens. They need cryptographic identities that can be verified independently, chained through delegations, and revoked in real time.

SPIFFE for Agent Identity

SPIFFE (Secure Production Identity Framework for Everyone) is an open standard for workload identity that provides a strong foundation for agent identity. A SPIFFE ID is a URI that uniquely identifies a workload:

spiffe://organization.com/agent/planning/instance-abc123
spiffe://organization.com/agent/cloud-inventory/instance-def456

SPIFFE provides:

  • Verifiable identity: Each agent receives an X.509 certificate (SVID) that proves its identity
  • Short-lived credentials: SVIDs are automatically rotated, typically every hour
  • Federation: Agents in different trust domains can verify each other's identities
  • No secrets to manage: Identity is attested automatically based on the workload's properties

The limitation of SPIFFE for agents is that it identifies the workload (the agent process) but doesn't capture the delegation context (who authorized this agent and for what purpose). You need to layer delegation tokens on top of SPIFFE identities.

Delegation Token Architecture

A delegation token for multi-agent systems should contain:

{
  "chain": [
    {
      "principal": "alice@company.com",
      "type": "human",
      "scope": ["infrastructure:review"],
      "timestamp": "2026-03-27T14:00:00Z",
      "signature": "..."
    },
    {
      "principal": "spiffe://co.com/agent/planning/abc123",
      "type": "agent",
      "delegated_by": "alice@company.com",
      "scope": ["cloud:read", "reports:write"],
      "timestamp": "2026-03-27T14:00:05Z",
      "expires": "2026-03-27T16:00:00Z",
      "signature": "..."
    },
    {
      "principal": "spiffe://co.com/agent/inventory/def456",
      "type": "agent",
      "delegated_by": "spiffe://co.com/agent/planning/abc123",
      "scope": ["cloud:read"],
      "timestamp": "2026-03-27T14:00:10Z",
      "expires": "2026-03-27T15:00:00Z",
      "signature": "..."
    }
  ]
}

Each entry in the chain is signed by the delegating principal. The scope narrows with each delegation. Timestamps and expirations provide temporal boundaries. Any verifier can validate the entire chain.

Policy Engines for Multi-Agent Authorization

With thousands of potential authorization combinations, you need a policy engine - not a configuration file - to make authorization decisions.

Open Policy Agent (OPA) for Agent Authorization

OPA is the most mature general-purpose policy engine and can be adapted for multi-agent authorization. A Rego policy for agent delegation might look like:

# Agent delegation policy (Rego)

default allow_delegation = false

# Allow delegation if scope diminishes and chain is valid
allow_delegation {
    # Verify the delegator is authorized
    delegator_authorized

    # Verify scope diminishment
    scope_is_subset(input.requested_scope, input.delegator_scope)

    # Verify chain length is within limits
    count(input.delegation_chain) < max_chain_length

    # Verify temporal constraints
    time.now_ns() < input.delegation_expiry
}

# Maximum delegation chain depth
max_chain_length = 5

Key policy decisions for multi-agent systems:

Policy Decision Example Rule
Maximum chain depth No delegation chain longer than 5 agents
Scope diminishment Each delegation must be a subset of the delegator's scope
Temporal limits Delegations expire within 2 hours
Agent type restrictions Only planning agents can delegate to execution agents
Cross-domain restrictions Agents in domain A cannot delegate to agents in domain B
Human approval requirements Delegations involving PII access require human approval

Real-Time Policy Evaluation

Policy evaluation must happen in real time, on every request. This means:

  • Sub-millisecond policy evaluation latency (OPA achieves this)
  • Policy decisions cached with short TTLs (minutes, not hours)
  • Policy updates propagated within seconds
  • Decision logging for audit and debugging

Monitoring Multi-Agent Systems

Monitoring a single agent is straightforward. Monitoring a network of interacting agents requires thinking about the system, not just individual components.

What to Monitor

Delegation patterns: Which agents delegate to which other agents? Are new delegation paths appearing that weren't expected? Are delegation chains growing longer than usual?

Scope usage: Are agents using all the permissions they were delegated? If an agent consistently uses only 10% of its granted scope, the delegation is over-provisioned.

Cross-agent anomalies: Is the same data being accessed by multiple agents in a short time window? Are agents coordinating in unexpected ways?

Chain integrity: Are delegation chains valid end-to-end? Are any agents presenting tokens from chains they shouldn't be part of?

Correlation Across Agents

Traditional SIEM systems correlate events from a single identity. Multi-agent monitoring requires correlating events across multiple identities that are connected through delegation chains.

Correlation Requirements:

  Task ID: task-12345 (quarterly infrastructure review)
    |
    +-- Planning Agent: 15 actions over 45 minutes
    |     |
    |     +-- Inventory Agent: 234 API calls to AWS
    |     |
    |     +-- Security Agent: 89 configuration checks
    |     |
    |     +-- Cost Agent: 12 billing API queries
    |     |
    |     +-- Report Agent: 3 document creation actions
    |
    Total: 353 actions across 5 agents
    All traceable to: Alice's request at 14:00

Without this correlation, each agent's actions appear in isolation, and the overall behavior of the multi-agent system is invisible.

Practical Implementation: Where to Start

Multi-agent zero trust is a complex target. Here's a pragmatic implementation path.

Phase 1: Visibility (Month 1-2)

  • Inventory all agent-to-agent interactions in your environment
  • Instrument delegation chains with correlation IDs
  • Build a map of which agents delegate to which other agents
  • Measure current delegation depths and scope breadths

Phase 2: Basic Policy (Month 3-4)

  • Implement maximum delegation chain depth (start with 3)
  • Enforce scope diminishment on delegation
  • Require expiration on all delegation tokens (start with 4-hour maximum)
  • Deploy OPA or equivalent for policy evaluation

Phase 3: Cryptographic Identity (Month 5-6)

  • Deploy SPIFFE/SPIRE for agent identity
  • Replace shared credentials with SVID-based authentication
  • Implement signed delegation tokens
  • Enable end-to-end chain verification

Phase 4: Continuous Authorization (Month 7+)

  • Real-time policy evaluation on every agent action
  • Behavioral monitoring and anomaly detection
  • Dynamic scope adjustment based on observed behavior
  • Automated response to policy violations (revocation, isolation)
Note

For a deeper dive into zero trust authorization in multi-agent architectures, see Deepak Gupta's article on zero trust authorization for multi-agent systems.

The Cross-Domain Trust Problem

Multi-agent systems frequently span organizational boundaries. A planning agent in your company might invoke a third-party analytics agent, which in turn calls a cloud provider's management agent. Each of these agents operates in a different trust domain.

Your Company's Trust Domain    |  Vendor Trust Domain
                               |
Planning Agent ----delegate--->|  Analytics Agent
  (your credentials,          |    (vendor credentials,
   your policies)             |     vendor policies)
                               |         |
                               |         +--> Cloud API
                               |              (cloud provider
                               |               trust domain)

The challenge: delegation chains that cross trust domain boundaries cannot be verified by any single authority. Your policy engine doesn't have visibility into the vendor's agent behavior. The vendor's policy engine doesn't know about your delegation constraints.

Solving this requires federation - trust agreements between domains that define:

  • Which agent types from Domain A can delegate to which agent types in Domain B
  • What maximum scope can cross domain boundaries
  • How delegation tokens are verified across domains
  • What audit information is shared between domains

This is an emerging area with no mature solutions. The practical advice today: treat cross-domain agent interactions as untrusted by default. Validate every response from an external agent. Never pass your internal credentials through a cross-domain delegation chain. Use API-level integration (with standard OAuth) rather than agent-level delegation when crossing trust boundaries.

The Uncomfortable Reality

Multi-agent systems are being deployed today without any of these controls. Organizations are connecting agents to agents using shared API keys, with no delegation chain tracking, no scope diminishment, and no way to trace actions back to a human principal.

This works until it doesn't. And when it doesn't - when an agent chain makes an unauthorized decision that causes real damage - the question will be: who authorized this? With current architectures, the answer is often: nobody knows.

Zero trust for multi-agent systems isn't a nice-to-have. It's the minimum viable security architecture for any organization deploying agents that interact with other agents. The exponential complexity of multi-agent authorization means that ad-hoc approaches will fail. You need principled, policy-driven, cryptographically-verified delegation from the start.

The good news is that the building blocks exist - SPIFFE for identity, OPA for policy, OAuth for authorization, and mature logging infrastructure for monitoring. The engineering challenge is assembling them into coherent architectures for the specific needs of multi-agent systems. That engineering is happening now, and the organizations doing it will define the security patterns for the next decade.