Trust and Verification

Agentforce Vibes protects your data and workspace through two layers of trust: the Einstein Trust Layer masks sensitive CRM data before prompts reach the LLM, and permission modes control what the agent can do without asking you first. Neither layer replaces code review. Always verify agent-generated Apex, LWC, and metadata output before deploying.

Einstein Trust Layer

Agentforce Vibes is built on two layers of trust. Salesforce protects your data automatically through the Einstein Trust Layer before prompts reach the large language model (LLM). You control what the agent can do in your workspace through permission modes and code review. Both layers work together. Neither replaces the other.

Data Protection Through the Einstein Trust Layer

Agentforce Vibes routes prompts through the Einstein Trust Layer, so Einstein Trust Layer protections apply to your Agentforce Vibes sessions.

The Einstein Trust Layer can identify and mask personally identifiable information (PII) and payment card industry (PCI) data in prompts before sending them to the LLM. Masked values are replaced with placeholders for LLM processing, then restored in the response. Your sensitive CRM data stays inside Salesforce.

:::note When Einstein Trust Layer data masking is active, the context window is capped at 115K tokens regardless of the model’s native limit. Plan your context accordingly when masking is enabled in your org. :::

For full details on supported languages, locales, and masking behavior, see Large Language Model Data Masking.

Review Generated Code

Agentforce Vibes acts directly in your workspace, creating files, modifying code, and running commands. This topic covers how to verify agent-generated Apex and LWC output. The agent produces code quickly. That speed is only valuable if you verify the output.

Apex: What to Look For

Bulkification: Are SOQL (Salesforce Object Query Language) queries and DML (Data Manipulation Language) statements outside of loops? Does the code handle collections rather than single records?
Governor limits: Are there queries inside triggers that could hit the 100 SOQL limit in bulk operations?
Null safety: Does the code check for null before accessing object properties or list elements?
Test coverage: Do tests address positive, negative, and bulk scenarios? Are assertions meaningful (not just System.assertNotEquals(null, result))?
Error handling: Are exceptions caught at appropriate levels? Are error messages useful for debugging?

Lightning Web Components (LWC): What to Look For

Reactivity: Are reactive properties decorated with @track or using @wire correctly? Does the component re-render when data changes? Event handling: Are custom events named correctly (lowercase, no camelCase)? Do event boundaries stay within the shadow DOM unless composed: true is set? Apex integration: Do @wire adapters reference real Apex methods with correct parameters? Are imperative calls handling errors? Accessibility: are interactive elements keyboard-accessible? Do images have alt text? Are ARIA attributes used correctly?

Metadata: What to Look For

Completeness: Are all referenced fields, objects, and record types included in the metadata changes? Dependencies: Does the deployment succeed, or are there missing references to objects and fields that don’t exist yet? Permissions: Are new fields and objects added to the relevant permission sets or profiles?

Use Permission Modes as Trust Boundaries

Permission modes control what the agent can do without asking you first. Use them to match your current trust level.

Starting out (low trust):

Set Default Session Mode to “Ask every time.”
Enable safety guardrails.
Keep the command allowlist minimal.

Building confidence (medium trust):

Move to “Run safe defaults” for session mode.
Add commonly approved commands to the allowlist (read operations, test runs, lint checks).

High confidence (established trust):

Expand the command allowlist to include build and deploy commands.
Enable Auto-approve Salesforce MCP write tools for non-destructive MCP operations.
Keep safety guardrails enabled. They prevent destructive actions regardless of session mode.

You can always tighten permissions again. The progression isn’t one-directional.

Considerations

Masking caps your context window. When data masking is enabled, the context window is limited to 115K tokens. If your sessions use large files or long conversation history, this limit may truncate context.
The agent doesn’t guarantee correctness. Output is nondeterministic. The same prompt can produce different results across sessions. Always verify.
Permission modes don’t replace code review. Even with restrictive permissions, the agent can produce code that compiles but has logic errors. Permission modes protect your filesystem. Code review protects your application.
Trust is context-dependent. You might trust the agent completely for boilerplate test classes but still want line-by-line review for security-critical code. That differentiation is the right approach, and it’s a sign of mature adoption.