Separate proposing an action from executing it
An AI agent can choose tools and steps to complete a task. Once a tool can modify data, send a message or take an external action, a wrong answer can become a real-world consequence. That is why agent design starts with the capability you grant it and the conditions under which it may use it.
For example, a support assistant can summarize a ticket and suggest a reply. Sending that reply to the customer is a separate action, with its own permission and review. You do not have to give the agent both at the outset. You can learn from the quality of its suggestions before allowing it to change anything in the system.
Build tools with narrowly scoped responsibility
Prefer a tool that performs a defined action and validates its input over a general-purpose tool that accepts free-form commands. Authorization must be enforced on the service side for the user and the action, even when the agent presents a convincing argument. An instruction in a prompt is not an access-control mechanism.
Minimize the data returned to the tool and the secrets the agent can see. Set limits on time, number of attempts and request size. When an action may be sent more than once, design a way to detect duplicates. Even an agent that followed its instructions can hit a network failure and trigger a retry.
Treat documents as data, not instructions
Prompt injection can appear in a document, a message or a result the agent reads. OWASP describes the risk of mixing external data with instructions and recommends layered defenses. Do not assume that text telling the agent to ignore its instructions, change a destination or reveal information is approval from an authorized user.
A vendor document is a source of information, even if it contains wording that looks like an internal command. The boundary has to be enforced in the mechanism that invokes the tools: allowed destinations, input schemas, authorization checks and audit. Keyword filtering may help in a specific scenario, but it does not replace those boundaries.
Place approval where the impact happens
An approval should show the concrete action: the recipient, the data to be transferred and the consequence. A generic notice at the start of a process does not explain an action that was not yet known at that point. Conversely, requiring approval for every internal call can overwhelm the user and dilute the meaning of the approvals that matter.
- Read-only: check permissions, data exposure and destination.
- Reversible change: limit the scope and record what changed.
- External or significant action: present the result for review before execution.
- Failure or uncertainty: stop and explain, without automatically expanding permissions.
Test before expanding authority
Run a set of scenarios that includes missing information, a hostile document, an unavailable tool and a repeated request. Check not only whether the task was completed, but also which tools were invoked and what information left the system. Define stop conditions and an owner who handles unresolved cases.
It is wise to start with an agent that proposes a plan or a draft for review. Expand its capabilities once there is evidence that the boundaries and approvals work. This is no guarantee against every attack; the goal is to reduce unnecessary authority and make behavior testable.