TL;DR | The Highlights
- The real question isn’t whether you can tell an AI agent your rules. It’s what stops it when those instructions don’t hold. In financial services, that answer has to be architectural.
- With Agentforce, control is layered, strongest to weakest: architectural exclusion, topic classification, grounding constraints, prompt instructions, output validation, and auditability. Prompt instructions sit near the bottom. They tune behaviour, they don’t enforce it.
- An AI platform plus MCP tells a different story, and in one respect a stronger one. Every call runs as the connected user, so Salesforce enforces the permission floor and the model can’t bypass it. ‘The agent cannot’ is a far better line for an auditor than ‘the agent has been told not to’.
- That floor still won’t catch bad judgment: the wrong record, a plausible-but-wrong value, a silent overwrite, or any of those amplified across many records. The control for that is preview-and-consent by default, plus separate preview and commit tools for high-stakes work so there’s no one-shot execute.
- Across both builds, the throughline holds: durable control comes from architecture, from what the agent can reach and where consent is required by design. Anyone who calls instructions your main compliance control is misrepresenting the technology.
If you are deploying an AI agent within a regulated workflow, you are likely already anticipating the inevitable question from your compliance team: “how do we ensure it strictly follows our established rules?”.
It’s the right question to ask. And the honest answer is that the instructions you write down are only one layer of several. In our first article, we covered the two ways to build AI for financial services. Here, we’re picking up the thread we left hanging; once an agent can draft or send responses in a regulated environment, what actually keeps it inside the lines?
The answer looks different depending on how you built it, so let’s take the two builds one at a time.
With Agentforce, Control Comes in Layers, Strongest to Weakest
The platform features a hierarchy of guardrails, which range from absolute constraints to softer behavioural adjustments. Based on the architecture of Agentforce, these mechanisms line up from the most secure to the least rigid as follows:
Architectural exclusion → If a topic, data source, or action doesn’t exist, the agent can’t use it. For high-risk surfaces, the safest control is not building the capability.
Topic classification → The classifier intercepts compliance-sensitive intent before any generation happens. Advice-seeking questions route to a deterministic handoff, not a Knowledge search.
Grounding constraints → The agent can only ground in the data sources you connect. Curated Knowledge plus scoped data access is itself a guardrail.
Prompt instructions → Topic and template-level constraints, ideally written as always or never rules. Necessary, but circumventable. This is tuning, not enforcement.
Output validation → Pattern matching for forward-looking language, comparisons, and guarantees before a response goes out. The Einstein Trust Layer handles some of this. Patterns specific to financial services usually need custom work.
Auditability → Not prevention, but defensibility. When something goes wrong, the question is “show me what happened and why,” and complete event logs, versioned prompts, and retention policies are the answer.
With an AI Platform Plus MCP, Salesforce Enforces a Floor the Model Can’t Cross
Pair an AI platform with MCP and the control story changes, and in one respect, it gets stronger. Here’s why.
Every call runs as the connected user, which means Salesforce itself enforces the permission floor. The model can’t talk its way around it. Scope the integration user’s field and object permissions to exactly what the engagement calls for, and any sensitive object or field you’ve set to read-only at the profile level is simply out of reach.
That is a far cleaner thing to tell an auditor than any instruction: ‘the agent cannot’, rather than ‘the agent has been told not to’.
The Permission Floor Won’t Catch Bad Judgment
What that floor won’t catch is bad judgment, as opposed to bad values. A write can be perfectly valid and still wrong. These are the failure modes worth designing against:
Wrong record → The AI resolves the customer to the wrong account and updates it. The write is valid. It’s just on the wrong row.
Plausible but wrong value → A sensible-looking value that isn’t what was meant. It passes validation and is still incorrect.
Silent overwrite → A write replaces a field that already held meaningful data, and nothing errors.
Bulk amplification → Any of the above, repeated across many records in a single action.
The fix for all four is the same, and it should be on by default: preview-and-consent. Before it changes anything, the AI resolves and reads back the exact record, shows you the before and after for each field, flags any overwrite of existing data, and, for a bulk change, tells you the count and the criteria up front.
For higher-stakes work, you can make that preview impossible to skip. Expose writes as a separate preview tool and a separate commit tool, so there’s no one-shot execute to jump straight to. And if your surface lets a human approve each tool call, that’s your final backstop.
One caveat on where this runs. Write-heavy internal workflows belong on a direct connector, like claude.ai, or a custom surface, not a chat-native integration like the Slack app, where the consent experience for writes is still thin today. Read-only, tier-one work is fine anywhere, Slack included.
Durable Control Comes From Architecture, Not Instructions
Across both builds, the throughline is the same. Durable control comes from architecture: what the agent can reach, what’s enforced beneath it, and where consent is required by design. Instructions have a role, but it’s a supporting one. So if anyone tells you the instructions are your primary compliance control, they’re misrepresenting how the technology works.
If you’re scoping an agent for a regulated workflow and want to know which controls actually hold up to an audit, rather than just reading well in a prompt, that’s the conversation we have before anything gets built. Let’s chat.
Let's chat!
