AI Guardrails

Why it matters

Most people picture guardrails as a profanity filter or a 'don't say anything offensive' wrapper. For a chatbot that only talks, that's roughly the whole job. For an agent that takes actions — updates a record, issues a refund, books a meeting, sends an email on the company's behalf — the dangerous failure is not a rude sentence. It's a wrong write to a system of record. The guardrails that prevent that are about authority and scope, not vocabulary.

• A talking agent can embarrass you. An acting agent can cost you money, corrupt data integrity, or trip a regulation.
• The blast radius of a missing guardrail scales with the agent's permissions, not its eloquence. A read-only agent and a refund-issuing agent need very different controls even when they share a model.
• Guardrails are also what make an agent shippable to a regulated buyer: they are the evidence that the system cannot do the thing legal is afraid of, independent of how the model behaves on any single prompt.

How it works: the four layers

Guardrails are best understood as checks placed at four distinct points in the request path. A serious deployment uses all four, because each catches failures the others structurally cannot.

• Input guardrails — validate and sanitize what comes in: detect prompt injection, strip or flag PII, reject off-topic or out-of-scope requests before they reach the model. Treat retrieved documents and tool results as untrusted input too, since injection often arrives through them rather than the user.
• Model/grounding guardrails — constrain the reasoning: a tightly scoped system prompt, retrieval that forces answers to cite trusted data so the model can't free-associate, and refusal or escalation behavior for low-confidence cases.
• Action/tool guardrails — the most important layer for agents: every tool the agent can call runs under real permissions (row- and field-level access, scopes), with allowlists, rate limits, dollar/quantity caps, idempotency on writes, and human-in-the-loop approval for high-stakes actions.
• Output guardrails — final checks before the response leaves: schema validation, PII redaction, toxicity and hallucination screening, and immutable logging of the full input-to-action chain for audit and replay.

The non-obvious part: guardrails are a permission model, not a vibe

A prompt that says 'never issue a refund over $500' is a suggestion. An LLM can be talked out of a suggestion. A guardrail is the refund API rejecting any call above $500 regardless of what the model decided — enforced in code, outside the model, where it cannot be argued with. The rule of thumb: anything you actually care about must be enforced deterministically, downstream of the model. Treat the model as a persuasive intern who proposes actions; the guardrail is the system that approves or denies them. If a control exists only as words inside the prompt, assume an attacker — or an ordinary confused user — can get past it.

• Prompt-level rules = soft, probabilistic, bypassable. Use them for tone, preference, and the happy path — never as your last line of defense.
• Code-level rules (permissions, validation, caps, approvals) = hard, deterministic. Use them for anything that touches money, data integrity, or compliance.
• Test guardrails like security controls, not features: red-team them with injection and jailbreak attempts, and assume the model will eventually try every path you left open. A guardrail you haven't tried to break is a guardrail you don't yet have.

Where it fits

The four layers are a general discipline — they apply to any agent on any stack, not just Salesforce. On Salesforce specifically, they map onto real platform mechanics rather than bolt-on filters. Agentforce topics and instructions scope what the agent will attempt; the Einstein Trust Layer handles input/output concerns like PII masking, grounding, and toxicity scoring; and crucially, an agent acts as a running user — so it inherits that user's profile, permission sets, sharing rules, and field-level security. That last point is the strongest action guardrail you have, and the easiest to over-provision by accident: design the agent's permission set as carefully as you'd design a service account, because it is one, and review it on the same cadence. SkySync's view is that guardrails are not a launch-day checklist item but part of running an agent accountably over time — the controls that let you put an agent into production, keep it inside its lane as data and use cases drift, and stand behind the outcome rather than handing over a config and walking away.