Day 14/90: Your AI Agent Has a Tool Permission Problem — Not Just a Tool Calling Problem

I explored why defining input and output schemas is not enough to make AI tool calling reliable.

But there is another important question:

Even if a tool call is valid, should the agent be allowed to execute it?

Imagine an AI assistant connected to a database.

It needs to retrieve customer information, but its database credentials also allow it to update and delete records.

The model selects the correct tool. The arguments pass schema validation. The backend accepts the request.

Yet the agent has more permissions than its task requires.

The OWASP Top 10 for LLM Applications (2025) identifies this risk as LLM06: Excessive Agency.

This means tool reliability is not just about selecting the correct function or validating its arguments.

It is also about controlling what that function is allowed to do.

Consider a customer support agent with database access.

Instead of providing unrestricted database access:

Most importantly, the model should never be the final authority deciding whether an action is permitted.

But before execution, the backend should check:

If any required condition fails, reject the operation.

Valid arguments do not automatically mean authorized actions.

Is this agent allowed to perform the requested action?

Under what conditions can the action proceed?

A production-ready agent should not receive more authority than its task requires.

Give agents capabilities, not unrestricted authority.

When building an AI agent with database or API access, where should authorization be enforced: inside the agent's instructions, the tool implementation, or the downstream backend?

I'd argue that the backend must enforce it independently.