They often treat discovery as a harmless convenience layer. In reality, an Agent Card advertises capabilities, endpoints, and auth methods, which makes it part of the trust decision. If discovery is not governed, agents can find and call services that were never meant to be broadly reachable.
Why This Matters for Security Teams
agent discovery is not just a directory problem. An Agent Card can expose what an agent can do, which endpoints it can reach, and how it authenticates, so discovery becomes part of the trust boundary. If teams assume cards are harmless metadata, they often allow broad reachability before they have decided who should trust the agent, under what context, and for which tasks.
This is where many governance gaps start. Discovery mechanisms can make hidden capabilities visible to other agents, orchestration layers, or humans who were never intended to invoke them. That changes exposure from “can this service be found” to “should this identity be allowed to act.” Current guidance from OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to context-sensitive control, not passive publication.
NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, which matters here because undiscovered or poorly governed agent identities tend to be trusted by default. In practice, many security teams encounter overexposure only after an agent has already discovered a service and invoked it, rather than through intentional discovery design.
How It Works in Practice
Effective agent discovery treats the Agent Card as a policy input, not a public brochure. The card should describe capabilities, authentication requirements, and intended scope in a way that can be evaluated by policy engines at request time. That means the discovery layer, the identity layer, and the authorisation layer must work together. For agentic systems, static RBAC alone is usually too blunt because the same agent may need different tools, scopes, or downstream services depending on task context.
A stronger pattern is to combine workload identity with runtime authorisation. A discovery request can reveal an Agent Card, but invocation should still require proof of workload identity, such as OIDC-backed identity or SPIFFE-style cryptographic attestation, plus a decision from policy-as-code. That policy should consider task intent, environment, tenant, data sensitivity, and whether the request came through an approved orchestrator. This is consistent with the emerging direction in CSA MAESTRO agentic AI threat modeling framework and the MITRE ATLAS adversarial AI threat matrix, which both emphasize that attack paths emerge through composition, not isolated services.
- Limit which registries can publish Agent Cards and who can query them.
- Classify cards by sensitivity, not just by function.
- Bind discovery to runtime checks, so visibility does not equal reachability.
- Expire or suppress cards for agents that are inactive, unapproved, or out of scope.
- Log card access separately from tool invocation so discovery abuse is detectable.
For deeper NHI governance context, the Ultimate Guide to NHIs — 2025 Outlook and Predictions and NHI Lifecycle Management Guide both reinforce that identity lifecycle and visibility are inseparable from access control. These controls tend to break down when agent registries are shared across teams or tenants because discovery becomes de facto authorisation without any equivalent policy gate.
Common Variations and Edge Cases
Tighter discovery controls often increase operational overhead, requiring organisations to balance easier agent reuse against more restrictive reachability. That tradeoff is real, especially in multi-agent environments where teams want fast composition and low-friction onboarding. Best practice is evolving, and there is no universal standard for how much detail an Agent Card should expose by default.
One edge case is internal-only agent ecosystems. Teams sometimes assume that because a registry is private, discovery risk is low. It is not. Internal exposure still matters when agents can chain tools, move laterally, or inherit permissions from orchestration platforms. Another edge case is federated ecosystems, where one group publishes a card for partner use. In those environments, the safest approach is to publish the minimum necessary metadata and require explicit approval before any card can be consumed outside its originating trust zone.
Teams should also be careful with cards that advertise multiple auth methods. That can be useful for interoperability, but it can also create downgrade paths or ambiguity about which method is authoritative. The most mature designs pair discovery with short-lived credentials and narrow scopes, then revoke or refresh access based on the current task. For agentic risk patterns, OWASP NHI Top 10 and AI LLM hijack breach are useful references because they show how discovery and trust can be abused together.
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 | A01 | Agent discovery can expose capabilities and endpoints that should not be broadly reachable. |
| CSA MAESTRO | GRC-2 | MAESTRO addresses governance for agent composition, trust, and runtime control. |
| NIST AI RMF | GOVERN | AI RMF governance covers accountability for autonomous systems and their exposure paths. |
Treat Agent Cards as security-sensitive metadata and gate visibility with policy before invocation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
