Agentforce guardrails: the layered controls that keep an agent in scope

Every scary Agentforce story has the same shape. The agent didn’t crash — it confidently did the wrong thing. It answered a question it had no business answering, quoted a refund policy that doesn’t exist, wandered from “order status” into “should I switch insurers,” or called an action on a record it shouldn’t have touched. Nobody saw an error. The customer just got a wrong answer delivered with total composure, which is worse.

The reflex is to call this a hallucination and blame the model. It’s almost never the model. An agent that goes off the rails is an agent whose rails were never laid — and laying them has a specific name on this platform: guardrails. Not a single setting, but a stack of them, and the first thing to get straight is that half the stack is Salesforce’s job and half is yours. Confuse the two and you’ll either over-trust a control you don’t actually have, or hand-build something the platform already gives you.

This post is the working map of that stack: the line Salesforce draws between platform and behavioral guardrails, the five layers you actually configure, why the natural-language layer is the weakest and what to reinforce it with, and how to prove the boundaries hold before a customer finds the gap.

Two tiers, and Salesforce draws the line for you

Salesforce splits guardrails into two categories, and the split is the whole mental model.

Platform guardrails are the ones the platform runs whether you configure anything or not. These are the Einstein Trust Layer controls — zero-data-retention agreements with model providers, PII masking, toxicity detection, secure data retrieval, and the audit trail — plus a couple of default behaviors worth naming because teams don’t realize they’re free: if a user asks something inappropriate, it’s detected, classified, and the agent refuses to engage; and a request outside the agent’s design gets classified as off-topic and redirected back to scope. You don’t author those. They’re the floor.

Behavioral guardrails are the operating boundaries of your specific agent — what it can and can’t do, when it should escalate, which data it can see. Salesforce’s own phrasing: guardrails are “the operational boundaries for each agent, outlining what it can and can’t do,” specified largely in natural language. This is the part that ships in your metadata, that a reviewer can read, and that is entirely on you to get right. The Trust Layer will stop your agent from being toxic; it will not stop your agent from cheerfully promising a refund your policy doesn’t allow. That gap is behavioral, and it’s this post.

Everything below is the behavioral tier.

The spine: five levels of determinism

Before the individual layers, the framework that organizes them. Salesforce publishes a model it calls the five levels of determinism, aimed at guided determinism — the balance between letting an LLM reason flexibly and forcing predictable business outcomes. The spectrum runs from Level 1, where the agent has maximum freedom and picks actions purely from topic and action descriptions, up to Level 5, where critical behavior is wrapped in Apex, API, and Flow actions that execute as code, not as a model’s choice.

The reason this matters for guardrails is the single most important idea in the whole subject: a natural-language instruction is a suggestion to a probabilistic model, not an enforcement mechanism. The higher you climb the determinism ladder for a given step, the less that step depends on the model choosing to behave. So the design question for every risky behavior isn’t “how do I word the instruction,” it’s “how deterministic does this step need to be” — and the answer moves genuinely dangerous operations down into code where the model can’t freelance. Guardrails aren’t one layer; they’re a choice of altitude, made per behavior.

With that spine in place, here are the five layers you configure, roughly outermost to innermost.

Layer 1 — Topics as the scope boundary

Topics are where an agent’s job gets segmented, and each topic is the first and coarsest guardrail. A topic carries four configurable fields, and each does distinct work:

• Classification Description — tells the reasoning engine when to use this topic by matching user intent to it. Salesforce’s own example: “Manages customer inquiries about order status and return requests.”
• Scope — what the agent is able to do inside the topic, and, explicitly, the jobs it should not perform. This is the closest thing to a literal in-scope/out-of-scope declaration, written in prose.
• Instructions — the natural-language rules for how to do the job (Layer 2 below).
• Example User Input — sample utterances that sharpen classification.

The Atlas reasoning engine reads the agent’s fields and every topic’s Classification Description to pick a topic, then reads that topic’s Scope, Instructions, and action descriptions to decide what to do. Which means the number-one architecture failure is semantic overlap between topics: two topics whose descriptions describe overlapping jobs make classification unreliable, and an agent that lands in the wrong topic is out of scope before it’s said a word. The discipline that fixes it is the same one behind good subagent and topic design — non-overlapping jobs, classification descriptions a stranger could route by, and scopes that say plainly what the topic will not touch. A tell worth watching for: a misclassification that still produces a right-ish answer, which masks the problem until the day it doesn’t.

Layer 2 — Instructions as guardrails (the weakest strong layer)

Inside a topic, instructions shape behavior — and they double as guardrails. Salesforce’s guidance is to write them as direct rules: “Always…,” “Never…,” “If X, then Y…,” “As a first step,….” They exist at three levels — topic instructions, action instructions, and input/output instructions — so you can bound behavior at the right granularity.

