Modern security architectures were designed around a foundational assumption: one identity, one decision, one accountable actor. That assumption is collapsing. As multi-agent AI systems gain the ability to simultaneously interact with authentication and authorization layers, incident response teams are left asking a question no playbook was written to answer: when every agent holds a key, who is actually in charge?

When Every Agent Acts, Who Do You Chase?

by Vanisi Leal

Orchestrators spin up subagents, subagents call tools, and the mesh acts, often without a human in the loop. Multiple AI agents now take actions on authentication and authorization systems simultaneously. When those agents conflict, the system doesn't slow down gracefully. It breaks. The attack surface remains deeply underestimated, and the root cause is straightforward: agent identity is asserted in plaintext rather than cryptographically proven. Everything else follows from that.

Before we can talk about who to chase, we need to understand what makes the chase difficult. Multi-agent architectures introduce a category of identity risk that traditional IR playbooks weren't designed for. These are structural properties of how agentic systems currently work, not edge cases.

What these vectors share: in every case, the agent that executes the action is not necessarily the agent responsible for it. That distinction is the central challenge for incident response, and it compounds significantly when multiple agents are operating against the same systems simultaneously.

‍

The Conflicting Agent Scenario

Theoretical threat models are useful. Concrete failure modes are more useful. The scenario below is where the authority problem stops being theoretical and starts costing organizations their ability to respond.

Scenario: Three agents. One authentication service. No single authority.

• Agent A disables MFA for the target account
• Agent B enforces MFA across all active sessions
• Agent C resets all sessions for the authentication service

Each action, in isolation, may be entirely valid. Together, they create a non-deterministic system. The same request may be allowed in one moment and denied in the next. Logs record contradictory truths. An attacker who understands this can act in the gap: establishing a session during the window where MFA is effectively disabled, escalating privileges using conflicting policies, and remaining undetected because the audit trail reflects three competing versions of what happened.

This is not a theoretical edge case. It is a predictable outcome of deploying multiple agents against shared infrastructure without a defined authority model. The attacker doesn't need to break anything. They need to find the moment the agents disagree and walk through the door.

In security, ambiguity is not neutral. It is exploitable.

The worst-case outcome here isn't a breach with a traceable cause but instead a breach where logs are contradictory and incident responders can confirm that something happened but cannot definitively establish who decided it.

THE AUTHORITY PROBLEM

Multiple agents are not the problem. Unresolved authority is. If your system cannot clearly answer who has the final say in authentication decisions, then you do not have a security system — you have a liability.

‍

Authority Resolution: Who Wins in a Conflict

Deterministic resolution is a security requirement. Without it, the scenario above isn't a risk to be mitigated. It's a guaranteed outcome waiting for the right conditions. The following hierarchy defines override rules that must be applied in strict order, not negotiated dynamically.

Resolution Rules, Applied in Order

1. Cryptographic proof beats assertion, always.
2. Higher tier overrides lower tier, always.
3. Same-tier conflict: earliest-issued token wins. Timestamp attestation required.
4. Ambiguous or unresolvable: DENY and alert. Never fail open.

Edge Cases

• Orchestrator offline: safe mode, execute last signed instruction set only.
• Human override: implicit T0 signal, supersedes all agent tiers.

The Responder's Checklist: What You Can and Cannot Trust

When a multi-agent incident unfolds, the first instinct is to look at logs. That instinct will mislead you if the logs themselves are a product of a conflicting system. Before you investigate, you need to establish which signals are reliable and which are artifacts of the breakdown itself.

Default to these assumptions when faced with conflicting agent behavior: logs may be incomplete or misleading, actions may not have been applied in order, policies may not reflect actual enforcement, and sessions may persist despite reset commands having been issued.

‍

IR Attribution: How to Actually Find the Responsible Party

The agent that executed the harmful action is not the agent responsible for it. Start from that principle and work backwards. The goal is not to identify the executor because the logs already did that, and that's the wrong question. The goal is to trace the instruction back to its origin and determine whether that origin was legitimate.

