An agent that drafts a response and an agent that changes a customer record have different responsibilities. Before connecting tools, describe exactly what the agent is allowed to accomplish—and who remains accountable for the result.
Write a small operating contract
Start with a single task. For example: read an incoming service request, find the relevant support guidance, and prepare a suggested reply for a person to review. List the inputs, the intended output and the conditions under which the agent must stop.
Make the excluded actions explicit. In this example, the agent does not send the reply, approve a refund or change account access. If those capabilities become necessary later, review each as a separate permission and operating decision.
Enforce permissions outside the model
OWASP identifies prompt injection as a risk when untrusted input influences a model’s behaviour. Retrieved documents and tool output can carry such input; retrieval alone does not remove the risk. OWASP recommends limited privileges and human approval for high-risk actions.
Design the surrounding application to check identity, tenant boundaries, permitted operations and action parameters independently of the model. Do not give a tool broad administrator access simply because the prompt tells the agent to behave carefully.
- Provide only the tools and records needed for the task.
- Validate proposed action parameters before execution.
- Keep credentials in the execution service, outside prompts and retrieved content.
- Require meaningful review before consequential changes.
Make approval a decision someone can assess
An approval screen should show what will change, which record or recipient is involved and the evidence used to propose it. Give the reviewer a way to edit or reject the action. ‘Approve agent’ is too vague when the actual effect is a payment, access change or external message.
For the service-request example, present the original request, the cited guidance and the draft response together. The reviewer should be able to judge the proposed reply without reconstructing the agent’s entire conversation.
Test the boundary and the recovery path
Create examples that include missing information, conflicting records, malicious instructions in a document and tool failures. Check whether the system stops safely, asks for clarification or hands the work back to a person.
Define how to pause the agent, revoke its access and investigate a failed action. Keep an appropriately scoped record of the proposed operation, the approval and the execution result. Decide what to retain and who can read it; operational logs should not become an uncontrolled copy of customer data.
A USEFUL NEXT STEP
Start with an agent that proposes a useful result within a narrow task. Add execution authority only when the permissions, review experience and recovery process are ready for it.
Further reading
Source links checked on 14 November 2026.