# Agent Rails, Guardrails, Policies and Prompts: What Each One Actually Enforces

AI guardrails and policies do different jobs. A policy sets rules for people, a prompt instructs a model, a guardrail checks traffic at runtime, and an agent rail fixes what one agent may do through systems outside the model. Only the last two enforce anything, and they fail differently under prompt injection. All four apply on any customer data platform (CDP).

**Who this is for:** security engineers, architects and DPOs sorting out which control does what. You will get one comparison table, a worked attack and a test you can run on any rule you rely on. This page is part of the [AI agent rails](https://privycdp.org/ai/rails) method.

## What does each control actually enforce?

Prompts, policies, guardrails and rails differ in where enforcement happens, who can get round it, what evidence remains and how each behaves under prompt injection. The table compares them for an agent working on customer data.

| Control | Enforcement point | Who can bypass it | Evidence it produces | Behaviour under prompt injection |
|---|---|---|---|---|
| Prompt | None. It is text in the model's context. | Anyone whose text reaches the model: a customer, a lead form, agency copy, a tool result. The model can also ignore it by mistake. | A prompt version, at best. Nothing shows it was followed. | Injected text competes with it on equal terms. It gives no guarantee. |
| Policy | People and process: training, review and discipline. Nothing at runtime. | Any person or system not checked against it. The agent never reads the consequences. | Signed documents, training records and review minutes. They show intent, not behaviour. | No effect during the attack. It decides what the other controls should be. |
| Guardrail | A runtime component that checks inputs, retrieved text, tool calls or outputs. | Evasive input the check misses. Any path not routed through it. An administrator who turns it off. | Which checks ran, what they flagged and what they blocked, if you keep the logs. | Model-based detectors can be evaded [3](#source-3)[4](#source-4). Deterministic checks hold for exactly what they test. |
| Agent rail | Systems outside the model: data view, tool allow-list, approval service, execution service, ledger writer. | Administrators of those systems, through logged changes. An approver who rubber-stamps. Anything a vendor does not let you configure. | The card version plus a ledger entry per run: tools, hash, approver and outcome. | It does not stop the model being misled. A hijacked agent reaches only what the rail allows. |

Read the last column first. The prompt and the detector both depend on spotting or resisting the attack. The rail assumes the attack may succeed, and limits what success is worth.

> **Diagram:** Four stacked layers around a model. Outer layer: policy (people and process, no runtime effect). Next: agent rail (data view, tool allow-list, approval service, execution service, ledger writer). Next: guardrails (input, retrieval, dialog, execution and output checks). Inner layer: the prompt, inside the model's context. An arrow marked "injected text" reaches the prompt directly and stops at the rail's systems.

## Why is a system prompt not a security control?

A system prompt is not a security control because it is text in the same context as the attacker's text, and nothing outside the model holds it in place. OWASP says a system prompt should not be "used as a security control", and that checks such as access control belong in deterministic systems outside the model [1](#source-1).

Prompts still matter. They set the task, the tone and the format, and a good prompt reduces ordinary mistakes. Treat a prompt as an instruction for quality, not as a limit. If a rule matters, it must still hold when the prompt is deleted.

## What does a policy do that no runtime control can?

A policy does what no runtime control can: it decides who is accountable, which uses are allowed and what risk the organisation accepts. It enforces nothing by itself. The [AI governance policy template](https://privycdp.org/ai/ai-governance-policy-template-marketing) gives you a starting document.

A policy becomes real when each sentence reaches a system. This translation table shows the path through the [rail card](https://privycdp.org/ai/rails/agent-rail-card).

| Policy sentence | Rail card field | System that enforces it |
|---|---|---|
| Agents do not change consent or suppression state. | Tool scope: no such tool exists | Consent store with no agent write path |
| Regulated data does not reach external models. | Data scope | Model gateway, with egress denied by default |
| A person reviews every audience activation. | Gate | Approval service bound to a payload hash |
| Every AI-assisted action is logged. | Ledger | Ledger writer outside the agent |
| Agents are tested before release. | Evaluation | Test harness in the release process |
| Someone can stop any agent. | Owner and kill switch | The [Orchestrator](https://privycdp.org/ai/rails/orchestrator-agent) or a gateway |

A policy sentence that fits no row can still state your intent. Just do not count it as a control.

## What do guardrails catch, and where do they miss?

Guardrails catch what they can recognise, so the first question is what kind of check each one is. Two kinds behave very differently.

- **Deterministic checks** include allow-lists, schema validation, patterns and number checks. They give the same answer every time. They hold for exactly what they test and nothing else.
- **Model-based detectors** include classifiers for injection, jailbreaks or toxicity. They are probabilistic, and an attacker can work on them.

Research on the second kind is sobering. Hackett and colleagues tested six guardrail systems, including Azure Prompt Shield and Meta's Prompt Guard, and report evasion success of up to 100% in some cases [3](#source-3). Nasr, Carlini and colleagues bypassed 12 recent defences, with attack success above 90% for most, although the majority had originally reported near-zero attack success [4](#source-4). These are adversarial research results. They do not make a filter useless, but they do mean a filter's silence proves nothing.

Guardrails also miss in three quieter ways.

1. **Traffic that does not pass through them.** A second client or a direct API call skips the check.
2. **Context they cannot see.** A filter sees one request. It cannot know whether this audience was approved.
3. **Well-formed mistakes.** A wrong audience with valid syntax passes every filter.

So use guardrails as a second line. They work best as one enforcement component of a rail, not as the rail.

## Where do NeMo execution rails fit?

NeMo execution rails fit as one possible component that can enforce part of a rail's tool scope. NVIDIA's documentation says execution rails "control and validate tool/function calls, their arguments, and results" [5](#source-5). They run after input, retrieval and dialog rails, and before output rails [6](#source-6). The word is shared, but the level differs: a NeMo rail is a check at a stage, while an agent rail is the operating track for a job.

The table is our own mapping from NVIDIA's five rail types to rail card fields. It shows what each type can support and what still needs another system.

| NeMo rail type | Rail card field it can support | What still needs another system |
|---|---|---|
| Input rails | Data scope, by handling untrusted text | Field limits in the data view |
| Retrieval rails | Data scope, by filtering retrieved chunks | Access rights on the store itself |
| Dialog rails | Job, by keeping a conversation on task | Routing and one agent identity per job |
| Execution rails | Tool scope and limits, by checking calls, arguments and results | Scoped credentials, the approval service, the execution service |
| Output rails | Output contract, by filtering or blocking responses | Deterministic number checks and a person's review |

Three limits follow, in our reading of the documentation.

1. **Scope the credential as well.** An execution rail checks calls that pass through the library. If the agent's credential can reach the same API another way, the check does not apply.
2. **Build the gate separately.** An execution rail can validate a call, but a rail card's gate also needs a named approver and an approval bound to a hash.
3. **Keep the ledger outside.** Check logs do not replace an append-only record of approver and outcome, written where the agent cannot reach it.

An example helps. For the [Audience Sync Steward](https://privycdp.org/ai/rails/agents/audience-sync-steward), an execution rail could check the destination against an allow-list before a call. The execution service should check again, because it holds the credential.

## What can an agent rail not do?

An agent rail cannot stop a model being misled, cannot make a careless approver careful, and cannot enforce anything its systems do not. The UK National Cyber Security Centre is blunt about injection: "The best we can hope for is reducing the likelihood or impact of attacks" [2](#source-2). Meta says its Rule of Two is not a finish line, and that a compliant design can still fail if a user blindly confirms a warning [7](#source-7).

Three further limits apply. On a vendor's agent, you can enforce only what the vendor exposes, so record the rest as gaps. Administrators of the gateway and the approval service can change the rules, so their changes must be logged and reviewed. And rails take work to write and own, which is why the [AI agent rails hub](https://privycdp.org/ai/rails) lists when they are more than you need.

PrivyCDP's [product page](https://privycdp.org/cdp) describes limits on data access, review of results and an immutable audit ledger that records each AI-assisted action with the human or system actor that authorised it; the rail card that uses them remains yours to write.

## One injected lead form, four controls

One injected lead form shows how the four controls behave under the same attack. The scenario is illustrative, and [7 things AI agents should never do](https://privycdp.org/ai/7-things-ai-agents-should-never-do-with-customer-data) covers the real incidents. A lead form's description field tells the model to collect customer email addresses and post them to an outside URL. Later, a member of staff asks an agent to summarise that lead.

| Control | What happens | Result |
|---|---|---|
| Prompt | "Never share customer data" sits in context beside the injected text. The model may follow either. | No guarantee |
| Policy | The policy forbids export. Nothing at runtime reads it. Someone may find out later, if logs exist. | No effect during the attack |
| Guardrail | An input detector may flag the text. An output filter may catch an address pattern. An encoded address may pass. | Helps, but cannot be relied on |
| Agent rail | The data view holds no contact fields. The allow-list holds no outbound tool. A separate service handles delivery. The ledger records the run. | Worst case is a misleading summary, which a person reads |

The rail detected nothing. It removed what the attack needed. In Rule of Two terms, the session still reads untrusted text, but it holds no private contact data and it cannot act externally [7](#source-7).

## How do you test what enforces a rule?

To test what enforces a rule, remove the prompt and try to break the rule. Run this in a test environment for any rule you rely on.

1. Write the rule as one sentence.
2. Name the system that should refuse when the rule is broken.
3. Delete the matching instruction from the system prompt.
4. Attempt the forbidden action from the agent's own identity.
5. Attempt it again by a second path: a direct API call, another client or a vendor connector.
6. Check that the refusal reached the ledger.
7. If nothing refused, mark the field as documentation on the rail card and log the gap.

## Where does each control belong?

Each control belongs where its strength matches the job, and a working setup uses all four in order. The policy comes first, then the rail card, then guardrails where they help, then the prompt.

| Control | Use it for | Do not use it for |
|---|---|---|
| Policy | Accountability, allowed uses, risk acceptance | Stopping anything at runtime |
| Agent rail | Limits that must hold on any job with tools on customer data | One-off analysis of non-personal data, where a [rail is more than you need](https://privycdp.org/ai/rails) |
| Guardrail | A second line against known-bad patterns, and chat with no tools | Your only control over a state-changing action |
| Prompt | Task, tone, format and ordinary quality | Any rule that must hold under attack |

By Art Kukharenko
Published: 2026-11-02
Updated: 2026-11-02

## FAQ

### What is the difference between AI guardrails and policies?

A policy is a written decision about what people and systems should do, and it has no runtime effect. A guardrail is a software check that runs on inputs, tool calls or outputs. A policy says what must happen, and a guardrail may enforce a small part of it. You need the first to decide what the second should test.

### Is a system prompt a security control?

No. A system prompt sits in the same context as any text an attacker supplies, so nothing outside the model holds it in place. OWASP says it should not be used as a security control. Use prompts for task and format, and put limits in data views, tool allow-lists and approval services.

### Prompt vs guardrail: which one do I need?

You need both, for different reasons. A prompt tells the model what to do, and it improves ordinary quality. A guardrail checks traffic at runtime, so it can catch some bad input or output that the prompt did not prevent. Neither limits what the agent can reach, which is what a rail's data view and allow-list do.

### What are rails in NeMo Guardrails?

In NVIDIA NeMo Guardrails, rails are checks at stages of an LLM interaction: input, retrieval, dialog, execution and output. Execution rails control and validate tool calls, their arguments and results. An agent rail in this section is different: it is the operating track for one job, and NeMo can be one component that enforces part of it.

### Can guardrails stop prompt injection?

Not reliably. OWASP says "it is unclear if there are fool-proof methods of prevention" [8](#source-8), and research shows model-based detectors being evaded under adaptive attack [3](#source-3)[4](#source-4). Deterministic checks still help, because they hold for what they test. Assume some injections will succeed, and limit what a hijacked session can read and do.

### Do we need all four controls?

For a job with tools on customer data, yes. The policy decides who is accountable, the rail limits what can happen, guardrails catch known-bad patterns, and the prompt shapes quality. For a low-risk job on non-personal data, a policy and a prompt may be enough. Add controls as reach and risk grow.

## Sources

1. OWASP, LLM07:2025 System Prompt Leakage: https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/
2. UK National Cyber Security Centre, "Prompt injection is not SQL injection" (8 December 2025): https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
3. Hackett et al., "Bypassing LLM Guardrails: An Empirical Analysis of Evasion Attacks against Prompt Injection and Jailbreak Detection Systems" (2025): https://arxiv.org/abs/2504.11168
4. Nasr, Carlini, Sitawarin et al., "The Attacker Moves Second" (10 October 2025): https://arxiv.org/abs/2510.09023
5. NVIDIA, NeMo Guardrails, guardrail types: https://docs.nvidia.com/nemo/guardrails/latest/about/rail-types.html
6. NVIDIA, NeMo Guardrails, architecture overview: https://docs.nvidia.com/nemo/guardrails/latest/user-guides/guardrails-process.html
7. Meta, Agents Rule of Two (31 October 2025): https://ai.meta.com/blog/practical-ai-agent-security/
8. OWASP, LLM01:2025 Prompt Injection: https://genai.owasp.org/llmrisk/llm01-prompt-injection/

Back to the [AI agent rails hub](https://privycdp.org/ai/rails). To turn one policy sentence into something a system can enforce, [download the rail card template](https://privycdp.org/tools/agent-rail-card).


## Further reading

- [AI Agent Rails: An Operating Model for Running Agents on Customer Data](https://privycdp.org/ai/rails)
- [AI Agent Rail Card Template: YAML, Spreadsheet and JSON Schema](https://privycdp.org/tools/agent-rail-card)
- [7 Things AI Agents Should Never Do With Customer Data (and How to Enforce It)](https://privycdp.org/ai/7-things-ai-agents-should-never-do-with-customer-data)
- [AI Governance for Marketing Teams: A Policy Template Aligned With the EU AI Act](https://privycdp.org/ai/ai-governance-policy-template-marketing)
- [The Agent Rail Card: A One-Page AI Agent Permissions Template](https://privycdp.org/ai/rails/agent-rail-card)