Trust by design

Agentforce security designed before the first action.

Agentforce can read data, make decisions and initiate processes. Security therefore extends beyond prompts into identity, Salesforce permissions, tools, data, approvals, logging and operational accountability.

Is Agentforce secure for enterprise data?

Agentforce can be deployed securely when the shared responsibility model is configured deliberately. Salesforce protects the platform and trust layer; the customer remains responsible for agent scope, record access, actions, integrations, knowledge, guardrails and monitoring. Those decisions belong in architecture, not in a pre-production checklist.

Define what the agent must not do first.

Every agent needs a clear goal, allowed topics, approved knowledge and a constrained action set. Informational responses should be separated from operations that change data. Greater autonomy is appropriate only when actions are low risk and reversible.

Financial commitments, access changes, regulated decisions and customer promises need stronger controls. We design confirmations, approvals, limits, escalation and a safe stop path.

  • Least privilege and sharing
  • Allowed topics and actions
  • Human approval and escalation
  • Validation, limits and idempotency

The Trust Layer does not replace correct Salesforce configuration.

The Einstein Trust Layer provides mechanisms including secure grounding, sensitive-data masking, audit and supported zero-data-retention arrangements. It cannot repair overbroad permission sets, an incorrect sharing model or an integration that bypasses access control.

We review profiles, permission sets, sharing, Named Credentials, integration identities and document access. We also verify whose context an agent acts in and what different roles can see from the same interaction.

Production needs an owner, metrics and a controlled change path.

Governance defines who approves a new topic, action or knowledge source, which tests must pass and who responds to incidents. It combines Salesforce release management with evaluation of non-deterministic agent behaviour.

After launch, teams monitor classification failures, action errors, escalation, answer quality, consumption and security signals. Instructions and knowledge changes should be versioned, tested and reversible.

Controls in a secure Agentforce implementation

  1. 01Risk and autonomy model
  2. 02Role, data and permission matrix
  3. 03Guardrails and escalation rules
  4. 04Human-in-the-loop design
  5. 05Audit trail and monitoring
  6. 06Change, test and incident process

Agentforce security questions

01Is company data used to train external models?

Terms depend on the feature and agreement. The Einstein Trust Layer includes safeguards and supported zero-data-retention arrangements, which must be verified for the specific implementation.

02Does the agent respect Salesforce permissions?

It can operate within Salesforce access controls when actions and integrations are designed correctly. Custom actions can create gaps if they bypass sharing or run with excessive privilege.

03When is human approval required?

Use it for hard-to-reverse, financial, legal or sensitive actions and whenever confidence does not meet the agreed threshold.

04Does governance slow delivery?

Good governance accelerates subsequent agents by providing reusable access, testing, approval and monitoring patterns.

Find your first agentic use case.

30 minutes with a Salesforce architect. We will look at the process, data and risk. You leave with a concrete recommendation for the next step.

  • No sales deck
  • Initial readiness view
  • A recommendation: pilot, discovery or not yet

Powered by Tucario