An AI agent becomes more consequential when it can use tools to change business systems. Searching a knowledge base, updating an address and issuing a refund require different authority. Giving the agent one broad credential makes those differences difficult to enforce and creates a larger impact when it misinterprets a request.
Start with a list of permitted operations, not a general instruction to "be careful." The model can propose an action, but the system executing the action must decide whether it is authorized. A prompt is not a substitute for a permission check.
Divide tools by their business effect
Separate read-only operations, reversible updates and consequential changes. A customer lookup should not share the same function or credential scope as a refund. Prefer narrow tools with explicit parameters over a general database query or unrestricted HTTP client.
The OWASP guidance on excessive agency describes risks from excessive functionality, permissions and autonomy. OpenAI's agent safety guidance discusses controls for tool use and untrusted inputs. The implementation still needs policies specific to the business workflow.
Worked example: a customer-support refund
Imagine a hypothetical support assistant that can find an order and prepare a refund request. It may read the order's status and the published policy available to the current support user. Its preparation tool returns the order, amount, reason and proposed payment operation without executing it.
An authorized reviewer sees that exact proposal. Approval creates a short-lived authorization for the specified order, amount and action. If the amount or destination changes afterward, the system requires a new decision. Approval of one proposal must not become permission for an arbitrary later tool call.
The execution service checks the current user's authority, the order's latest state and whether the approved operation has already run. It uses an idempotency key for retries. If the payment provider times out, it reconciles the existing operation before attempting another refund.
Carry the user's access boundaries through execution
An agent acting for a branch employee should not gain access to other branches through a powerful service account. Pass an authenticated context to the tool service, and enforce record scope there. Do not accept a branch ID or an administrator flag generated by the model as proof of authorization.
Validate parameters against allowed values and current state. Restrict exported fields and result size. A lookup tool returning every customer record can create unnecessary disclosure even when the agent only needed one order number.
Treat retrieved instructions as untrusted content
Emails, documents and web pages may contain text asking the agent to ignore its rules or invoke a tool. Their contents can supply facts for a task, but cannot grant permission. Keep tool policy outside the retrieved text and enforce it independently.
Test a document that asks the assistant to send data to an external address, a user requesting another customer's records and an expired approval token. The expected result is a denied operation with a useful explanation, not merely an assurance that the model recognized suspicious wording.
Make action history and recovery practical
Record the actor, requested operation, approval reference, tool result and resulting business identifier. Keep sensitive payloads out of routine logs. Review denied actions as well as successful ones, because repeated denials can reveal either attempted misuse or a badly designed workflow.
Start the pilot with read-only tools and introduce write operations individually after evaluation. Define how operators stop the workflow and resolve uncertain external effects. A useful agent can reduce repetitive work while remaining inside the authority and accountability of the business process it serves.
Primary references
Related reading
Define controlled tool workflows with our AI solutions team.