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

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 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.

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.

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.

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 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.

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. 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. 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. They run after input, retrieval and dialog rails, and before output rails 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.

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, 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. 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.

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 lists when they are more than you need.

PrivyCDP's product page 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 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.

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.

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.