This layer is indispensable and, on its own, insufficient. The failure mode is baked into what it is: “if instructions do not clearly define what the agent should avoid, guardrails cannot compensate,” and even when they do, the model can still stray, because instructions steer probabilistically. Two practical consequences. First, vague instructions are worse than none, because they create false confidence — “be careful with refunds” is not a guardrail, “Never issue a refund; if a refund is requested, escalate” is closer. Second, anything that must not fail should not live in this layer alone. Use instructions to shape the routine and the tone; push the non-negotiable down to Layer 4. (Agent Builder’s AI Assist can rewrite instructions toward best practice, which helps with clarity but does nothing for enforceability — a clearer suggestion is still a suggestion.)

Layer 3 — Grounding scope: answer only from approved content

An agent that can retrieve anything can be talked into citing anything. Grounding scope is the guardrail that bounds what the agent is even allowed to know when it answers. The Agentforce Data Library builds the retrieval layer over your knowledge articles, files, and documents, and — this is the guardrail part — a library is scoped to a topic and audience, and Data Category filters restrict which content can surface. Point a topic at a narrow, curated library and “answer only from approved sources” stops being a hope and becomes a retrieval boundary.

This is also where most real hallucinations are actually born. The common root cause isn’t a creative model — it’s conflicting or duplicate source content that forces the model to reconcile contradictions and invent the resolution. Which means grounding scope and grounding hygiene are the same guardrail: curate the corpus, dedupe it, chunk long articles so retrieval returns the relevant paragraph rather than a document the model has to summarize under pressure. Getting the retriever configuration and the source content right does more for factual reliability than any instruction tuning, because it removes the raw material hallucinations are made from.

Layer 4 — Deterministic actions: put the dangerous parts in code

This is Level 5 of the determinism ladder, and it’s the layer that turns a guardrail from advisory into structural. An agent can only invoke actions that have been explicitly added to its topics — that allow-list is itself a boundary — and for anything with real consequences, the action behind it should be Apex, Flow, or an API call that enforces the rules in code. The model decides whether to issue the refund; the Flow decides how, checks the eligibility, caps the amount, and writes the audit record — the same way every time, regardless of how the conversation got there.

This is where the Flow-versus-Apex-versus-Agentforce decision becomes a guardrail decision, not just an architecture one. A deterministic action is a promise the model can’t break. As of the Summer ‘26 release, Agent Script — the strongly-typed authoring layer in the new Agentforce Builder — makes this explicit, letting builders define subagents, actions, variables, guardrails, and transitions as declared, inspectable structure rather than prose the engine interprets. Where a behavior must be exact, express it as script and code, not instruction.

Layer 5 — Escalation: the pressure-release valve

The last guardrail isn’t about stopping the agent — it’s about knowing when to hand off. Over-tight guardrails that make an agent refuse everything are their own failure; escalation is what lets you draw hard boundaries without degrading the experience, because “I can’t do that” becomes “let me get you someone who can.” Agentforce ships an Escalation subagent; you enable it per topic by setting the topic’s canEscalate field to true, and in the new builder you can invoke it with the escalate utility in Agent Script. The handoff routes through a pre-built Omni-Channel flow that checks for an available human and transfers with context.

The guardrail detail teams miss: make the escalation action’s inputs — an intent summary, the trigger reason, the relevant record IDs — required, so a handoff can never fire with a blank context and dump a confused customer on an agent who has to start over. Escalation done well is the core of a real human-in-the-loop design: the agent handles what it’s scoped for, and everything past the boundary reaches a person with the context, not without it.

Testing that the rails actually hold

Guardrails you haven’t tested are guardrails you’re hoping about. Three tools and one habit.

Testing Center is the built-in harness. You upload test cases as CSV or let Salesforce generate them from the agent’s own topics, actions, and Data Library, then run them in bulk. It reports not just whether the answer was right but which topic was selected, which action was chosen, and metrics including an instruction-adherence score — so you can see the agent staying in (or drifting out of) its lane, which is exactly the guardrail signal you want. Build the practice out the way we describe in testing Agentforce agents.

Plan Tracer (the agent tracer in the new builder) shows the execution behind a single response — input, topic selected, variables updated, tools enabled, reasoning steps, transitions, output evaluation — as a timeline. It’s how you confirm the agent stayed within the guardrails you set on a specific hard case, and it’s the first thing to reach for when debugging an agent that misbehaved.

