Tool curation for AI agents cuts LLM context overhead

At a glance

What this is: This is an analysis of policy-based tool curation for AI agents, showing that returning only authorised tools can cut LLM context overhead and narrow the agent’s usable discovery surface.

Why it matters: It matters because IAM teams now have to govern not just whether an agent can act, but which tools it can even see, which changes how least privilege, auditing, and delegated access are enforced.

Context

AI agent tool curation is a governance problem before it is a model-optimization problem. When every connected tool is exposed to the model, the agent inherits a broad discovery surface, larger prompts, and more choices than its role actually requires.

The core control shift is simple: authorised tools should be determined before the agent reaches the model, not after the model has already seen the catalog. That matters for NHI governance because the effective access boundary is the tool list itself, not just the action that follows.

In practice, this creates a new identity control point around AI agent authorisation: policy decides what an agent may discover, and the model only sees the subset that matches its purpose.

Key questions

Q: What breaks when AI agents discover tools at runtime instead of using hardcoded lists?

A: Hardcoded lists assume the tool set is stable enough to be embedded in code. That breaks when services change frequently, environments differ, or new tools appear without redeploying the agent. Runtime discovery shifts the trust boundary to the registry, so misclassified or overexposed tools can be selected immediately.

Q: Why do policy-based tool sets improve AI agent governance?

A: They move authorisation to discovery time, before the model can choose from the enterprise catalog. That reduces unnecessary context, aligns tool visibility with role, and gives security teams a clearer boundary to audit. The practical benefit is that a policy can limit what the agent can even consider, not just what it is later allowed to execute.

Q: How do security teams know whether curated tools are actually helping?

A: Look for three signals: fewer tools returned per agent, cleaner audit trails linking policy to execution, and lower variance between the tools an agent is allowed to see and the tools it actually uses. If the catalog remains broad or the policy decisions are not logged, the governance model is still too loose to support least-privilege control.

Q: What is the difference between tool curation and simply hiding tools from the model?

A: 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.

Technical breakdown

Why large tool catalogs inflate model context

Tool definitions are not just labels. In function-calling systems and MCP, each tool can carry a name, description, schema, parameters, and sometimes usage guidance. When hundreds of tools are exposed, the model must process a much larger instruction surface, even if only a small subset is relevant. That raises token consumption, can weaken cache efficiency when tool catalogs change, and increases the chance that the model evaluates irrelevant options. The architectural issue is not only efficiency. A broad catalog also makes tool discovery itself a governance event, because visibility becomes equivalent to availability in the model's working context. See the MCP Security Guide.

Practical implication: Prune tool exposure before the request reaches the model so irrelevant tools never enter the agent’s context.

How policy-based tool discovery works for AI agents

Policy-based curation moves access control from the prompt to the authorization layer. The enterprise assigns an agent a named policy tied to role and purpose, then the tool broker returns only the tools approved for that policy. This is closer to entitlement filtering than to telling the model to ignore things it already received. The distinction matters because hidden tools are still present in memory if they are merely omitted from use instructions, but they are absent from the model's available choices when filtered at discovery time. That makes the policy boundary explicit, auditable, and aligned to delegated authority rather than raw catalog size. See the AI Agent Authorisation Guide.

Practical implication: Bind each agent to a role-specific policy so tool availability is enforced at discovery time.

Why auditability changes when the tool set is curated

A curated tool set does more than reduce clutter. It creates a cleaner record of what an agent was allowed to see, choose, and execute. That is important for AI governance because the audit trail can distinguish policy decisions from model behaviour. If a tool was never returned, the question is not why the agent ignored it but why the policy excluded it. If the tool was returned and used, the record can show the agent, policy, result, and time. This is a more defensible governance model than post-hoc analysis of a model that had access to the entire enterprise catalog. See the AI Agent Observability, Audit and Incident Response Guide.

Practical implication: Log policy decisions alongside tool selection so reviewers can reconstruct both authorisation and execution.

