How to implement a policy layer between an AI agent and Salesforce

A policy layer is code between the agent and the Salesforce API that evaluates each proposed write before it happens. The agent proposes. The policy layer decides. Both answers get logged. It is the difference between an agent you trust because it has behaved so far and one you trust because it cannot do the thing you are worried about.

Why Salesforce permissions are not this

Profiles, permission sets, and field-level security answer a static question: may this identity write this field. That is necessary and it is not sufficient, because the dangerous writes are usually ones the agent is technically allowed to make. Permissions cannot express any of the following, and each of them is a real rule teams want: no more than two hundred records in a single run, never overwrite a field a human edited in the last thirty days, never move an opportunity backward more than one stage, never write a close date more than a year out, never touch a record owned by someone on leave. These are conditions about the write, not about the writer.

What the layer evaluates

• Field allowlist. Explicit list of what this agent may write. Not a denylist. A denylist silently permits every field added to the object after it was written.
• Value constraints. Type, range, picklist membership, and sanity bounds. Most bad writes are not malicious, they are a date in 2087 or an amount with an extra digit.
• Blast radius. A cap on records per run. The single most valuable rule in the layer, because it converts a catastrophe into an incident.
• Human precedence. If a person set the value recently, the agent proposes instead of overwriting. This is what stops the agent quietly undoing deliberate human decisions.
• Transition rules. Which state changes are legal. Stage movement, ownership changes, and status transitions have real constraints that no field-level check catches.
• Rate and time. Writes per minute, and whether unattended bulk changes are allowed outside business hours when nobody would notice.

Where it runs

Outside Salesforce, in the path the agent has to take. The pattern that works is a small service the agent calls instead of calling the Salesforce API directly, holding the only credential that can write. The agent never sees that credential, so it cannot go around the layer.

Implementing it inside Salesforce as Apex triggers or validation rules is tempting and has two problems. It only catches writes that reach Salesforce, so it cannot cap a run before the run starts, and it mixes agent governance into org configuration that everything else also depends on. Platform validation is a good second line. It is a poor first one.

Every decision gets logged, including the yes

Log allowed writes, blocked writes, and the rule that decided each. Blocked entries are how you tune the rules, and they are the evidence that the layer does anything at all. A policy layer with no record of blocking anything is indistinguishable from no policy layer.

The fields that log needs are in what to log when an AI agent writes to your CRM. Store the previous value on every entry. The log is also the rollback path, and a rollback without the old value is a guess.

Rolling it out

Start in report-only mode. Evaluate every write, log what would have been blocked, allow everything. Then read the would-have-blocked list.

That list is the whole point of the exercise. It will contain rules that are wrong, thresholds set too tight, and at least one legitimate workflow nobody remembered. Fix those with the layer still permissive, and only then start enforcing. Teams that enforce on day one block real work in the first week, and the layer gets turned off and never comes back.

Enforce in stages after that. Value constraints and blast radius first, because they are unambiguous and catch the worst outcomes. Human precedence and transition rules once the exceptions are understood.

The failure modes

A bypass path. If the agent holds any credential that can write directly, the policy layer is advisory. One credential, held by the layer.

Rules in prompts. Instructions in a system prompt are a preference, not a control. The constraint has to be code the model cannot talk its way past.

Silent blocks. A blocked write that nobody sees is a workflow that stopped for reasons nobody can explain. Blocks need to surface somewhere a person reads.

We publish a working reference implementation, open source and Apache-2.0, at github.com/synauton/crm-write-guard. It covers field-level write policy, a tamper-evident audit log, and rollback records, tested against synthetic data. The design reasoning is in guardrails for AI agents that write to your CRM, and the build work is Salesforce Automation.