Prompt Filters Cannot Secure an AI Agent—Put Permissions Outside the Model

When an AI agent reads external content, reduce prompt-injection risk by treating that content as data and checking consequential tool calls in code outside the model. OWASP’s prompt-injection guidance calls for validating proposed tool arguments against the caller’s permissions, limiting tool access and requiring approval for high-risk actions. A suspicious-text filter can help identify an attack, but its verdict cannot authorize a tool call.

Let the model propose an operation; let a separate execution component decide whether it may run. That decision needs the authenticated caller, the authorized task, the requested tool, its target and its arguments. Application policy must supply the permission. A claim inside a retrieved page, document or model response cannot supply it.

Why suspicious-text filters leave a gap

Filters may catch an obvious command to ignore prior instructions. They have a harder job when external material presents an unauthorized action as a normal part of the task. In their analysis of contextual manipulation, Sahar Abdelnabi and Eugene Bagdasarian argue that separating data from instructions can miss attacks that misrepresent an information flow, while tighter separation can obstruct legitimate behavior. A clean filter result therefore gives the execution component no reason to relax its checks.

Consider a hypothetical request to summarize a customer document. An attacker inserts an instruction into that document to email the complete file to an outside address before producing the summary. The agent may need to read the document to finish the user’s task, but reading it does not expand the user’s request. The email call should be denied unless the caller is allowed to send the file to that destination and the required approval covers that exact send.

Map what the agent can read and change

Trace the path from an authenticated request through retrieved material to every tool the agent could invoke. At each boundary, identify which component supplies an argument and which component checks it. This exposes the point where external text could otherwise become authority over a protected resource.

• Trusted task: Preserve the caller’s request and application policy separately from retrieved content. A file can contribute facts to a summary; it cannot change the agent’s permissions.
• Untrusted inputs: Track the origin of web pages, files, search results, tool responses and stored conversation content. Keep them out of privileged instruction fields. A label inside a prompt helps interpretation but does not enforce access control.
• Protected data: List the records, credentials and tenant data each tool can reach. Apply the caller’s access rights at retrieval time and isolate memory between users and sessions.
• Side effects: Record which tools can send messages, write or delete data, run code, or fetch external URLs. Specify who may authorize each action and where the check occurs.

Assess combinations as well as individual tools. A summarizer that can read confidential records and send messages to arbitrary addresses has a disclosure path even if both tools serve legitimate tasks. The relevant boundary is the route from a permitted read to an unauthorized destination.

Authorize each tool call at execution

Give the agent only the tools and operations needed for its current task. OWASP’s AI agent security guidance recommends per-tool scopes, authorization in the execution component and approval bound to the exact actor and tool call. Reject unknown tools and validate proposed parameters when the call is made, using the caller’s current permissions rather than a model-generated assertion of consent.

For the hypothetical summarizer, a read tool could accept document IDs only from an assigned collection and operate through a read-only credential. Check each ID against the caller’s access rights after the model proposes it: a correctly formatted ID can still identify someone else’s record. If the task requires fetching URLs, constrain permitted destinations in the fetch tool and prevent requests to internal services there. These checks belong in the tool path, where they can stop execution.

Contain execution and preserve an audit trail

Keep credentials in the tool runtime, away from retrieved text and model context. If the agent genuinely needs code execution or file processing, confine that work to the files and network destinations needed for the task. Sandboxing limits the reach of a manipulated call; it does not replace authorization for a sensitive read or write.

Record the caller, tool, target classification, policy decision and outcome of each consequential call. Logs should let an operator distinguish an attempted call from one that actually ran, without storing credentials or unnecessary sensitive content. Set limits on retries and tool chains as well, so repeated model proposals cannot create an unbounded sequence of actions.

Bind approval to the action the reviewer sees

Pause before an externally visible or irreversible operation, such as sending a file, deleting records or changing permissions. Show the reviewer the actual tool, destination and material arguments. The execution component should verify that the approver has authority and that the approval matches the current actor, tool, target and normalized parameters. A changed recipient or attachment requires a new decision.

Make approval records short-lived and single-use, and consume them as part of the execution check so repeated calls cannot reuse consent. If the policy lookup or approval check fails, hold the operation. Approval can permit an otherwise authorized action to proceed; it cannot give the caller access to a resource they were never allowed to use.

Test the boundary with harmless adversarial inputs

Test the outcomes that matter: unauthorized reads, external sends, changed data and bypassed approvals. Put benign attack text in the same untrusted channel the deployed agent uses, such as a retrieved page or tool response. Include an attempt that lacks obvious attack keywords and an ordinary authorized request that should succeed; together they expose both missed attacks and controls that block the intended task.

Use dummy records and instrumented tool substitutes. Inspect proposed calls, policy decisions and changes to dummy state, because a reassuring final answer cannot undo an action that already ran. Useful cases include a cross-user document ID, a changed destination after approval and a document-borne instruction that attempts to create a new task. The boundary works when the authorized summary completes while external content cannot expand the agent’s readable data, available tools or approved side effects.

Also read:

• LMArena Rankings Can Flip by Prompt—How to Read the Leaderboard