TL;DR: Agent2Agent (A2A) standardises how autonomous agents discover one another, exchange tasks, and use short-lived OAuth/OIDC tokens, but it also introduces compliance blind spots and orchestration overhead, according to Apono. The real issue is that agent-to-agent communication makes identity, auditability, and least privilege a runtime governance problem, not just an integration problem.
At a glance
What this is: This analysis explains how Agent2Agent protocol adoption changes identity governance for autonomous software, especially where discovery, token issuance, and auditability move into runtime execution.
Why it matters: IAM and NHI teams need to treat agent-to-agent communication as governed access, because scoped tokens and trace IDs do not by themselves solve approval, accountability, or least-privilege enforcement.
Context
Agent2Agent protocol adoption is best understood as an identity governance problem, not just a transport or interoperability upgrade. The core issue is that autonomous agents are now being given delegated authority to find, contact, and act through other agents, which pushes approval, scoping, and audit questions into the execution path.
In practical terms, A2A turns machine-to-machine collaboration into a governed access pattern. That matters because the same controls that work for static service integrations do not automatically answer who authorised a token, whether access was time-boxed correctly, or how to reconstruct intent after a cross-agent transaction.
The article's starting position is typical of current enterprise AI adoption: enthusiasm for automation is running ahead of the governance model. The gap is not whether agent workflows are possible, but whether they can be made accountable at the same speed as they are being adopted.
Key questions
Q: Where does Agent2Agent fail if teams rely only on logging and not authorisation?
A: It fails at the point of delegated execution. Logs can show that an agent acted, but they do not prove the token was properly scoped, the audience was correct, or the request should have been allowed in the first place. Without pre-issuance authorisation, observability records misuse after it happens instead of preventing it.
Q: Why do short-lived agent tokens still create governance risk?
A: Because short-lived does not mean well-governed. A token can expire quickly and still represent an unreviewed approval, an overly broad task scope, or an unaudited delegation chain. The risk shifts from long-term credential theft to runtime misuse and weak accountability over who authorised the access.
Q: What are the signs that agent access is becoming ungovernable?
A: Look for shared secrets across tools, inherited CI identity, inconsistent credential use between runs, and logs that cannot explain which prompt led to which action. Those signals show that the agent’s access path is being assembled on the fly and can no longer be reviewed as a fixed workflow.
Q: How should security teams govern Agent2Agent communication in production?
A: Treat every agent as a governed non-human identity, not just a service integration. Require ownership, scoped authentication, traceable task IDs, and lifecycle offboarding before the first production workflow goes live. If an agent can discover peers and request access at runtime, it belongs inside identity governance and audit processes.
Technical breakdown
Agent cards and discovery create a dynamic trust boundary
A2A uses an agent card, typically a JSON document published at a well-known endpoint, to advertise skills, endpoints, and supported authentication methods. That makes identity discovery programmable, but it also means trust is established at runtime rather than at a fixed provisioning point. The security issue is not discovery itself. It is that the system must decide, on the fly, whether one agent should be allowed to initiate work against another agent with only partially known context. In identity terms, this is closer to ephemeral delegated access than to a static service account relationship.
Practical implication: Treat discovery data as part of the authorisation decision, not just metadata.
Short-lived OAuth and OIDC tokens shift control to issuance time
The protocol's authentication model relies on short-lived OAuth 2.0 and OIDC tokens so access can be scoped per task and expire automatically. That reduces standing credential exposure, but it does not eliminate governance obligations. The control point moves from later review to earlier issuance, because once the token is minted the interaction can already be underway. In other words, the system improves temporal containment, but it also increases the importance of policy quality, audience restriction, and traceable token provenance.
Practical implication: Enforce issuance policies that bind tokens to task scope, audience, and lifetime before the first agent action begins.
Built-in observability does not equal auditability without correlation
A2A embeds trace IDs and OTLP logs and metrics so multi-agent work can be monitored across systems. That is useful, but observability only becomes auditability when the log trail can answer who initiated the task, what credential was used, which agent acted, and whether the action stayed within scope. Cross-agent workflows often fail here because the evidence is fragmented across registries, token issuers, and telemetry backends. The practical risk is that teams mistake having logs for having a reviewable control plane.
Practical implication: Correlate token issuance, task execution, and outcome telemetry into one audit path.
Threat narrative
Attacker objective: The objective is to obtain delegated, time-boxed access that can move through multiple agents while leaving weak approval and audit evidence behind.
- Entry occurs when one agent discovers another through an agent card or registry and requests a task relationship using the published authentication method.
- Credential access happens when the caller obtains a short-lived OAuth or OIDC token that authorises a scoped cross-agent action.
- Escalation occurs when teams lose visibility into who approved the token and whether the delegated scope was broader than the task needed.
- Impact follows when multi-agent workflows become difficult to audit, creating compliance blind spots and making misuse harder to reconstruct.
Breaches seen in the wild
- Google API Keys Exposure — Gemini AI: Google API keys exposed in client-side code via Gemini AI integrations, creating data leak risk.
- Gemini AI Breach — Google Calendar Prompt Injection: Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Agent2Agent adoption turns runtime delegation into the new governance surface: The central issue is no longer whether agents can talk to each other, but whether those conversations are authorised, time-bounded, and reconstructable. A2A moves identity decisions into the middle of execution, which means governance has to keep pace with the transaction, not the deployment. Practitioners should assume the control plane is now part of the workload.
Ephemeral access reduces exposure, but it does not solve accountability: Short-lived tokens reduce standing privilege, yet they also compress the window in which approval, intent, and context can be evidenced. That makes token provenance, task correlation, and access purpose part of the core security record. The practical conclusion is that ephemeral credentials are necessary, but not sufficient, for agent governance.
Runtime identity for agents needs different assumptions than service integration: Traditional integration patterns assume a stable calling service and a known trust relationship. A2A introduces on-demand negotiation between agents that may not have a predeclared business relationship, which breaks static review models. The implication is that identity policy must operate on task scope and session context, not just on the named endpoint.
Built-in telemetry is only valuable when it can answer governance questions: Trace IDs and structured logs help, but they matter only if teams can use them to answer who approved access, which token was used, and whether the action stayed within policy. A2A is exposing a common gap between observability and accountability. Security teams should stop treating logs as evidence unless they can reconstruct delegated access end to end.
Agentic interoperability is creating a new class of NHI governance debt: The more organisations standardise agent handshakes, the more they inherit cross-agent lifecycle obligations for inventory, revocation, and review. That is a structural identity problem, not just an orchestration one. NHI programmes now have to govern agent-to-agent access with the same seriousness they already apply to service accounts and APIs.
From our research library:
- Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Identity Guide
What this signals
Agent2Agent creates a control problem at the moment of delegation: As soon as agents can discover one another and negotiate access dynamically, identity policy has to move upstream into issuance, not downstream into review. That shift changes how IAM, PAM, and NHI teams think about what counts as a control failure because the failure may now be an unauthorised task handoff rather than a compromised account.
Runtime trust needs to be designed around task scope, not actor labels: If an agent can request work from another agent, then the relevant question is not simply which system is calling. The more useful question is whether the requested action, token audience, and execution window match the exact task being delegated. That is where current governance programmes will either adapt or create durable blind spots.
Access review alone is too late for autonomous collaboration: Reviews can confirm what happened after the fact, but they do not stop an agent from acting within a narrow window of opportunity. The practical implication is that organisations need issuance controls, not only recertification controls, when adopting A2A-style communication.
For practitioners
- Define task-scoped authorisation for agents Bind every cross-agent request to a narrow purpose, explicit audience, and short lifetime so the token cannot outlive the task it was issued for.
- Inventory agent discovery endpoints Track every /.well-known/agent.json or registry entry as an identity asset, because discovery data now determines who can ask for work and how.
- Correlate token issuance with task execution Join issuer logs, trace IDs, and task outcomes so investigators can tell who approved access, which agent acted, and when the action completed.
- Review agent-to-agent access as lifecycle governance Apply joiner, mover, and leaver thinking to non-human identities that discover and call other agents, including revocation when the workflow changes.
- Separate observability from approval Require policy checks before token minting and not just after logging, because evidence collected after the fact does not prevent unauthorized delegation.
Key takeaways
- Agent2Agent pushes identity governance into the execution path, where discovery, token issuance, and auditability must be controlled in real time.
- The main risk is not protocol adoption itself but the creation of compliance blind spots around who approved access and whether the task stayed in scope.
- Practitioners need issuance-time policy, correlated telemetry, and lifecycle revocation to keep agent-to-agent delegation reviewable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | A2A relies on task-scoped auth flows that must be correctly bound to each agent interaction. |
| NHI-05 — Overprivileged NHI | Cross-agent delegation can easily exceed the minimum access needed for a specific task. | |
| NHI-07 — Long-Lived Secrets | The article contrasts short-lived tokens with static credentials in agent workflows. | |
| Recommendation — Bind agent authentication to task scope, audience, and lifetime before any delegated action begins. Limit each agent handshake to the narrowest permissions needed for the current task. Replace persistent credentials with short-lived, auditable tokens wherever agents exchange work. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | A2A makes runtime authorisation central to whether delegated access is valid. |
| Recommendation — Apply entitlements checks before token issuance and again when agent scope changes. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token issuance, expiry, and lifecycle are the core control points discussed in the article. |
| Recommendation — Manage agent authenticators so tokens are issued narrowly, rotated often, and revoked cleanly. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | A2A uses API-style task calls where weak binding of identity and token can create abuse. |
| Recommendation — Harden agent task endpoints so authentication is validated for every cross-agent request. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The protocol can be abused to obtain scoped tokens and move between agent boundaries. |
| Recommendation — Map agent delegation abuse to credential access and lateral movement, then monitor for unusual task chaining. | ||
Key terms
- Agent Card: An Agent Card is a machine-readable description of an agent’s capabilities, endpoint, and invocation details. In A2A-style systems it helps other agents discover and call the agent at runtime, which makes the card a governance object as much as a technical descriptor.
- Task-Scoped Token: A task-scoped token is a short-lived credential issued for one specific action or workflow segment. It narrows access to the smallest usable window and expires when the task ends, reducing the chance that a dynamic identity keeps permission after the original need has passed.
- Runtime Delegation: The process by which an identity is allowed to choose actions, tools, or next steps while a task is in progress. In AI agent environments, runtime delegation is risky when it is broad, opaque, or disconnected from explicit policy, because the resulting behaviour may exceed the original intent.
- AI Agent Observability: AI agent observability is the practice of tracking what an agent does across systems, including actions, permissions, and data access. It provides visibility into behaviour, but it does not by itself establish what the agent was authorised to do or when access should be revoked.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org