Adversarial testing is the habit, and it’s a method rather than a button: deliberately provoke the failure modes — ask about products that don’t exist, push jailbreak and out-of-scope prompts, run multi-turn edge cases — and keep them as a regression suite so a later change can’t quietly reopen a hole. Two cautions. Test for over-refusal too: a suite that only checks the agent says no to bad inputs will happily ship an agent that also says no to good ones. And remember a passing test is not a correctness proof — Testing Center tells you the agent behaved as configured, not that the configuration is right, so pair it with domain checks on the answers themselves.

The trade-off you’re actually managing

Every guardrail decision is a point on the guided-determinism spectrum, and there’s no free end. Push everything toward the deterministic end and the agent becomes rigid — predictable, and useless the moment a customer phrases something you didn’t script. Leave everything to instructions and it’s adaptable and unreliable. The craft is putting each behavior at the right altitude: low-stakes conversation stays flexible and model-driven; anything that moves money, changes a record, or makes a promise gets pushed down into deterministic actions and required-input escalations. There’s also a quiet cost to over-guarding — a guardrail check after every step accumulates latency across a conversation, so where you enforce matters as much as whether.

And underneath all five layers sits the unglamorous truth the incident reports keep repeating: most “the agent hallucinated” failures trace back to bad source data, vague instructions, or overlapping topics — three things no additional guardrail can paper over. Fix the corpus, sharpen the instructions, separate the topics, and the layers above them start doing their job.

The takeaway

Guardrails aren’t a switch you flip; they’re a stack you build. Salesforce runs the platform tier — Trust Layer, toxicity refusal, off-topic redirect — for free. The behavioral tier is yours: topics that bound scope, instructions that shape behavior but don’t enforce it, grounding scoped to curated content, deterministic actions that put the dangerous parts in code, and escalation that hands off with context instead of refusing. Organize them with the five-levels-of-determinism question — how predictable does this step need to be? — and test the boundaries with Testing Center, Plan Tracer, and an adversarial suite that also checks the agent isn’t over-refusing.

An agent that stays in its lane isn’t a more cautious model. It’s a better-built one — scoped narrowly, grounded cleanly, deterministic where it counts, and rehearsed against the exact inputs meant to break it.

Understanding the basics

What are guardrails in Agentforce?

Guardrails are the operating boundaries that define what an agent can and can’t do. Salesforce splits them into two tiers. Platform guardrails are built in and run automatically — the Einstein Trust Layer (zero data retention, PII masking, toxicity detection, secure retrieval, audit), plus default behaviors like refusing inappropriate requests and redirecting off-topic ones. Behavioral guardrails are the ones you configure for your specific agent: topic scope, natural-language instructions, grounding scope, deterministic actions, and escalation rules. The platform tier keeps the agent safe; the behavioral tier keeps it correct and in-scope, and it’s entirely your responsibility.

How do I stop an Agentforce agent from hallucinating or going off-topic?

Work the layers, not just the instructions. Give each topic a non-overlapping Classification Description and a Scope that states what it won’t do, so requests get classified correctly. Scope grounding to a curated, deduplicated Data Library so the agent can only answer from approved content — conflicting source documents are the most common hallucination cause. Push anything with real consequences into deterministic Apex/Flow/API actions rather than trusting a natural-language instruction, since instructions steer a model probabilistically and can be ignored. Then test with Testing Center and adversarial prompts. Most off-topic and hallucination problems trace to overlapping topics, vague instructions, or bad grounding data.

Are natural-language instructions enough to enforce agent behavior?

No — and this is the most important thing to internalize. A natural-language instruction is guidance to a probabilistic model, not a hard control; the model can still stray, and a vague instruction is worse than none because it creates false confidence. Use instructions to shape routine behavior and tone, but move any behavior that must not fail down the determinism ladder into Flow, Apex, or API actions that enforce the rule in code. Salesforce’s five-levels-of-determinism framework exists precisely to help you decide which behaviors need that structural enforcement versus which can stay model-driven.

How do I test Agentforce guardrails?

Use Testing Center to run batches of test cases (uploaded as CSV or AI-generated from your topics and actions) and read the metrics — it reports the topic and action selected and an instruction-adherence score, so you can see whether the agent stays in scope. Use Plan Tracer to inspect the reasoning and transitions behind a specific response. Then build an adversarial regression suite that provokes the failure modes — nonexistent products, jailbreak prompts, out-of-scope requests, multi-turn edge cases — and, crucially, also checks the agent doesn’t over-refuse valid requests. Treat a passing test as evidence the agent behaved as configured, not proof the configuration is correct.

---

Trying to work out which agent behaviors need hard, deterministic guardrails and which can stay flexible — and how to prove the boundaries hold before go-live? Talk to us. Scoping topics, pushing the dangerous steps into code, and adversarially testing the result is exactly the work that makes an agent safe to ship.