Safe Tool Discovery for Enterprise AI Agents: Registry, Gateway and Policy

The question behind agent tooling

Give an agent a few APIs, let the model pick which to call, and tool access looks like a solved problem. An enterprise changes the picture. There the catalog holds hundreds or thousands of tools. Some are harmless read-only lookups, others can change customer data or PII, and a smaller group can start financial transactions, reconfigure accounts or run administrative operations. "How does the agent find the right tool?" is the easy question. The harder one is how to guarantee that the agent can see and use only the tools it's allowed to use for this particular user request.

This is what's explored here as a design study. It's a reasoned architecture for a financial-services setting and shouldn't be read as a report of a deployed payments system.

Keep the model out of the security boundary

Production ML teaches a durable lesson: the business-critical process doesn't live inside the model. A model can predict, recommend or classify, while security, validation, business rules, authorization and transaction processing belong to deterministic software outside it. Agents make that rule stricter, not looser, because an agent can take action. An LLM can be a strong reasoner and still be a poor choice for the security boundary of an enterprise system.

A simple financial scenario shows why. A customer asks the agent to look at a recent transaction and say whether a refund has been processed. The agent has to understand the request and use customer lookup and transaction lookup tools, which is routine.

Now alter the request: if the refund hasn't gone through, issue it. The agent is no longer just retrieving information, because it can cause a financial side effect. That small shift motivates the principle everything else rests on:

The agent may reason about an action and suggest it. Whether that action actually runs is decided by the deterministic platform.

The split between reasoning and execution lets a system use what LLMs do well without relying on them for duties they can't perform reliably.

A Tool Registry instead of a giant list

How should the agent learn what tools exist? One option is to hand the model a very long list of tool definitions and let it sort out relevance. That might do for a prototype and fails at enterprise scale. Thousands of descriptions bring context and latency costs, and unrestricted discovery adds security exposure for no benefit.

A better fit is a Tool Registry, an enterprise catalog of capabilities. It holds more than API names and schemas. Each entry carries metadata that the platform can use for discovery, governance and policy decisions:

• business domain, owner and version
• whether the tool is read-only or can write
• risk classification and required capability
• data classification
• input and output schemas
• idempotency characteristics
• audit requirements

The metadata matters most when separating kinds of operations. A transaction lookup is a fairly low-risk read, a refund is a high-impact financial write, and an administrative operation may carry still more risk. Those distinctions can't stay in documentation. They have to exist in the platform so deterministic infrastructure can act on them.

Discovery isn't authorization

This may be the most useful distinction in the whole design: discovering a tool and being authorized to use it are different things.

Discovery answers which tools should be made available to this agent for this task. Authorization answers whether this specific call is allowed right now.

So the registry's metadata powers a filtering step that happens before the LLM ever weighs its options. First the platform settles who the user is, which agent is acting, the tenant, the surrounding context and what the request is trying to achieve. Next it shortlists tools matching that intent, then trims the shortlist using the agent's capabilities, the user's permissions, tenant boundaries, region and risk policies. The model sees only what's left.

That filter still can't be the last line of defense. The model might emit a call nobody expected, misread the user's intent, or be steered by prompt injection. So every invocation passes through a controlled Tool Gateway on its way to the underlying enterprise API.

In concept, the gateway evaluates a bundle of facts together (who the user is, which agent is calling, what's being requested, on which resource, with what parameters, in what context) and applies the matching policy.

Authorize the intent, not just the tool

The refund example exposes another point. Authorization can't depend only on which tool is being called. It has to consider the intent and the action that results.

Checking a refund status and starting a refund aren't the same capability: one is a read and the other is a financial side effect. The platform should model them explicitly. A request classified as a refund-status inquiry may reach customer and transaction lookup tools, but that classification doesn't quietly grant permission to call the refund operation. Even if the model wrongly decides a refund should be issued, the authorization layer can compare the action actually requested with the permitted intent and reject it.

Security thinking shifts here from asking whether an agent has access to the refund API to asking whether this user, agent, intent, resource and action are permitted in this context.

When half a workflow fails

Once an action is permitted, a second problem arrives: what if one part of a workflow succeeds and another fails? Suppose the refund goes through and the confirmation email doesn't. Restarting the whole agent workflow could execute the refund twice.

A safer pattern makes the side effect a step in a durable workflow. Authorization approves the refund, the refund API executes, and the success gets stored. That stored outcome emits a RefundCompleted event, which kicks off notifications. A failed email then triggers a retry of the notification alone, and the financial operation isn't repeated.

Having an LLM in the system doesn't retire the classic enterprise toolkit. Retries and deduplication, circuit breakers and compensating actions, idempotent operations, durable state and event-driven processing all still apply. Agents can contribute to deciding what should happen, while deterministic infrastructure keeps hold of the critical state changes.

Approvals belong to policy

The LLM also shouldn't decide when a human must approve something. That's a policy matter. An organization might let refunds below a threshold run automatically and require sign-off above it, always demand approval for administrative operations, and add controls for transactions with unusual destinations or elevated risk. The model can flag that an action may be needed. The policy system decides whether approval is required, and the Tool Gateway enforces the decision. Governance benefits as well, since the rules are explicit, reviewable, versioned and auditable and don't hide inside a prompt.

Control plane and execution plane

Worked through these scenarios, the design looks far less like a simple User to LLM to Tools pipeline and far more like an enterprise governance platform. It splits naturally into two areas.

The Control Plane is where the organization writes its rules. It covers the agent catalog, the Tool Registry, capability definitions, risk classes, authorization and approval policies, and general governance settings.

The Execution Plane is what runs live. It contains the gateways for APIs and agents, the agents themselves, discovery that's already filtered, enforcement of policy, exchange of credentials, the tools being executed, workflow state and the stream of audit events. Rules can be managed centrally while the enforcement sits nearer to where workloads run.

That separation matters at scale. With hundreds or thousands of agents and a huge number of tools, no one wants every authorization check to wait on a single central service. Policies are governed in one place, while enforcement points are distributed and policy data is cached or replicated where appropriate.

Evaluating actions, not only answers

The design ties neatly to enterprise ML while adding a new class of problems. Traditional ML cares about accuracy, data quality, drift, latency, security, monitoring and operational reliability. Agents keep all of those and add the evaluation of actions.

A correct final answer doesn't settle it. Reviewers also need to know if the agent picked the right tool and passed the right parameters, stayed within authorization limits, avoided actions it wasn't allowed to take, followed the intended workflow, asked a human for approval when that was needed, and produced the side effects that were expected. Evaluation moves from scoring answers to scoring actions.

The principle that holds

One rule keeps returning: treat the LLM as an untrusted decision-making component and never as the security boundary. The agent may reason, discover relevant capabilities and propose actions. Deterministic enterprise infrastructure decides what the agent may do, which resources it can touch, which parameters are acceptable, whether human approval applies, how side effects run safely and how the whole process is audited.

That's the real architectural challenge of agentic AI. Getting an agent smart enough to call a tool is the easy bit. A platform on which thousands of agents act for millions of users, with identity, authorization, business rules and operational reliability still under control, is the hard bit.