How do you prevent an agent from calling unauthorized tools?

You prevent an AI agent from calling unauthorized tools by enforcing permissions in trusted application code before any tool call is executed.

The model may suggest a tool, but it should never be the final authority on whether that tool is allowed.

Do not expose every tool to every agent

The safest starting point is to give each agent only the tools it actually needs.

For example, a support agent may have:

• get_customer
• get_order
• create_support_ticket

but not:

• delete_customer
• change_permissions
• deploy_production

This follows the principle of least privilege.

Filter tools before the model sees them

A runtime can build the available tool list dynamically based on:

• user identity
• role
• tenant
• workflow
• current task
• environment
• risk level

For example:

Support role

Available:

• view_customer
• view_orders

Unavailable:

• issue_large_refund
• delete_account

If a tool is not available to the model, accidental selection becomes less likely.

Runtime authorization is still required

Tool filtering alone is not enough.

Even if the model somehow requests a restricted tool, the execution layer should independently verify:

• who is making the request
• which tenant they belong to
• whether the tool is allowed
• whether the requested action is permitted

If authorization fails, execution must stop.

Authorization should be deterministic

Permissions should come from trusted systems such as:

• role-based access control
• policy engines
• identity claims
• tenant configuration
• application permissions

The model should not decide:

“This user probably looks like an admin.”

Authorization must be enforced by code.

Check permission at execution time

Permissions may change while an agent workflow is running.

For example, a user may lose access to a tool after the workflow started.

So authorization should be checked when the tool is actually called, not only when the session begins.

Scope permissions to the specific action

A user may be allowed to use a tool only under certain conditions.

For example:

A support agent may:

• issue refunds up to ₹5,000

but not:

• issue refunds above ₹5,000

The tool layer should enforce the limit.

Access control should consider both:

Can this user call this tool?

and:

Can this user perform this specific action with these arguments?

Separate read and write permissions

A user may be allowed to inspect data without modifying it.

For example:

Allowed:

• get_customer
• get_invoice

Restricted:

• update_customer
• issue_refund

Separating these tools makes policy enforcement clearer.

Inject trusted identity outside the model

Sensitive authorization context should come from the runtime.

For example:

Model provides: order_id = O123

Runtime provides:

• user_id
• tenant_id
• role

The model should not be allowed to invent or override these identity fields.

Enforce tenant boundaries

In multi-tenant systems, an agent must not access another tenant's tools or data.

The runtime should ensure that:

• tool credentials belong to the current tenant
• resource IDs are checked against the tenant
• queries are tenant-scoped
• cross-tenant calls are rejected

Tenant isolation should not depend on the model remembering to include the correct tenant filter.

High-risk tools may require approval

Some authorized tools may still require human approval.

Examples include:

• deleting production data
• changing access permissions
• issuing large refunds
• transferring money
• deploying to production

A workflow may allow the agent to prepare the action but block execution until approval is given.

Use separate credentials for different capabilities

An agent should not use one highly privileged credential for every tool.

For example:

Read tool credential: read-only database access

Write tool credential: limited update access

Admin tool credential: available only through approved workflows

This reduces the impact of a compromised or misused tool.

Tool schemas can reduce misuse

A narrow tool is easier to authorize than a generic one.

For example:

Safer:

get_order(order_id)

Riskier:

execute_arbitrary_database_query(sql)

Specific tools make the allowed capability easier to understand and enforce.

The tool registry can include permission metadata

A tool catalog may store metadata such as:

• required role
• allowed tenants
• read or write
• risk level
• approval required
• environment

The runtime can use this metadata when deciding whether the tool can be exposed or executed.

Denied calls should fail clearly

If the agent attempts an unauthorized call, the runtime should return a structured result such as:

• permission_denied
• approval_required
• tool_not_available

The agent should not repeatedly retry the same forbidden action.

It should choose an allowed alternative or stop.

Prompt instructions are not enough

Telling the model:

“Do not call restricted tools.”

is useful guidance, but it is not security enforcement.

Models can make mistakes, misunderstand instructions, or be influenced by malicious input.

The security boundary must exist outside the model.

Audit sensitive tool calls

For important actions, log:

• user
• tenant
• agent run
• selected tool
• arguments
• authorization decision
• approval status
• result

This makes unauthorized attempts and policy failures easier to investigate.

A practical authorization flow

A secure tool call may work like this:

1. Agent proposes a tool call.
2. Runtime checks whether the tool is available to this agent.
3. Runtime verifies user and tenant permissions.
4. Arguments are checked against policy.
5. Approval is requested if required.
6. Authorized credentials are attached.
7. Tool executes.
8. Result and authorization decision are logged.

In short

Preventing unauthorized tool calls requires deterministic permission enforcement outside the model.

Use least-privilege tool sets, filter tools by user and tenant, validate authorization again at execution time, keep trusted identity outside model control, enforce action-specific limits, require approval for high-risk operations, and audit sensitive calls.