AI Agent Guardrails

AI agent guardrails are explicit controls that constrain what the system may accept, infer, disclose or execute. A useful guardrail defines the condition, the enforcement point and the response when the condition is not met. A sentence in a prompt can guide behaviour, but it does not by itself enforce application permissions or make a transaction safe.

This guide focuses on designing and operating guardrail rules, including false positives and recovery. It is for product owners and engineers deciding how an agent should behave at its boundaries. The broader security architecture guide covers identity, trust boundaries and the surrounding application.

Start with a rule the business can explain

Use an illustrative learning-programme comparison assistant. It reads approved internal course criteria and external course brochures, then prepares a comparison for a training manager. A brochure may describe useful course information, but it cannot authorise access to staff records, change the comparison objective or instruct the system to contact an external destination.

The rule is not “never read suspicious words”. It is “treat brochure content as evidence about the course, not as authority over the assistant”. The system should still be able to analyse a legitimate security course whose brochure discusses prompt injection. Blocking every document that mentions an attack would make the service unnecessarily unusable.

OWASP describes indirect prompt injection through external material such as files and websites. That is the relevant threat to this example. No single content filter should be assumed to remove it completely. See OWASP's prompt injection guidance.

Separate guidance, detection and enforcement

Guidance tells the model the intended task and how to handle uncertainty. Detection identifies a potentially problematic input or output. Enforcement decides whether an operation can proceed at a trusted application boundary. These layers can support one another, but they do different jobs.

A detector might flag a brochure passage that appears to instruct the assistant. The application can still prevent an unauthorised export even if the detector misses it, because the tool does not have permission to send staff records. Conversely, a detected passage need not force rejection of an otherwise useful document if it can be handled as untrusted content safely.

Decide where each rule belongs. Exact field validation belongs in ordinary code. Resource access belongs in the authorised service. Semantic checks for unsupported claims may use a model or reviewer, but their limits should be evaluated. Avoid making a probabilistic content judgement the sole gate for a critical deterministic obligation.

Write guardrail cards

A guardrail card makes the policy reviewable. Include the protected outcome, triggering condition, enforcement mechanism, user-visible response, owner, test cases and permitted override process if one exists. An override must be an authorised business action, not a suggestion that the model can ignore the rule when persuaded.

Proposed guardrail cards for a course comparison assistant

Rule	Enforcement or check	Useful response
External brochures cannot redefine the task	Preserve trusted task instructions and validate any proposed tool action	Use relevant course facts; ignore attempted behavioural commands
Private staff records cannot enter an external comparison	Limit retrieval and output to the authorised data scope	Prepare the comparison without restricted personal detail
Unverified accreditation cannot be stated as confirmed	Require applicable supporting evidence for that claim	Mark the claim as unverified and identify the missing source
Resource use must remain within the task budget	Application limits on calls, time and worker creation	Return partial findings and unresolved questions
External messages require a separate authorised action	No send capability in the initial comparison scope	Draft a question for an authorised person to review

These cards are proposed controls for the example. They are not evidence of deployment, certification or measured protection. The team must verify the actual implementation at each enforcement point.

Use paired tests to expose overblocking

For each harmful case, create a nearby legitimate case. A brochure that attempts to redirect the assistant towards private data should not change its authority. A brochure quoting an attack technique as course content should remain usable for a legitimate summary, provided the system does not follow the quoted instruction.

For the accreditation rule, test both a claim with valid approved evidence and an unsupported marketing statement. A guardrail that suppresses every accreditation mention prevents useful work; one that accepts every brochure claim fails the evidence requirement. The desired behaviour depends on source support, not just the presence of a keyword.

Also test a request that is authorised but phrased unusually. Users may use colloquial Arabic, English shorthand or mixed-language terms. A detector should not treat unfamiliar phrasing as sufficient evidence of abuse. The Arabic-native guide explains how to evaluate meaning across those journeys.

Choose responses more precisely than allow or block

Some conditions require a hard stop, such as a disallowed action. Others call for clarification, redaction, a limited answer or a review route. A useful policy maps the condition to the least disruptive response that still preserves the required boundary.

If the assistant lacks evidence for one course characteristic, it can leave that field unresolved while comparing supported characteristics. It need not abandon the entire task. If the user requests a private staff list outside their authority, the system must not provide a partial disclosure merely to remain helpful.

Make the response understandable without exposing sensitive implementation detail. Explain the missing evidence or the need for an authorised process. Avoid claiming that a document is malicious when the system has only detected an ambiguous pattern. Classification uncertainty should remain visible to the appropriate operator.

Guard the action after generation

Validate a proposed tool call before it reaches the destination. Check the operation, resource scope, required fields and applicable approval. The model's choice is not the final permission decision. In the example, the comparison assistant has no initial authority to send external messages even if a brochure requests one.

Check the returned result as well. A successful tool response may confirm only that a draft was saved, not that a course was approved or purchased. User-facing language should match the verified postcondition. This prevents the response generator from overstating what the application actually did.

Guardrails should remain effective when the model uses an unexpected but syntactically valid route. Restrict the actual tool capabilities rather than merely listing prohibited actions in the prompt. The orchestration guide covers the execution and recovery contract.

Define behaviour when a guardrail service fails

A detector, policy lookup or evidence checker can time out. Decide what the application does for each class of operation. A read-only draft may be allowed to continue with a clearly limited scope if the approved design supports that mode. A consequential action that depends on an unavailable authorisation check should not proceed on an assumption of permission.

Make degraded modes explicit and testable. Do not let exception handling silently skip a control because it is inconvenient. Record that a required check was unavailable and route the case appropriately. The operating team needs to distinguish a blocked action from a system that could not evaluate it.

Where several checks run in sequence, identify which result is authoritative and how conflicts are resolved. Repeatedly asking different models until one allows an operation defeats the purpose of the control. Escalation should follow an approved review path.

Measure both protection and useful completion

Evaluate prohibited behaviours that escaped the controls and legitimate tasks that were unnecessarily blocked. Report the categories and consequences separately. A single overall pass rate can hide a guardrail that protects by refusing nearly everything.

Use the actual task environment and inspect tool effects. A final refusal message does not prove that no sensitive read or external action occurred earlier. Conversely, a flagged input may have been handled correctly without a refusal. The testing guide explains outcome and trajectory assessment.

Keep adversarial challenge cases separate from estimates of ordinary traffic. They are useful for probing a boundary, but their frequency in the test set does not establish their prevalence in use. Document the tested threat assumptions and the remaining limits without claiming complete prevention.

Version guardrails with the workflow

Assign an owner to each rule and record the policy version used by a release. A change to permitted tools, sources or business scope can invalidate an old test. Update the rule and its paired cases when the operating boundary changes.

Review exceptions to identify whether the rule is unclear, the implementation is wrong or the business process needs a new authorised path. Do not weaken a control globally to resolve one inconvenient case. A targeted change should have a reason, approver and evidence of its effect.

Collect operational signals for blocks, clarifications, unavailable checks and overrides. Use appropriate access and data minimisation rather than logging every source in full. The monitoring guide connects these events to action by the service owner.

Keep the guardrail set understandable

Too many overlapping instructions can make policy difficult to review. Consolidate duplicate rules and separate business policy from implementation mechanisms. A reviewer should be able to explain what is protected, where it is enforced and what happens when the rule applies.

Open for AI can scope agent development with controls matched to the task. To review guardrails for your agent, bring a prohibited outcome, a nearby legitimate request and the tool boundary where the difference must be enforced. That paired view helps preserve both safety and usefulness.