Curation is an authorisation control, while hiding is only a presentation choice. If a tool is merely hidden, it may still exist in the wider environment and be recoverable through other paths or future requests. If it is filtered by policy at discovery time, it is never presented as available to that agent in the first place.
Why curation changes the access decision, not just the user interface
Tool curation is a policy decision about what an agent is allowed to discover and invoke. Hiding a tool only changes what is shown in a particular interface or prompt, so it can reduce clutter without changing the underlying access model. If the tool still exists elsewhere, hiding does not prevent other routes from surfacing it later.
The practical difference is that curation narrows the agent’s effective authority before it can reason about the tool, while hiding leaves the authority in place and relies on presentation alone. That distinction matters when the same agent can be re-run, retried, or connected through another integration path.
Why hiding is a weaker control than policy filtering
Hiding is fragile because it depends on a specific view. A model may still learn about the tool from prior context, other menus, documentation, indirect references, or later requests. If the control is only cosmetic, the tool may remain reachable even though it was not listed in the first interaction.
Policy-based curation is stronger because discovery is filtered up front. The agent never receives the tool as an available option, which reduces accidental use, prompt-driven probing, and inconsistent behaviour across sessions or channels. For teams governing tool access, that makes the control auditable rather than merely presentational.
What changes in governance and operational practice
Once curation is treated as authorisation, you need to manage it like any other access decision. That means clear ownership for which tools are eligible, what conditions allow discovery, and what telemetry proves the filter is being enforced consistently. If a tool is hidden but not excluded by policy, you still need to assume it may be reachable through another path.
This is where the distinction between presentation and control becomes important. A curated set can be reviewed, tested, and revoked. A hidden set can only be assumed absent in the current interface, which is not the same as absent from the environment.
Risk and Threat Considerations
Hidden tools create a false sense of restriction. If the underlying capability still exists, an agent or user may rediscover it through alternate prompts, different clients, inherited context, or future integrations, turning a cosmetic change into an access-control gap.
Failure mechanism: The system suppresses display rather than enforcing discovery-time policy, so the tool remains available in the broader environment and can reappear through another route.
Impact: An agent may invoke a capability that the operator believed was removed, which increases the chance of unintended action, privilege creep, and inconsistent enforcement across channels.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Curation vs hiding changes what tools an agent may access and invoke. |
| Recommendation — Enforce policy-based tool discovery to prevent unauthorized agent access. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Filtering tools at discovery time is an access decision, not just a UI change. |
| IA-9 — Identification and Authentication (Service and Device Authentication) | Tool access often depends on authenticated service-to-service paths beyond the UI. | |
| Recommendation — Apply access enforcement so disallowed tools are never exposed to the agent. Authenticate service access so hidden tools cannot be reached through alternate paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Managed Access Control | The question is about controlling what an agent can discover and use. |
| Recommendation — Manage access rules centrally so discovery reflects real authorization. | ||
| OWASP ASVS | V8 — Authorization | The distinction is whether a capability is actually authorised, not merely visible. |
| Recommendation — Verify that authorization decisions block access instead of only hiding features. | ||
Practitioner Guidance
What to verify: Test the agent’s tool list from the discovery layer, not only the user interface. If the tool can still be enumerated or reached after you “hide” it, the control is not equivalent to curation.
Decision rule: If the goal is to prevent use, enforce policy at discovery and authorization time. If the goal is only to simplify the interface, treat hiding as a usability measure and not as a security boundary.
Practitioner takeaway: The safe mental model is that curation removes authority from the agent’s reachable set, while hiding only removes visibility from one view, so the latter should never be treated as a substitute for access control.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?