Why do agent-to-agent systems increase identity risk compared with human-in-the-loop AI?

Why agent-to-agent systems raise the identity bar

Agent-to-agent systems do not just add more automation, they add more independently acting identities. Each agent may need its own authentication material, delegation path, and permission boundary, so identity becomes a live control plane rather than a background implementation detail. That matters because the trust model is no longer “one user approves one action,” but “multiple software entities can authenticate and act on each other’s behalf.”

That shift is why multi-agent environments need explicit governance for agent registration, ownership, lifecycle, and cross-agent trust. NHIMG’s Multi-Agent and A2A Security Guide is built around those exact control points, including authenticated agent-to-agent communication, signed Agent Cards, and multi-hop delegation.

Human-in-the-loop AI still uses identity, but the human pause creates a natural checkpoint where authorization can be reviewed, challenged, or stopped. In agent-to-agent systems, that checkpoint can disappear unless it is designed back in. The practical result is more opportunities for impersonation, confused-deputy behaviour, and privilege chaining across tool and service boundaries.

Where the extra risk comes from

The risk grows because machine-speed delegation scales faster than human oversight. One compromised agent can inherit trust from another agent, reuse a token or session, or trigger downstream actions that look legitimate to surrounding systems. Once that happens, the blast radius is not limited to the first compromised identity, it can spread through delegated authority and shared trust paths.

Agent-to-agent systems also create more identity-bearing material to protect: credentials, tokens, certificates, and any service accounts or workload identities that let agents call tools or other agents. If those artefacts are long lived, shared, or over-scoped, an attacker can move from one agent to another without needing to break the underlying model. NHIMG’s AI Agent Authorisation Guide focuses on that problem by tying agent access to task scope, just-in-time access, and per-action policy decisions.

That is also why identity governance becomes a lifecycle issue, not just an access-control issue. If an agent is cloned, retired, repurposed, or left unowned, the environment can accumulate orphaned access paths that are difficult to detect and easy to abuse. The relevant question is not only whether the agent was allowed to act, but whether it is still supposed to exist, still has active credentials, and still reflects the current trust model.

Why human-in-the-loop changes the blast radius

Human-in-the-loop AI usually reduces identity risk in three ways: it slows action, inserts accountability, and limits autonomous chaining. A person can reject an out-of-pattern request, notice that a step is drifting beyond scope, or require a second look before a sensitive operation proceeds. That does not remove identity risk, but it makes the control surface smaller and easier to reason about.

Agent-to-agent systems remove much of that friction, so the control burden shifts to design-time guardrails and runtime policy enforcement. In practice, this means the identity model has to answer questions that are easy to avoid in a human-reviewed workflow: who owns the agent, what exactly can it do, what can it delegate, and how far can trust extend before another approval is required. NHIMG’s Identity Governance for AI Agents Guide covers that lifecycle view, including registries, ownership, access reviews, rotation, and offboarding.

The security implication is simple: if the organisation cannot explain the delegation chain, it cannot reliably contain the failure domain. Human-in-the-loop systems usually fail more slowly and more visibly; agent-to-agent systems can fail faster, more silently, and across more trust boundaries.

Risk and Threat Considerations

Agent-to-agent systems increase exposure to identity compromise because software entities can be used to impersonate other software entities, chain privilege, and keep operating without a human pause. That makes stolen or mis-scoped credentials more dangerous, since a single compromised identity may unlock further delegation paths and tool access.

Failure mechanism: An attacker who captures one agent’s credential or trust artefact can exploit delegated authority, reuse trust relationships, and move laterally through agent-to-agent calls until a higher-value action or data path is reached.

Impact: The likely result is broader blast radius, faster privilege escalation, weaker attribution, and harder containment than in a workflow that requires human review between sensitive steps.

Practitioner Guidance

What to prioritise: Treat agent identity, delegation, and permission scope as first-class controls before expanding autonomy. If an agent can act on behalf of another agent or a user, make the delegation explicit, bounded, and revocable rather than implicit.

What to verify: Confirm that every agent has a named owner, a defined lifecycle, and a distinct access boundary. Verify that shared credentials, long-lived tokens, and unattended “temporary” access paths are either removed or tightly constrained, because those are the easiest paths for identity chaining to become an incident.

Practitioner takeaway: The main design decision is not whether agents may act autonomously, but how much trust they can inherit before the system forces a fresh control point.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents increase non-human identity risk?
• Why do AI agents create new risk in non-human identity management?
• What is the difference between human identity governance and AI agent governance?