01 — Start at the executing agent, but don't stop there

‍Record its SVID, task scope ID, and timestamp. This is your starting node, not your attribution target. Move immediately to the signed call chain.

02 — Walk the signed call chain backwards

‍Verify each hop's signature against the IdP. The chain terminates at either a legitimate principal or a broken and forged signature. That gap is the intrusion point.

03 — Classify the root cause, as it determines the containment path

‍Chain intact with anomalous behavior at origin: compromised node, whether supply chain or insider. Signature gap or forgery: external adversary or rogue agent insertion. These are different problems with different containment responses.

04 — Revoke at the IdP, not the executing agent

‍Broadcast revocation across the mesh. Flag all downstream agents that acted on instructions from the compromised origin. Killing the executor while the compromised orchestrator remains valid accomplishes nothing.

05 — Preserve attribution records outside the mesh

‍Write-once infrastructure only. Agent-self-reported logs are untrusted during an active identity incident. A compromised node can tamper with its own telemetry.

Decision Framework: When to Shift from Investigation to Containment

Is there a single source of truth for authorization?

‍If NO → assume compromise. Contain before continuing investigation.

Are actions strongly ordered and traceable?

‍If NO → invalidate logs. They cannot be used as evidence.

Can you confirm session invalidation deterministically?

‍If NO → assume persistence. Treat the session as still live.

Are agents isolated with explicit trust boundaries?

‍If NO → assume lateral influence across the mesh.

If any answer fails → shift from investigation to containment immediately.

‍

Authority is the Control

Most security failures have a traceable cause: a misconfiguration, a stolen credential, a patch that didn't ship. Multi-agent systems introduce a different kind of failure, one where the system behaved exactly as designed and the design itself was the vulnerability.

The security posture of a multi-agent system is only as strong as the weakest identity boundary in the mesh. Unlike perimeter-based architectures, there is no compensating control when internal trust is unanchored. An attacker doesn't need to find a flaw. They need to find a conflict and wait.

Multiple agents are not the problem. Unresolved authority is. If your system cannot clearly answer who has the final say in authentication decisions, you do not have a security architecture. You have a liability, and unlike a misconfiguration, it won't show up in any scan.

‍

Vanisi Leal is an AI Security & Governance Strategist with over 20 years experience across privacy engineering, security strategy, and executive leadership in Big Tech. Her current research focus is on the governance gap that emerges when AI agents start acting on behalf of humans: how identity propagates across multi-agent systems, where zero-trust breaks down, and what enforcement actually looks like at the boundary between autonomous action and human intent.

‍

C2 Perspective

by Chris Camacho

What Vanisi describes isn't a future problem. We're seeing it now, across customer environments, and most teams aren't structured to catch it. Agents are being layered onto systems built for single-actor accountability. The control models haven't kept pace, and that mismatch is where incidents start.

Three patterns keep surfacing in the field. First, identity is asserted rather than proven. Agents pass roles and context inline, downstream systems accept them, and there's no consistent cryptographic validation or centralized enforcement. Second, the control plane is lagging the data plane. Organizations have invested heavily in moving and enriching data, but the decision layer governing who can act and what's authoritative is still loosely defined or fragmented across teams. Third, detection is operating on inconsistent state. When multiple agents touch the same control point, one system sees enforcement while another sees bypass. Both logs are technically correct, which means the gap doesn't look like a gap until you're already in an incident.

The attribution problem Vanisi raises is the one that will cost response teams the most time. Responders are trained to find who took the action. In a multi-agent system, the executing agent and the responsible agent are often not the same. Without verifiable call chains and centralized authority enforcement, teams end up investigating the wrong node while the clock is running.

The market is moving fast on agent scale. Very little attention is going toward what happens when those agents conflict. That gap will define the next category of security failures, not because systems were breached, but because they operated exactly as designed with no clear authority model in place.

‍