An agent’s rules file can describe what it should do, but it cannot by itself limit what the application lets it access or execute. Put policy in the prompt for clarity; put authorization, tool restrictions, validation, and approval gates in the execution path. That way, a successful prompt injection has fewer opportunities to cause harm.
Why a rules file is not an enforcement boundary
An agent may read a web page, email, file, OCR result, or tool response that contains instructions written by someone other than the user. Those instructions can try to redirect the agent while it is carrying out a legitimate task. OpenAI describes this as prompt injection and recommends limiting access, giving explicit instructions, and requiring confirmation for consequential actions (OpenAI’s explanation of prompt injections).
As an Amazon Associate I earn from qualifying purchases.
A rules file is useful: it gives the model a clear task, boundaries, and preferred behavior. But it is still an instruction to the model, not an access-control decision. If the runtime gives an agent broad file access or a tool that can send messages, change records, or run commands, a sentence saying “do not do that” does not revoke those capabilities.
The practical distinction is between behavior guidance and enforced authority. Guidance tells the agent what it should do. Enforcement determines what data and tools are available, which calls are permitted, and whether a consequential action can proceed.
#1 Best Overall
What belongs in the rules file—and what belongs in code
| Control | Best place | What it does |
|---|---|---|
| Task purpose, expected behavior, and instructions for treating external content cautiously | Rules file or system instructions | Gives the agent a clear operating policy |
| Which data and tools the agent can access | Application configuration and tool permissions | Limits the agent’s available capabilities to what the task needs |
| Whether a particular action is authorized | Application logic or an authorization service | Allows or denies the operation independently of the model’s stated intent |
| Whether an action needs a person’s approval | Workflow or human-review gate | Pauses a consequential operation for review before it takes effect |
| Whether inputs, outputs, tool arguments, or results meet policy | Validation hooks around the relevant workflow boundary | Can observe, flag, redact, or block, depending on implementation |
OpenAI’s agent-security guidance emphasizes reducing the impact of manipulation, including cases where an attack succeeds, rather than depending only on filters to recognize every malicious input (OpenAI, “Designing AI agents to resist prompt injection,” March 11, 2026). A layered design applies that principle: retain clear instructions, but do not let instructions carry authority that should belong to the application.
Where to put runtime checks
1. Limit the agent’s access before it starts
Give each task only the data and tools it needs. A read-only research agent should not also receive a tool that can send email or edit a production record. Narrow permissions reduce the consequences of a mistake or manipulation; they do not depend on the model correctly recognizing every hostile instruction.
2. Validate at the boundary that matters
Place checks where data enters, where the model’s result leaves, and around tool calls. Depending on the application, a check may validate user input before expensive or sensitive processing, inspect an output before it is returned, or confirm that a tool call’s arguments and result fit policy. The right boundary depends on the risk: a text check cannot replace an authorization check, and a check on tool arguments cannot by itself decide whether the caller is entitled to perform the action.
Free tools Windows power users keep installed
One-click scans. No signup required.
In the OpenAI Agents SDK, input, output, and tool guardrails have distinct roles and workflow boundaries. Tool guardrails wrap function-tool calls; input and output guardrails do not necessarily run for every agent in a multi-agent chain. Confirm the current SDK behavior for the workflow you are building rather than assuming that one guardrail covers every agent or call (OpenAI Agents SDK: Guardrails).
3. Make authorization and side effects application decisions
Before a tool changes something outside the model’s response—such as editing data, sending a message, or running a sensitive operation—the application should decide whether the action is allowed. Do not treat the model’s assertion that an action follows policy as proof of authorization. Enforce permissions in the execution path that actually performs the operation.
4. Pause consequential actions for human review
Automated validation and human approval solve different problems. A validator can apply a rule automatically; a review gate lets a person inspect a proposed action before it takes effect. OpenAI’s API documentation treats human review as a separate control for sensitive side effects, including edits and shell commands (OpenAI API: Guardrails and human review). Use approval pauses where the potential impact warrants them, not as a substitute for limiting permissions.
5. Record decisions and test each path
For operational visibility, record which checks ran and whether they allowed, denied, or paused an action. Test representative allow, deny, and approval-required cases, including multi-agent paths where checks may run at different boundaries. These are practical implementation steps; the cited documentation does not prescribe a particular log format or test plan.
How to evaluate a guardrail
“Guardrail” can mean anything from a warning to a hard block. Before relying on one, determine what boundary it covers and what happens when it detects a problem.
- Boundary: Does it inspect input, model output, a tool call, or the external side effect?
- Action: Does it observe, flag, redact, block, or pause for approval?
- Authority: Can it actually prevent access or execution, or does it only ask the model to comply?
- Workflow coverage: Does it run for every relevant agent and call in a multi-agent workflow?
- Failure behavior: What happens if the check errors, times out, or cannot make a decision, and what operational burden does that create?
These distinctions matter because a control can be correctly implemented yet cover the wrong boundary. For example, output review cannot undo a tool action that already occurred, while an approval pause is ineffective if the operation bypasses it.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.A practical way to build the policy boundary
- Write the task policy. State the agent’s purpose, the allowed scope, and how it should treat instructions found in external content. Keep the task specific rather than granting unnecessary discretion.
- Reduce capabilities. Configure data access and tools to match that task; omit unrelated write-capable tools.
- Map the execution path. Identify where inputs arrive, where outputs are returned, where tools are called, and where their effects occur.
- Place checks at those boundaries. Validate the relevant inputs, outputs, arguments, and results using hooks appropriate to the framework and workflow.
- Enforce permissions outside the model. Make the application—not the model’s promise—decide whether an operation is authorized.
- Require review where impact justifies it. Pause sensitive or consequential actions for a person to approve before execution.
- Exercise and monitor the paths. Test allowed, denied, and review-required cases, and retain enough decision records to diagnose unexpected outcomes.
What enforcement can—and cannot—promise
Runtime controls can restrict an agent’s authority and make the consequences of a successful manipulation smaller. They cannot guarantee that every prompt injection will be detected or that every workflow is safe. OpenAI’s security guidance frames the goal as constraining attack impact, not relying solely on input filtering (OpenAI’s agent-security guidance). The sound design is therefore layered: clear instructions, limited capabilities, checks at meaningful boundaries, application-level authorization, and human review for actions whose consequences merit it.
The exact implementation depends on the SDK and workflow. In particular, verify where its guardrails execute in a chain of agents and whether they can block the operation you need to protect.
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.
