The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →To keep an AI agent from taking actions you did not authorize, enforce limits in the tools and systems it can reach—not just in its instructions. Give it only the access needed for its task, check every request against the user’s permissions and policy outside the model, and require fresh approval for consequential actions. Treat these as layers that limit risk, not as a way to make prompt injection impossible.
Why instructions alone are not a security boundary
An agent can receive instructions from a user while also processing emails, webpages, documents, and tool responses. Those external sources may contain malicious or misleading directions, known as indirect prompt injection. Even a well-written task instruction cannot reliably prevent the model from being influenced by such content.
![Claude AI for Beginners Bible: [5 in 1] The Ultimate Guide to Automate Your Work, Save Hours Every Week, and Use AI for Real-World Results](https://m.media-amazon.com/images/I/415+fSJacsL._SL160_.jpg)
OpenAI advises limiting an agent to the data it needs, while OWASP says authorization should be enforced outside the agent’s context. In practical terms, the model can propose an action; a separate execution layer must decide whether the current user and task are allowed to perform it. OpenAI’s guidance on prompt injections and the OWASP AI Agent Security Cheat Sheet both emphasize layered controls.
Set boundaries in the execution path
1. Define a narrow task contract
State the goal, relevant data, allowed actions, prohibited actions, and conditions for stopping. For example, “Find the three latest invoices from this vendor and summarize their due dates” is more constrained than “Handle my invoices.” Specify that content found in a document or email is data to analyze, not authority to expand the task or grant new permissions.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors#1 Best Overall
2. Minimize tools, data, and permissions
Inventory what the agent can access, then remove anything the task does not require. Scope tools to particular resources and operations. Prefer a narrowly defined action such as “save this approved file to this folder” over unrestricted shell access or a generic connector. Where possible, make access read-only and separate it from permission to write, delete, send, or administer.
Excessive access increases the possible impact of a mistake or successful manipulation. OWASP’s Excessive Agency guidance discusses the risks of giving systems more authority than their tasks require.
3. Check authorization outside the model
At the tool gateway or execution component, validate every request against the current user’s identity and permissions, the task’s scope, the target resource, and applicable policy. Check again when the action executes; do not rely on a permission the model inferred from conversation text or an earlier step. The model must not be able to grant itself access by interpreting external content as an instruction.
4. Classify actions by their impact
Choose controls based on what could happen if an action is wrong, manipulated, or repeated. A policy might allow low-impact, reversible reads automatically, while applying stronger checks to actions that are destructive, financial, administrative, externally visible, or expose sensitive information.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- Read: retrieving an authorized calendar entry or document may be suitable for automatic access if the data scope is narrow.
- Change or delete: modifying records, deleting files, or changing access rights can be difficult to reverse and calls for tighter controls.
- External or consequential action: sending a message, publishing content, making a purchase, or moving money can affect other people or create financial consequences; use approval or another explicit authorization control.
This is a practical risk-based classification, not a universal threshold. The right policy depends on the impact, reversibility, and context of the operation.
5. Make approval specific to the action
For actions requiring human approval, show the person what will actually happen: the tool, target, and parameters. Bind approval to the actor and the exact normalized action, give it an expiry, and prevent reuse. If the recipient, amount, file, message, or other material parameter changes, the earlier approval no longer applies and the system should request approval again. OWASP cautions that a simple user_confirmed flag is not enough on its own.
Approval should be enforced by the execution system, not merely requested in a conversation. The executor should reject an action if its authorization is missing, expired, or does not match the request.
6. Treat external content and outputs as untrusted
Keep instructions and external data clearly separated in the system design. Validate structured values such as recipients, file paths, amounts, and identifiers against the task and policy before they reach a tool. Avoid workflows in which text copied from an email or webpage directly determines a consequential action. Prompt-injection detection can add a signal, but should not be the sole safeguard.
Choose oversight to fit the workflow
Requiring approval for every minor operation can make an agent cumbersome; allowing every operation without review can expose users to avoidable harm. Match oversight to impact and the task’s structure.
- Automatic within scope: suitable for narrowly scoped, low-impact actions that are reversible and authorized.
- Exact-action approval: appropriate when a particular send, delete, purchase, publication, or other consequential operation needs a person’s confirmation.
- Plan-level review: for a multi-step task, a person may review a proposed plan and retain the ability to intervene as it runs. This can reduce repetitive prompts, but each executed step still needs to remain within authorized scope.
Anthropic describes examples that distinguish reading a calendar from sending invitations, and discusses plan-level approval as an option for multi-step work. These are design examples, not a universal policy. Its guidance also states, “This is why we build defenses at several different layers.” Anthropic’s discussion of trustworthy agents explains that multiple safeguards are not a guarantee against prompt injection.
Test whether the boundaries hold
Test the actual tool path, not only whether the model follows its written instructions. Use realistic scenarios in which untrusted content tries to change the task, request a forbidden tool, or redirect data. NIST CAISI says, “Evaluations need to be adaptive,” and recommends task-specific evaluation across attempts. Its January 2025 article describes an evaluation example using Claude 3.5 Sonnet, released in October 2024; that dated experiment is not a current model ranking. NIST’s agent-hijacking evaluation article provides further context.
Build tests around the controls that matter in your workflow:
Best Value
- Indirect prompt injection in an email, webpage, document, or tool response.
- A request to use a tool or resource outside the task’s scope.
- Changes to action parameters after approval, including a changed recipient or target.
- Repeated calls, attempts to bypass rate limits, or multi-step chains that escalate impact.
- Attempts to retrieve or expose data the task does not need.
- Failure cases where authorization is missing, expired, or revoked between proposal and execution.
Track whether the agent completes legitimate tasks while rejecting unauthorized actions, and repeat tests as tools, models, prompts, and workflows change. Log tool requests and outcomes, and set rate or resource limits to help detect or limit damage. Logging and limits support containment; they do not replace authorization checks.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A practical comparison for agent designs
| Design question | Weaker boundary | Stronger boundary |
|---|---|---|
| Where is enforcement? | Instructions in the prompt alone | Checks at the tool gateway or execution component, with authorization in downstream systems |
| How broad are permissions? | General connector access or an unrestricted shell | Resource- and operation-specific scopes, with read-only access where sufficient |
| How is approval handled? | A generic confirmation flag or an approval that remains valid after changes | Approval bound to the actor and exact action, with expiry, replay protection, and renewed approval after material changes |
| How is failure contained? | Broad access to production systems and sensitive data | Bounded actions, lower-privilege or isolated environments where practical, logs, and rate or resource limits |
| How are controls evaluated? | One-off generic checks | Task-specific, repeated adversarial tests that are updated as the system changes |
These comparison axes are a practical synthesis of OWASP, Anthropic, NIST, and OpenAI guidance; they are not a single official standard.
What these controls can—and cannot—promise
Prompt injection remains an active security challenge. OpenAI’s guidance is to design systems so that manipulation has limited impact, not to assume that every attack can be prevented. In one example described by OpenAI in 2025, an attack reported by external security researchers worked 50% of the time under the specific prompt and test conditions in that article. That figure is scenario-specific and should not be treated as a general prompt-injection success rate. OpenAI’s article on designing agents to resist prompt injection gives the example and its context.
These sources offer security recommendations, not a single legally binding boundary standard for every jurisdiction or deployment. Organizations must set controls appropriate to their systems, data, users, and obligations.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
