Derive AI tools from a bounded task

Start by describing the required work result. This determines the functions an AI assistant needs. Having access to a ticket system is not sufficient reason to expose its entire functionality to the model.

Translate a task into functions

In this fictional example, the task is to create an internal reply draft for ticket T-62. The ticket belongs to customer account K-18 and references a project. The assistant may read the incoming request, query the associated project status and save a draft. Sending is outside this task.

The tool names are our own example labels. This matrix describes the planned scope:

OWASP recommends limiting tool functions and their permissions to what is necessary. A dedicated, narrowly defined call is easier to constrain than a general tool that executes arbitrary commands or uses arbitrary destination addresses.

Check context on the server

The server determines the permitted customer context from the signed-in person and the verified ticket. A customer identifier freely supplied by the model must not expand that context. The project must also demonstrably belong to the permitted case.

Every tool call checks permissions and allowed fields again. The visible tool list helps guide behaviour; actual access control remains in the service performing the operation. A well-formed argument or an instruction inside ticket text grants no additional rights.

Pass results on as states

A successfully saved draft requires confirmation from the ticket system. Generated text alone does not prove storage. If the write fails or its outcome remains unknown, the interface shows that state. It must not display it as a message sent to the customer.

If sending is added later, it is a separate extension with defined recipients, permissions and approvals where needed. An additional model request does not enable it incidentally.

Test the boundaries before use

Check the permitted workflow through to the saved draft, as well as a different customer context, a sending request inside ticket text and a failed save. The expected outcomes are an internal draft, denied access, no sending and a visible error state, respectively.

For each case, record permitted functions, the expected system state and the actual result. This makes it possible to see whether the technical boundary respects the task even when the model proposes an inappropriate call.

Sources

• OWASP — LLM06:2025 Excessive Agency