Who is accountable when tool discovery leaks capabilities an agent should not see?

Accountability sits with the team operating the discovery layer and the governance controls around it. If discovery reveals tools outside an agent’s scope, that is a policy failure, not just an application bug. Security, platform, and identity owners should define discovery rules, logging, and review processes so visibility is enforced as a governed control.

Why This Matters for Security Teams

tool discovery is not a neutral convenience feature. In agentic environments, discovery determines what an agent can even attempt, so a leak is effectively an authorization exposure. If an agent can enumerate tools outside its intended scope, it can combine them, probe boundaries, and move from harmless visibility into unsafe execution. That makes the discovery layer part of the trust boundary, not just the user interface.

This is why current guidance from NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 treats governance, access control, and runtime context as inseparable. NHI Management Group’s 52 NHI Breaches Analysis shows how visibility failures quickly become compromise paths when identities, secrets, and permissions are not tightly governed. The operational mistake is assuming discovery only informs the agent; in practice, it shapes the attack surface.

In practice, many security teams discover tool overexposure only after an agent has already queried or chained into a capability that should never have been visible in the first place.

How It Works in Practice

Accountability should follow control ownership. If the discovery service, tool registry, or capability broker exposes unauthorized tools, the team operating that layer owns the defect, while security and identity owners own the policy model and review process. The right control pattern is to treat discovery as a governed decision point: the agent receives only the tool descriptors it is allowed to know, and each descriptor is filtered through policy at request time.

That usually means combining workload identity, policy-as-code, and least-privilege scoping. A discovery request can be evaluated using context such as agent identity, task intent, environment, time, and data sensitivity. If the agent is authenticated as a workload rather than a human, the system can bind discovery to that workload identity and return only approved tools. This aligns with the direction described in the Ultimate Guide to NHIs and with the runtime authorization ideas in NIST AI Risk Management Framework.

• Define the discovery boundary explicitly: what the agent may see, not just what it may execute.
• Log every discovery response, denied capability, and policy decision for review and incident response.
• Use short-lived, task-scoped credentials so discovery does not reveal durable access paths.
• Separate tool catalog maintenance from agent authorization so stale entries do not become accidental exposure.

Current practice also benefits from correlating discovery logs with tool invocation logs, because visibility leaks are often the first step before misuse. The CSA MAESTRO agentic AI threat modeling framework and the OWASP Agentic AI Top 10 both reinforce that exposed tool metadata can become a planning aid for lateral movement or privilege chaining. These controls tend to break down when tool catalogs are cached broadly across tenants, because the cache itself becomes a secondary disclosure channel.

Common Variations and Edge Cases

Tighter discovery controls often increase operational overhead, requiring organisations to balance safer visibility against developer friction and slower tool onboarding. That tradeoff is real, especially in multi-agent systems where teams want reusable registries and fast experimentation. Best practice is evolving, but there is no universal standard for this yet.

One edge case is intentionally shared tooling. Some agents need broad awareness for coordination, but awareness should not equal eligibility. Another is prompt-injected or compromised agents that try to enumerate capabilities as reconnaissance before making a malicious call. In those cases, discovery should be treated as sensitive telemetry and reviewed like an access event, not a convenience feature.

Another exception is delegated administration, where platform teams manage the registry but application teams own agent policy. In that model, accountability is split but not diluted: the registry team is accountable for what is exposed, while the product team is accountable for how the agent scope is defined and enforced. NHIMG’s Analysis of Claude Code Security and CoPhish OAuth Token Theft via Copilot Studio illustrate how quickly agent visibility issues become control failures when governance is not embedded at the discovery layer.

Related resources from NHI Mgmt Group

• Where does cross-environment agent discovery fit in an IAM programme?
• Who is accountable when a coding agent leaks secrets or makes an unsafe tool call?
• Why is single-provider AI agent governance not enough for enterprise security?
• How can organizations manage the risk of credential leaks in MCP frameworks?