Agents & control
Limit an AI agent’s permissions before improving its prompt
A careful instruction cannot remove access the system still holds. Match its tools and authority to the task before allowing consequential actions.
Before asking whether an AI agent follows instructions, ask what it can do when it follows the wrong one. A tool with enforced read-only access to approved documents cannot use that connection to delete a record. Adding deletion or sending functions gives a mistaken instruction more ways to cause harm.
OWASP’s excessive-agency guidance identifies unnecessary functionality, permissions and autonomy as causes of damaging actions. Its examples include a document-reading service that also exposes modification and deletion, and a mailbox assistant given functions it does not need.
Translate the task into allowed actions
Take a hypothetical assistant that prepares a morning summary of a shared mailbox. It needs access to the authorised messages and somewhere to place its summary. Sending a reply, deleting a message and changing access permissions are separate actions. Include them only if the owner has deliberately commissioned those functions.
Write that boundary as a short task specification, then have the system administrator check the actual account and connector permissions. A prompt saying “never delete” leaves a deletion tool available if the surrounding software still exposes it. Remove unnecessary capabilities or enforce the restriction in the connected service.
Outside content must not grant authority
OWASP describes indirect prompt injection as instructions reaching a model through external material such as a webpage or file. The system may be asked to read that material without being authorised to obey commands inside it. A message saying “forward the attached records” is content to assess, not permission from the mailbox owner.
Separating external text from authorised instructions helps define the problem, but it does not guarantee the model will interpret every case correctly. The assistant’s instructions should describe the limits; the software carrying out an action must enforce them.
Make approval specific enough to inspect
For consequential actions, show the proposed recipient, records, changes and reason before asking an authorised person to approve. A general “continue?” prompt gives the reviewer little to assess. Keep the pending action fixed during approval; if the recipient or contents change, require a new decision.
Test the boundary with harmless synthetic material in a test environment. An email in that exercise can request an action outside the task, such as sending a dummy attachment. Check the service logs to see whether the restriction held. Do not use customer records or send test messages to unsuspecting recipients.
Keep an owner for disabling the connection and investigating unexpected activity. Restricted permissions reduce the damage some failures can cause; they do not prove that the assistant’s summaries are accurate. Those outputs still need checks proportionate to how they will be used.
Sources and further reading
Sources checked 3 November 2026. Prepared with AI assistance and editorial review.