Why do agent-to-agent protocols create more governance complexity than tool protocols?

Why This Matters for Security Teams

Tool protocols usually expose a bounded action surface: a request comes in, a known tool is called, and authorization can often be evaluated against a stable integration pattern. Agent-to-agent protocols are different because they introduce negotiated trust between autonomous systems that can choose paths, chain actions, and change behaviour at runtime. That makes the control problem closer to runtime governance than simple API access. Current guidance suggests this is where static RBAC and coarse allowlists become brittle.

Security teams also have to account for how trust is established, how identity is proven, and which side enforces policy when both participants can initiate actions. The risk is visible in the broader NHI landscape: NHI incidents are not rare exceptions, and NHIMG research shows that 72% of organisations have experienced or suspect a breach of non-human identities in the last year, from The 2024 ESG Report: Managing Non-Human Identities. Agentic systems amplify that problem because one compromised agent can negotiate with others and expand access through legitimate-looking exchanges. In practice, many security teams encounter this only after an agent has already traversed multiple systems through trust they never explicitly intended.

How It Works in Practice

Tool protocols are usually governed by a single application boundary: an orchestrator owns the session, the tool is called with a defined purpose, and the enterprise can often pre-approve scopes. Agent-to-agent protocols add a second layer of complexity because the trust decision is no longer just “may this tool be called?” but “should this agent be allowed to engage, negotiate, delegate, or accept work from another agent?” That is a governance problem as much as an authentication problem.

Practically, this pushes security architecture toward runtime controls:

• Use workload identity to prove what an agent is, rather than relying on a shared secret or static integration token.
• Issue short-lived credentials per task where possible, and revoke them automatically when the work ends.
• Evaluate authorization at request time using context, intent, and policy-as-code rather than fixed pre-approvals alone.
• Log both sides of the exchange, including delegation chains, tool calls, and any privilege changes.

That model aligns with current thinking in OWASP Agentic AI Top 10 and CSA MAESTRO agentic AI threat modeling framework, both of which emphasise that autonomous systems need controls designed for dynamic trust, not just static access lists. For operational maturity, teams should also map these workflows to the NIST AI Risk Management Framework and the OWASP NHI Top 10, since both highlight identity, authorization, and misuse as core control points. These controls tend to break down when agents are allowed to self-discover peers across multiple tenants because the trust graph becomes too dynamic to pre-model fully.

Common Variations and Edge Cases

Tighter agent-to-agent controls often increase latency and integration overhead, requiring organisations to balance autonomy against auditability. That tradeoff becomes sharper in multi-agent pipelines, where one agent brokers work for another and the system may need to decide whether delegation is allowed at all.

There is no universal standard for this yet, so guidance is still evolving. In some environments, a central orchestrator can remain the policy enforcement point; in others, peer-to-peer negotiation requires each agent to present cryptographic workload identity and accept only narrowly scoped, short-lived delegation. The strongest pattern is not universal trust but conditional trust: verify the agent, constrain the scope, and re-evaluate before every meaningful action. This is especially important where agents can access production APIs, customer data, or secrets stores, because even a well-intentioned agent may chain benign tools into an unsafe outcome.

For teams comparing approaches, the key distinction is that tool protocols assume a known action catalog, while agent-to-agent protocols must govern uncertain future behaviour. That is why standards such as the NIST Cybersecurity Framework 2.0 help at the program level, but they do not by themselves solve runtime delegation across autonomous systems. The practical answer is to reduce standing trust, prefer ephemeral access, and make every cross-agent exchange explicit, attributable, and revocable.

Related resources from NHI Mgmt Group

• Why do agent workflows create more governance risk than standalone models?
• Why is single-provider AI agent governance not enough for enterprise security?
• Why do agent tool chains create new identity governance problems?
• When does customer identity enrichment create more governance risk than value?