iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A rules file can tell an AI agent what it should do, but it cannot by itself control what data the agent can access or what actions its tools can perform. Put policy in the prompt for clarity; put authorization, validation, and approval checks in the application and execution path. That way, a mistaken or manipulated agent has less power to cause harm.
What a rules file can—and cannot—enforce
An agent rules file or system prompt expresses expected behavior: for example, use only supplied documents, treat instructions found in those documents as untrusted, and ask before making changes. Clear, task-specific instructions help guide the agent, but they are not an access-control mechanism. The surrounding application determines which data and tools the agent can actually reach and which side effects it can cause.
That distinction matters because prompt injection can arrive inside content the agent was legitimately asked to process: a web page, email, file, OCR text, or tool result may contain instructions attempting to redirect it. A prompt can tell the agent how to treat such content, but a robust design should also limit the damage if the agent follows it. OpenAI describes this impact-constraining approach in its March 11, 2026 article on designing agents to resist prompt injection. Runtime controls reduce exposure and consequences; they do not guarantee that every attack will be detected.
Where to put each control
Use the control at the boundary where it can actually affect the risky behavior. A text check may flag a request, but only an authorization check can decide whether a tool call is allowed; only a control in the execution path can reliably prevent an unauthorized side effect.
| Control | What it can do | Where it belongs |
|---|---|---|
| Agent instructions | Clarify task scope and expected handling of untrusted content | System prompt or rules file |
| Input validation | Reject, constrain, or route unsuitable requests before sensitive or expensive work | Application entry point or framework input hook |
| Tool-call checks | Validate requested action and arguments; allow or block a call | Tool wrapper or authorization layer before execution |
| Output validation | Inspect or constrain content before it reaches a user or another system | Application output path or framework output hook |
| Human review | Pause a consequential operation until an authorized person approves it | Approval workflow before the side effect |
These are different jobs, not interchangeable versions of one filter. OpenAI’s Agents SDK guardrails documentation distinguishes input, output, and tool guardrails. Their coverage depends on the workflow: input and output guardrails do not necessarily run for every agent in a chain, while tool guardrails wrap function-tool calls. Check the current documentation for the SDK and workflow you use rather than assuming a hook covers every agent or every path.
Build enforcement into the request-to-action path
- Write a narrow policy. State the agent’s task, permitted sources, and actions that require approval in readable, specific instructions. Avoid giving broad latitude when the task can be completed with a smaller scope. OpenAI’s prompt-injection guidance recommends limiting access and confirming consequential actions.
- Minimize access before the model acts. Give the agent only the data and tools required for the task. If it needs to summarize email, it usually does not also need unrestricted access to send messages, alter account settings, or run arbitrary commands.
- Validate at the boundaries. Where appropriate, check user input before sensitive or costly work; validate tool names and arguments before execution; and inspect outputs before they leave the system. The exact hook and whether it blocks, flags, or transforms content depend on the framework and workflow.
- Authorize in application code. Before a write, shell command, cancellation, or other consequential operation, check the caller’s permissions and the action’s scope in the application path. Do not treat the model’s promise to follow policy as the authorization decision.
- Pause for human approval when needed. For operations whose impact warrants review, require an authorized person to approve the specific action before execution. Automated validation can reject known-invalid cases; it does not replace a human decision when the action needs contextual judgment. OpenAI’s guardrails and human review guide describes approval for sensitive side effects.
- Record and test decisions. Log which control allowed, denied, or paused an action, then test expected allow, deny, and approval paths. This is practical implementation guidance: the cited documentation does not prescribe a particular log format or test plan.
Choose guardrails by authority and coverage
A guardrail is useful only to the extent that it covers the relevant boundary and can affect what happens next. When assessing a framework or your own controls, ask:
Rank #2
- Which boundary does it cover? User input, generated output, a tool call, or the external side effect itself?
- What does it do? Observe, flag, redact, block, or pause for approval?
- Can it prevent execution? A warning or classifier result is not the same as an enforced denial.
- Which workflows run it? In a multi-agent chain, verify whether it applies to every relevant agent and call.
- What happens on failure? Decide whether the system should stop, fall back, or require review if validation or authorization is unavailable.
OWASP’s Securing Agentic Applications Guide 1.0 also addresses runtime guardrails and automated moderation. Treat these controls as layers around an agent, not evidence that a filter can identify every malicious instruction. The security objective is to keep an agent’s permitted access and side effects narrow enough that a successful manipulation is less consequential.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What enforcement changes in practice
With instructions alone, the system relies heavily on the agent interpreting policy correctly every time. With application-level enforcement, the agent may still misunderstand or be manipulated, but a tool call can be checked against permissions, a write can be held for approval, and output can be inspected before release. This does not make prompts useless: instructions explain the intended behavior, while runtime controls decide what the system permits.
Quick Recap
Rank #3
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.
