Teams often mistake capability discovery for trust. In practice, a published agent card or server description only tells you what might be done. It does not prove the requester is authorised, the action is safe, or the delegation path is bounded. Governance must sit above discovery.
Why This Matters for Security Teams
Capability discovery in agent protocols is often treated like a trust signal, but it is only an inventory signal. A tool, function, or agent card can describe what is available without proving who can invoke it, under what context, or whether the delegation chain is bounded. That matters because autonomous and semi-autonomous agents can combine discovered capabilities in ways the original designer did not anticipate.
Security teams commonly over-index on the published surface and under-index on runtime authorisation. The real control question is not whether an agent can see a capability, but whether it can use it safely in the current context, with the right identity, scope, and expiry. That is why governance must sit above discovery, not inside it. Current guidance in OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward runtime controls, not catalog trust.
NHI Management Group research shows how often teams miss the deeper issue: only 1.5 out of 10 organisations are highly confident in securing NHIs, even though identities and secrets are the control plane behind most automated access. In practice, many security teams discover dangerous capability exposure only after an agent has already chained tools, not during intentional design review. See Ultimate Guide to NHIs for the broader identity and secrets context.
How It Works in Practice
Capability discovery should be treated as metadata for orchestration, not as an authorisation decision. In agent protocols, a server may advertise tools, schemas, or actions, but the actual security boundary must be enforced at invocation time through workload identity, policy evaluation, and scope-limited credentials. That means the agent proves what it is, the system evaluates what it is trying to do, and the decision is made in real time.
A practical model usually includes:
- NIST AI Risk Management Framework style governance for ownership, accountability, and monitoring.
- Workload identity for the agent or runtime, such as SPIFFE-style identities or OIDC-backed service identities, so the requester is cryptographically known.
- Just-in-time, ephemeral secrets issued per task and revoked on completion, rather than long-lived credentials that survive beyond the use case.
- Policy-as-code at request time, so the decision can account for tool sensitivity, data classification, user delegation, and environment context.
This is where current NHI guidance and agentic AI guidance converge. The NHI Lifecycle Management Guide is useful for thinking about issuance, rotation, and offboarding, while the CSA MAESTRO agentic AI threat modeling framework focuses attention on tool chaining, control boundaries, and action risk. The common mistake is to whitelist capabilities once and then assume discovery equals approval.
In practice, discovery should feed policy decisions, logging, and review workflows. It can tell a controller that a tool exists, but it cannot prove the call is safe, necessary, or authorised for the current context. These controls tend to break down when agents operate across multiple tenants or federated tool ecosystems because policy context, identity binding, and delegation scope become inconsistent across boundaries.
Common Variations and Edge Cases
Tighter runtime control often increases orchestration overhead, so security teams have to balance safer delegation against developer friction and operational latency. That tradeoff becomes sharper in multi-agent systems, where one agent discovers another agent’s tools, or where a planner delegates tasks to multiple executors with different trust levels.
There is no universal standard for how much discovery metadata should be trusted yet. Best practice is evolving, but current guidance suggests treating published capability information as advisory only. In high-risk environments, teams should require separate approval for privileged tools, restrict discovery to a bounded catalogue, and validate every invocation against policy, not against the agent card alone.
Edge cases appear when agents are embedded in CI/CD, ticketing, customer support, or code-assist workflows. Those environments already contain broad automation and weak human review, which makes it easy for discovered capabilities to become hidden escalation paths. The NHIMG OWASP NHI Top 10 highlights this class of risk, and AI LLM hijack breach shows why exposed capabilities become dangerous once an agent can be steered off intent.
Where autonomy is low and tool use is tightly sandboxed, discovery can safely improve usability. Where autonomy is high, discovery must be assumed hostile until runtime controls prove otherwise.
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 | Discovery can expose tools, but runtime authorisation must stop unsafe agent actions. |
| CSA MAESTRO | T1 | MAESTRO addresses tool access, delegation, and agent control boundaries. |
| NIST AI RMF | AI RMF supports governance, monitoring, and accountability for autonomous agent behaviour. |
Use AI RMF GOVERN and MAP functions to tie discovery metadata to accountable runtime controls.
