Implicit discovery breaks trust because one agent may inherit context or delegate work without a clear authentication and authorisation boundary. That creates hidden propagation paths across systems and makes it difficult to prove who initiated the action chain. Teams need explicit trust rules before they allow agent interactions to scale.
Why This Matters for Security Teams
Implicit agent-to-agent discovery is not just a design shortcut. It changes the security model from known, reviewable trust to inferred trust, which is a poor fit for autonomous systems that can chain tools, delegate work, and act without human pacing. Once an agent can “find” another agent by context alone, the boundary around authentication, authorisation, and accountability becomes blurred. That is exactly the kind of gap called out in the OWASP Agentic AI Top 10 and in the CSA MAESTRO agentic AI threat modeling framework, both of which treat trust boundaries as first-class security objects rather than assumptions.
The practical risk is that implicit discovery lets one agent inherit the authority or context of another without a clean policy decision. That can create hidden propagation paths across ticketing systems, code runners, message buses, and internal APIs. It also undermines post-incident analysis because teams cannot easily prove which agent initiated the chain, which credentials were used, or whether the downstream action was authorised at runtime. NHI governance matters here too: NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which makes hidden agent links even harder to detect. In practice, many security teams encounter this only after a delegated action has already crossed into an unintended system boundary, rather than through intentional discovery design.
How It Works in Practice
The safer pattern is to make discovery explicit and policy-bound. An agent should not “assume” another agent is eligible to act on its behalf just because it is reachable in the environment. Instead, discovery should be mediated by workload identity, runtime policy, and narrowly scoped delegation. That means the requesting agent proves what it is, the target agent proves what it can do, and the policy engine decides whether the interaction is allowed in that moment.
In agentic systems, static role-based IAM often fails because behaviour is goal-driven and dynamic. A fixed RBAC role may be too broad for the task, yet still too narrow for a new path the agent invents mid-execution. Current guidance therefore leans toward intent-based authorisation, where the decision is made from the task, context, and provenance rather than a pre-defined static grant. The most practical implementation pattern is JIT credential provisioning with short-lived secrets, because agents should receive credentials only for the specific step they are performing. That aligns with Zero Trust thinking in the NIST AI Risk Management Framework and with the identity rigor in NIST AI Risk Management Framework.
A practical control set usually includes:
- Explicit agent registry or service catalogue for discovery, not ambient network reachability.
- Cryptographic workload identity, such as SPIFFE or OIDC-backed service tokens, to prove agent identity.
- Policy-as-code checks at request time, using context such as task, tenant, data sensitivity, and tool scope.
- Ephemeral delegation tokens with automatic revocation after completion or timeout.
- Audit trails that preserve initiation, delegation, and downstream execution as separate events.
This approach is reinforced by NHIMG research on agentic application risk, including the OWASP NHI Top 10 and the Top 10 NHI Issues. These controls tend to break down when agents are allowed to self-discover peers across loosely governed microservice meshes because the trust decision is then outsourced to topology rather than policy.
Common Variations and Edge Cases
Tighter discovery control often increases orchestration overhead, so organisations have to balance agility against the cost of maintaining explicit trust maps. That tradeoff becomes sharper in multi-agent workflows where one coordinator may need to call several specialist agents in sequence. Best practice is evolving, but there is no universal standard for this yet: some teams prefer central broker patterns, while others use decentralised policy checks with signed intent claims.
Edge cases usually appear in hybrid environments. Legacy systems may not support workload identity, which forces teams to wrap them with gateways or token translation layers. Human-in-the-loop workflows also need careful handling because a human approval does not automatically make downstream agent delegation safe. Another common failure mode is long-lived secrets stored for convenience in CI/CD, code, or config files. NHI Mgmt Group research shows 96% of organisations store secrets outside secrets managers in vulnerable locations, and 71% do not rotate them within recommended time frames. That is particularly dangerous when an agent can fan out from one discovery event into many downstream calls.
For threat modelling, the right question is not whether the agent can discover a peer, but whether the peer can verify the requester’s identity, intent, and delegated scope before acting. The Moltbook AI agent keys breach is a useful reminder that exposed agent credentials can turn simple integration paths into broad compromise paths. The main exception is tightly bounded internal automation with single-purpose agents and pre-approved workflows, but even there the controls should be explicit rather than assumed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agent-to-agent trust failures map to unauthorized tool and peer interaction risk. |
| CSA MAESTRO | MAESTRO treats agent trust boundaries and runtime policy as core security controls. | |
| NIST AI RMF | AI RMF governance and mapping functions support accountability for autonomous actions. |
Require explicit authorization checks before any agent can delegate or call another agent.