NHI Mgmt Group analysis

Tool discovery is now an access-control decision, not just a usability choice. When a model receives only the tools its policy authorises, the governance boundary moves upstream from execution to discovery. That is a stronger identity pattern because the agent cannot select what it never sees, and the enterprise can reason about entitlement before action. The practitioner takeaway is that tool visibility should be treated as part of authorisation design, not as a UI convenience.

Overexposed tool catalogs create a form of governance drag. Large inventories do not only add tokens; they also blur which tools are truly in scope for a given agent. That makes review, monitoring, and exception handling harder because the catalog no longer reflects a role-based boundary. The implication is that catalogue size is a governance variable, not just an engineering one.

Policy-based tool curation is a practical expression of least privilege for AI agents. The article’s model fits the same access logic used across NHI governance: expose only what the identity needs for its current purpose, and no more. In agentic systems, the difference is that the policy must control discovery as well as execution, otherwise the model still carries unnecessary authority into the session. That is why curated tool sets belong in agentic AI identity programmes.

Observed token savings are secondary to the control model. Reducing context is useful, but the more durable benefit is that the organisation can explicitly tie an agent’s tool surface to role, purpose, and policy. That makes authorisation review easier and reduces the chance that broad catalogs become invisible standing access. The practitioner conclusion is to measure the governance effect first and the token effect second.

From our research library:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: Agentic AI Identity Guide

What this signals

Tool visibility will become a standard governance boundary for agentic programmes. Teams that treat tool catalogs as static infrastructure will miss the control point introduced here: who can discover which tools, under what policy, and for what purpose. The next phase of agent governance is not just about action approval, but about reducing the discoverable surface before the model reasons over it.

Identity programmes will need to align authorisation, audit, and prompt efficiency. A policy that returns only approved tools can reduce context noise and tighten oversight at the same time. The control value is larger than the token savings because it gives practitioners a defensible way to prove that the agent never saw out-of-scope capabilities in the first place.

For practitioners

• Define tool access by role and purpose Create named policies that map each agent to a specific business function, then allow only the tools required for that role.
• Filter tools before model discovery Return only approved tools at request time so the agent never receives the full enterprise catalog as available choices.
• Separate catalog size from authorisation scope Treat tool inventory growth as a governance issue and review whether newly added tools expand the agent’s discoverable surface unnecessarily.
• Log policy, selection, and execution together Record the agent identity, policy decision, returned tool set, action taken, and outcome in a single audit trail.

Key takeaways

• AI agent tool curation narrows the discovery surface so an agent only sees the tools its policy allows, rather than the full enterprise catalog.
• The main governance gain is stronger least privilege at discovery time, which makes authorisation easier to audit and reason about.
• Token savings are real, but the more important outcome is a clearer separation between policy scope, tool visibility, and execution.

Related NHI Mgmt Group resources: AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Agentic AI Identity Guide · MCP Security Guide

Key terms

• AI Agent Tool Curation: AI agent tool curation is the practice of exposing only the tools an agent needs for a specific role, purpose, or policy. It moves authorisation earlier in the flow so the agent never sees an unrestricted enterprise catalog, reducing excess context and limiting the chance of unauthorized selection.
• Tool discovery: The process by which an AI agent learns what functions or actions are available to it at runtime. It becomes a security issue when discovery is broader than entitlement, because the agent can map capabilities even when it should not be able to use them.
• Policy-Based Access Control: Policy-based access control grants or denies access using rules that evaluate context, signals, and identity state at decision time. It is more adaptive than static role assignment, but only if the policy engine receives accurate runtime inputs and can enforce them across systems.
• Model Context Overhead: Model context overhead is the extra token and processing cost created by sending unnecessary tool definitions, instructions, and schemas to an LLM. In agent systems, large catalogs inflate this overhead and can dilute the model’s focus even when the tools are never used.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.