Permissions and safety for CRM AI agents

The permissions material on this site was buried inside a longer guide, and it's the part most likely to produce an answer that's wrong in a way nobody catches. So it gets its own page.

Three separate questions here, and they get conflated constantly:

1. What can the agent read? Object, field, and row scope.
2. Who can change what the agent believes? The rules store is application behavior, not data.
3. What is the agent allowed to do? Reading is one thing. Acting is another.

Three scopes, and they're independent

A user can have object access, lack field access, and see only part of the available rows. All three scopes apply to your agent because your agent is running as somebody.

Your allowlist sits on top of these, never instead of them. The allowlist is a semantic policy about what's worth sending the model. Platform permissions decide what the running user may see. Both have to exist, and where they disagree, the platform wins.

Run as the asking user

This is the central decision and it has an important consequence: the same question can return different answers for different people.

That's often correct. For example, a regional AE asking about pipeline may only be entitled to see their region, while a CRO asking the same question may be entitled to see a broader population. Running as a privileged integration user can be simpler to build, but it also creates a path where a user could receive records or fields they could never open directly in the CRM unless the application re-enforces their scope.

The model also may not know that it is looking at a partial population. It can report "38 opportunities" with confidence when the more accurate sentence is "38 opportunities are visible under the permissions used for this query."

Two global instructions help:

• State whose permissions the query ran under when that context matters to the answer.
• Never conclude that no records exist from an empty result on a sharing-restricted object. "None visible to you" and "none exist" are different claims.

The suppressed null

A subtle permissions failure appears when the application receives an inaccessible field in a form that is indistinguishable downstream from a genuine blank.

For example, an agent may see no renewal date and infer that the Account has none, when the real issue is that the running user cannot access the field. The answer can be fluent and internally consistent while its premise is an artifact of permissions.

List<Account> accounts = [
    SELECT Id, Name, Renewal_Date__c, Renewal_Risk_Score__c
    FROM Account
    WHERE Id IN :accountIds
    WITH SECURITY_ENFORCED
];

The general rule, on any platform: if you can't distinguish "hidden" from "empty," you can't safely let the agent interpret the blank. Either surface the difference or instruct the agent to treat blanks on sensitive fields as unknown rather than as absent.

Deploying a field grants nobody access

Deploying a field or object and granting people access to it are separate steps. A new field can exist successfully in production while the intended users still lack permission to read it.

That can create a misleading debugging path: the schema is present, the query looks correct, and yet the application returns less than expected. Check object and field permissions before assuming the query or deployment failed.

Who can read the rules store

Your rule text can encode thresholds, exclusion logic, attribution policy, and definitions of terms like qualified pipeline. That's a meaningful piece of your GTM operating model written in one queryable place.

If the guidance store inherits broader read access than intended, users may be able to inspect rules that were meant only for the systems or operators administering the agent. Decide that access deliberately rather than accepting the default.

For a Salesforce custom-object implementation, one reasonable pattern is to keep the object private by default and grant read access through a permission set to the users or services that actually need it.

Who can write the rules

Here's the part that matters more as agents get capable.

A guidance rule is an instruction your agent may follow across many questions. Editing one is closer to changing application behavior than to updating an ordinary CRM record. Someone with edit access on the rules object could, for example:

• Change what "qualified pipeline" means, shifting numbers that depend on it.
• Deactivate an exclusion and inflate counts.
• Add a rule that conflicts with another rule.
• Write text into a rule that the agent interprets as an instruction.

That last case is configuration injection: the rules store is a privileged channel into the model's behavior, so anything that can write to it can potentially steer the agent.

Practical controls, in rough order of value:

• Separate edit from read. More people can reasonably need read access than write access.
• Require approval before status: active. draft and approved exist for this. A rule reaching production should be a deliberate transition, not just a save.
• Version and audit every change. You want to answer "what did this rule say in July" without archaeology.
• Keep user-generated CRM content out of the guidance channel. Never build a rule body by interpolating a text field a customer or rep can write into.
• Keep rollback close. A bad rule should be revertible quickly without requiring a long deploy cycle.

The threat model isn't only malicious. A well-meaning admin can change a rule to fix one use case and unintentionally change other answers that depend on the same rule. That is why review, history, and rollback matter.

How much should the agent be allowed to do

Reading and acting are different risk profiles, and "can the agent write?" is too blunt a question. A ladder is more useful because it lets you stop somewhere on purpose:

A lot of production value is available at levels 1 and 2. Moving beyond them should be a deliberate decision rather than something inherited from a demo architecture.

If you do go past level 2, three things stop being optional:

Know what silently reverts. A field that automation force-sets on every save can accept the agent's update and then be overwritten again. The recommendation may look applied even though the durable state did not change. Mark those fields explicitly and do not let the agent propose writing them.

Never overwrite a human-owned field by default. A rep's qualification score or a CSM's health assessment should usually be read, compared against, and reported as agreement or disagreement with reasoning. If AI is allowed to become the writer, that should be an explicit ownership decision rather than an accidental consequence of automation.

Constrain the blast radius in code. Row count caps, allowed field lists for writes, and a dry-run mode belong at the tool boundary, not in a prompt asking the agent to be careful.

What to check

• The identity and permissions used for the agent query are explicit.

• Answers can state whose permissions the query ran under when scope affects interpretation.

• Empty results on sharing-restricted objects are not automatically reported as "none exist."

• Inaccessible fields are handled explicitly instead of being interpreted as ordinary blanks.

• The guidance store's read access is intentionally scoped.

• Rule write access is narrower than rule read access.

• Rules require approval before reaching status: active when they affect production behavior.

• Rule changes are versioned, audited, and easy to roll back.

• No rule body interpolates user-editable CRM text without a deliberate trust boundary.

• The write capability level is a decision someone made, not a default.

• How to build an AI context layer for your CRM: the concept and full build

• One CRM question, traced end to end: where the gate sits in a real run

• Debugging wrong CRM AI answers: the symptoms these failures produce

• Salesforce implementation: Apex security patterns in context