Reviewing Salesforce Agentforce — the Trust Layer and what it doesn't cover

Because Agentforce is metadata-driven, an agent's available actions are defined by the same profiles, permission sets, sharing rules, and role-based access controls that already govern human users in the org — plus attribute-based policies for finer-grained rules. That's a real strength: there's no separate permission system to keep in sync. It also means an agent inherits whatever gaps already exist in an org's existing permission model.

The Einstein Trust Layer is what makes Agentforce safe to point at production data in the specific sense of the prompt/response path: data sent to an LLM, including PII, is protected in transit and excluded from external providers' training data under a zero-retention policy. That's a genuinely strong default for the question “can this LLM provider retain or train on our customer data.”

The Trust Layer answers “is the prompt path safe.” It does not answer “is this agent allowed to update this record” — that's determined entirely by the Action Layer and the permissions of whichever user the agent runs as.

A CVSS 9.4 disclosure by Noma Security, dubbed “ForcedLeak,” shows exactly how a Trust-Layer-secured prompt path and an over-permissioned Action Layer can combine into a real exfiltration chain. The Web-to-Lead form's Description field allows up to 42,000 characters — more than enough room to hide a prompt-injection payload in plain sight. Separately, Salesforce's own Content Security Policy allowlist included a domain, my-salesforce-cms.com, that had lapsed and become available to purchase for five dollars. An attacker bought it, then submitted a lead with an injected payload instructing the agent — the next time an employee asked it about that lead — to exfiltrate CRM data by embedding it in an image request to that now-attacker-controlled, still-trusted domain.

A related flaw, PipeLeak (Capsule Security), used the same lead-form-injection pattern with no authentication required at all — and notably, Salesforce never assigned it a CVE or issued a public advisory, a real inconsistency in disclosure practice worth knowing about if a review is trying to build a complete picture from public records alone. Separately, CVE-2025-64322 covers an unrelated permission-assignment flaw in the Agentforce Vibes development extension, not the production runtime.

Salesforce's own guidance is explicit on this point: an agent's running user should be a dedicated, minimally permissioned integration user with only the object, field, and action access the agent's published topics actually require. In practice, the fastest path to shipping an agent is often to run it as an existing highly-privileged admin or integration user that already has broad access — which works, ships fast, and is exactly the finding a review exists to catch before it reaches production.

Salesforce's own admin guidance goes further than a general caution here: it explicitly instructs teams to move from Profile-based to Permission-Set-based field-level security specifically to get “Agentforce ready.” The implication is direct — the legacy profile model doesn't cleanly govern what an agent's actions can touch, and an org that hasn't made that migration is not fully ready to scope an agent's access precisely, whatever integration user it's assigned.

For any Agentforce deployment, a design-time review should be able to answer:

• What user does each agent actually run as — a dedicated, minimally-scoped integration user, or a broader existing account?
• Do the agent's published topics map to a permission set that grants only the objects, fields, and actions those topics need?
• Which of the agent's actions are consequential enough to require explicit confirmation before executing, versus running autonomously?
• Is data classification (which fields are sensitive/PII) actually configured, since the Trust Layer's protections depend on that classification being accurate?
• Has the org migrated from Profile-based to Permission-Set-based field-level security, per Salesforce's own “Agentforce ready” guidance?
• Is Trusted URL Enforcement enabled, and are all CSP-allowlisted domains actively owned and monitored for expiry, given the ForcedLeak precedent?
• Do public-facing forms (Web-to-Lead or equivalent) that feed agent-visible data have a character-length or content-scanning limit to reduce the space available for a hidden injection payload?