Salesforce Agentforce Security & Governance: Permissions, Guardrails, Trust Layer, Privacy & Compliance

AI agents introduce a different security challenge from traditional software.

A conventional application usually waits for a user to click a button and then executes predefined logic.

An AI agent can interpret a request, select a capability, retrieve information and execute an action.

That makes the security question broader:

What can the agent access?

What can it do?

Who authorized it?

Which data can it use?

What happens when the request is ambiguous or risky?

Salesforce Agentforce is designed around several layers of security, including the Einstein Trust Layer, Salesforce permissions, agent-specific guardrails, data access controls, auditability and human oversight. Salesforce describes Agentforce security as a shared responsibility model in which Salesforce provides the secure platform foundation while customers configure permissions, access and agent-specific controls.

For enterprises, this means Agentforce security should not be treated as a final deployment checklist.

It should be part of the architecture from day one.

What Is Salesforce Agentforce Security?

Salesforce Agentforce security is the combination of platform security, user permissions, data access controls, AI guardrails, Trust Layer protections, integration security, monitoring and governance used to control how Agentforce agents access information and perform actions.

A simplified security architecture looks like this:

USER / EVENT
│
▼
┌───────────────┐
│   Agentforce  │
│     Agent     │
└───────┬───────┘
│
┌───────────┼───────────┐
▼           ▼           ▼
Permissions   Guardrails   Context
│           │           │
└───────────┼───────────┘
▼
Einstein Trust Layer
│
┌───────────┼───────────┐
▼           ▼           ▼
CRM Data    Knowledge   External Data
│           │           │
└───────────┼───────────┘
▼
Action
│
▼
Business System
│
▼
Audit / Logs

The important point is that no single control is sufficient.

Security comes from multiple controls working together.

Why Agentforce Security Is Different

Traditional Salesforce automation generally executes logic that administrators and developers explicitly define.

Agentforce introduces an additional reasoning layer.

For example:

"Find the customer's account and give them the details of their recent transactions."

The agent must determine:

1. Who is the customer?
2. Which account belongs to them?
3. Which information is relevant?
4. Is the user authorized to access it?
5. Which action should be performed?
6. What information can safely be returned?

The security architecture therefore needs to control both:

Data access

and

Agent behavior.

The Salesforce Agentforce Shared Responsibility Model

Salesforce's current Agentforce security documentation describes a shared responsibility model. Salesforce provides the foundational platform security, while customers are responsible for configuring permissions, access and agent-specific guardrails.

This distinction is important.

Salesforce can provide:

• Platform security
• Einstein Trust Layer
• Access-control mechanisms
• AI security capabilities
• Audit functionality
• Infrastructure security

The organization still needs to define:

• Who can use the agent
• What the agent can access
• What actions it can execute
• Which data is sensitive
• Which requests require approval
• When humans must intervene
• How agent activity is monitored

A secure platform does not automatically mean a secure agent configuration.

Salesforce Agentforce Security Architecture

A practical enterprise architecture can be divided into seven layers.

Layer 1: Identity

Who is interacting with the agent?

Layer 2: Authorization

What is that user or agent allowed to access?

Layer 3: Data Security

Which records, fields and datasets can be accessed?

Layer 4: Agent Guardrails

What can the agent say and do?

Layer 5: Trust Layer

How is data protected while interacting with AI models?

Layer 6: Action Security

Which business operations can the agent execute?

Layer 7: Governance and Monitoring

How are agent interactions, actions and outcomes monitored?

Identity → Authorization → Data Security → Agent Guardrails → Einstein Trust Layer → Actions / Integrations → Monitoring & Governance

This layered approach is more reliable than attempting to solve everything through prompts.

1. Identity and Authentication

The first security question is:

Who is interacting with the agent?

The answer may differ depending on the agent type.

Employee Agents

Internal employees may interact with agents through authenticated Salesforce environments.

Salesforce documentation states that employee agents typically operate in the context of the logged-in user and respect that user's security framework, including permissions, field-level security and sharing rules.

Customer Agents

Customer-facing agents can operate differently because external users may not have the same Salesforce permissions as employees.

Salesforce documents the use of a dedicated Agent User for customer agents, with administrators expected to grant only the access required by the agent.

This makes identity architecture an important part of Agentforce design.

2. Least Privilege for Agentforce

One of the most important principles for Agentforce security is:

Give the agent only the access it needs.

Avoid:

Agent → Full Salesforce Access

Prefer:

Agent → Required Permission → Specific Action → Required Data

For example, a service agent may need permission to:

• Read customer information
• Read cases
• Search knowledge
• Create cases

It may not need permission to:

• Delete accounts
• Modify financial records
• Export customer data
• Change user permissions

Salesforce specifically recommends the principle of least privilege when configuring Agentforce users and permissions.

3. Salesforce Permissions and Agentforce

Agentforce operates within Salesforce's broader access-control model.

Relevant controls can include:

• Profiles
• Permission sets
• Permission set groups
• Role hierarchy
• Sharing rules
• Field-level security
• Object permissions
• Record-level access

Salesforce states that agents respect standard Salesforce access controls.

This creates an important architectural principle:

Do not build a separate permission model when Salesforce's existing security model already defines the required access.

Instead, align Agentforce permissions with the organization's existing security architecture.

4. Field-Level Security

Record access is not enough.

An agent may be allowed to access an account but should not necessarily see every field.

For example:

Account

Allowed:

• Account Name
• Industry
• Account Status

Restricted:

• Internal Risk Score
• Sensitive Financial Information
• Confidential Notes

Field-level security becomes particularly important when agents generate responses based on CRM records.

The agent should not expose information simply because it exists somewhere in the record.

5. Agentforce Guardrails

Agentforce guardrails define operational boundaries for the agent.

Salesforce describes Agentforce guardrails as controls that help define what an agent can and cannot do, while platform guardrails provide broader organizational protections.

Guardrails can address:

• Allowed activities
• Restricted activities
• Escalation
• Data access
• Communication
• Actions
• Compliance requirements
• Human approval

For example:

Never approve a refund above ₹50,000 without human approval.

Or:

Never disclose internal account notes to external customers.

Or:

Escalate requests involving legal disputes to a human representative.

These rules should be explicit.

Agentforce Guardrails vs Permissions

These two concepts are related but different.

Permissions answer:

Can the agent access this?

Guardrails answer:

Should the agent perform this?

For example:

The agent technically has permission to update an opportunity.

A guardrail may say:

Do not change an opportunity stage unless required qualification criteria are present.

This distinction is important for enterprise governance.

6. Subagent Instructions as Guardrails

Salesforce's current terminology uses subagents rather than the older "topics" terminology.

Subagent instructions can establish:

• Scope
• Context
• Behavior
• Restrictions
• Escalation rules

Salesforce's current documentation states that subagent instructions can create boundaries and define agent behavior.

For example:

Billing Subagent

Handle billing questions, retrieve approved account information and escalate disputes.

Returns Subagent

Explain return policy, validate eligibility and create a return request when requirements are met.

This creates clearer boundaries than giving a single agent unrestricted responsibility.

7. Einstein Trust Layer

The Einstein Trust Layer is a core component of Salesforce's AI security architecture.

Salesforce documents Trust Layer capabilities including:

• Data grounding
• Sensitive data masking
• Toxicity detection
• Audit trails
• Zero-data-retention arrangements with participating third-party LLM providers

A simplified architecture is:

Salesforce Data
│
▼
Security / Grounding
│
▼
Einstein Trust Layer
│
▼
LLM
│
▼
Trust Layer
│
▼
Agentforce
│
▼
User

The Trust Layer helps place security controls between enterprise data and the generative AI model.

8. Data Masking

Sensitive information may require additional protection before being processed by an LLM.

Salesforce's developer documentation describes masking sensitive data such as personally identifiable information before prompts are sent to the LLM.

Potentially sensitive information can include:

• Personally identifiable information
• Financial information
• Customer identifiers
• Payment-related information
• Confidential business data

Data masking should be evaluated according to the organization's data classification and regulatory requirements.

9. Zero Data Retention

Salesforce documents zero-data-retention arrangements with participating third-party LLM providers as part of its Trust Layer architecture.

This is important for enterprises because sending information to an AI model raises a critical question:

What happens to the data after the model processes it?

A zero-data-retention architecture helps reduce the risk of customer information being retained by participating third-party model providers.

Organizations should still review the specific contractual terms, service configuration and applicable provider arrangements before making compliance decisions.

10. Dynamic Grounding

Grounding helps provide the AI model with relevant business context.

Instead of relying entirely on general model knowledge:

User Question → Agentforce → Trusted Business Data → Context → LLM → Response

Salesforce identifies dynamic grounding as one of the Trust Layer capabilities designed to improve the safety and accuracy of generative AI responses.

This can reduce the likelihood that an agent answers using irrelevant or outdated information.

11. Prompt Injection Protection

Agentforce agents can interact with information that was not originally written by the agent developer.

That creates a potential prompt-injection risk.

For example, an external document could contain malicious instructions designed to manipulate the agent.

A secure architecture should therefore consider:

• Untrusted content
• External documents
• User-generated text
• Retrieved information
• Tool responses
• External APIs

Salesforce identifies prompt injection as a security threat that Agentforce guardrails are designed to address.

12. Knowledge Security

Grounded responses are only as secure as the information being retrieved.

Consider a company with:

• Public product documentation
• Internal product documentation
• Executive documents
• Legal documents
• Customer-specific information

The agent should not treat all knowledge as equally accessible.

Knowledge architecture should define:

• Source
• Owner
• Classification
• Audience
• Access rules
• Version
• Review cycle

13. Data 360 Security

Data 360 can expand the amount of context available to an agent.

That also expands the security responsibility.

Salesforce's Data 360 documentation describes capabilities for unified, real-time and external data, including structured and unstructured information.

Before connecting Data 360 to Agentforce, organizations should evaluate:

• Data sources
• Data ownership
• Data classification
• Identity resolution
• Consent
• Retention
• Access
• Activation
• Sensitive information

More data does not automatically mean better AI.

The objective is trusted context.

14. Agentforce Integration Security

External integrations create another security boundary.

For example:

Agentforce → MuleSoft → SAP

Security needs to be considered across every layer.

Questions include:

• How is the agent authenticated?
• Which API is called?
• What credentials are used?
• Which operations are allowed?
• What data can be returned?
• Is the response validated?
• Is the operation logged?
• Is approval required?

Salesforce's current platform security guidance emphasizes security and governance across integrations and automation as well as Agentforce.

15. Secure Agent Actions

Actions are where AI decisions can become real-world changes.

An agent may:

• Create a case
• Update a lead
• Modify an opportunity
• Send an email
• Schedule an appointment
• Initiate a transaction
• Call an external API

Actions should therefore be classified according to risk.

Low Risk

• Search knowledge
• Retrieve account information
• Summarize a case

Medium Risk

• Create a case
• Update contact information
• Create a task
• Send an internal notification

High Risk

• Issue refund
• Change financial information
• Approve contract
• Delete records
• Modify sensitive information

High-risk actions should have stronger controls and, where appropriate, human approval.

16. Human-in-the-Loop Governance

Autonomous does not mean:

No human involvement.

A mature architecture defines where humans remain responsible.

For example:

Agentforce
│
▼
Assess Request
│
├── Low Risk
│      ↓
│   Automated
│   Action
│
└── High Risk
↓
Human Approval
↓
Action

Salesforce's Agentforce security guidance specifically recommends human-in-the-loop controls for custom actions.

This is particularly important for:

• Financial decisions
• Legal processes
• Healthcare
• Employment
• Sensitive customer decisions
• High-value transactions

17. Agentforce Audit Trail

Enterprise AI requires visibility.

Organizations should be able to understand:

• Who interacted with the agent
• What the user requested
• What the agent generated
• Which action was selected
• Which data was accessed
• What happened afterward

Salesforce provides an audit trail for AI agent actions and outputs, with related monitoring capabilities through Data 360 and Agentforce Analytics.

A simplified audit model is:

User Request → Agent Decision → Data Retrieval → Action → Result → Audit Record

Auditability is particularly important when organizations need to investigate incidents or demonstrate governance.

18. Enhanced Event Logs

Salesforce's Agentforce security guidance recommends enabling enhanced event logs for monitoring and auditing agent and user activity.

Event monitoring can help security teams investigate:

• Unexpected actions
• Repeated failures
• Suspicious activity
• Permission problems
• Unusual usage patterns
• Potential security incidents

19. Agentforce Analytics

Security should not end after deployment.

Organizations should monitor agent behavior continuously.

Useful metrics include:

Security

• Permission failures
• Blocked actions
• Escalations
• Suspicious interactions

Quality

• Hallucination reports
• Incorrect responses
• User feedback
• Action failures

Operational

• Resolution rate
• Average interaction time
• API failures
• Escalation rate

Business

• Customer satisfaction
• Conversion
• Cost per resolution
• Revenue impact

Salesforce documents Agentforce Analytics capabilities for monitoring agent performance and metrics including user trends, acceptance rates, data masking and toxicity indicators.

20. AI Governance Framework for Agentforce

A mature Agentforce governance program should define ownership across several areas.

This converts Agentforce from an experimental AI tool into a governed enterprise capability.

Agentforce AI Risk Assessment

Before deployment, assess risks across five categories.

1. Data Risk

Could the agent expose sensitive information?

2. Action Risk

Could it execute an inappropriate transaction?

3. Model Risk

Could it generate incorrect or misleading output?

4. Integration Risk

Could a compromised external system influence agent behavior?

5. Governance Risk

Could the organization fail to detect or explain an agent's behavior?

Salesforce's current guidance explicitly identifies risks such as security threats, data breaches, financial loss, hallucinations, bias and transparency issues when deploying autonomous AI.

Agentforce Security by Use Case

Different agents require different security models.

Customer Service Agent

Priorities:

• Customer identity
• Case access
• Knowledge security
• PII
• Escalation

Sales Agent

Priorities:

• Opportunity access
• Account confidentiality
• Pricing information
• Email controls
• Customer data

Marketing Agent

Priorities:

• Consent
• Customer segmentation
• Campaign access
• Personalization data
• Communication governance

Finance Agent

Priorities:

• Financial information
• Transaction authorization
• Approval workflows
• Auditability
• Segregation of duties

HR Agent

Priorities:

• Employee privacy
• Compensation data
• Sensitive personal information
• Role-based access
• Strict escalation

Security should therefore be designed around the business process, not just the Agentforce product.

Agentforce Security for Regulated Industries

Organizations in regulated sectors need additional controls.

Examples include:

• Financial services
• Healthcare
• Insurance
• Government
• Education
• Telecommunications

The implementation should evaluate applicable requirements around:

• Data residency
• Consent
• Data retention
• Access controls
• Auditability
• Human oversight
• Sensitive information
• Regulatory reporting

Salesforce's current trust and governance materials emphasize that organizations need to establish governance policies appropriate to their industry, geography and use case.

The exact compliance requirements should always be evaluated with the organization's legal, privacy and security teams.

Agentforce Security Testing

Testing should happen before production deployment and continue afterward.

Functional Testing

Verify:

• Correct responses
• Correct actions
• Correct data

Security Testing

Test:

• Unauthorized requests
• Restricted records
• Restricted fields
• Permission boundaries

Adversarial Testing

Test:

• Prompt injection
• Malicious instructions
• Data exfiltration attempts
• Conflicting instructions

Integration Testing

Test:

• API failures
• Timeouts
• Invalid responses
• Authentication failures

Human Escalation Testing

Test:

• When escalation occurs
• What information is passed to the human
• Whether the human can complete the process

Salesforce provides Agentforce Testing Center and other testing capabilities to validate agent behavior and security.

Agentforce Security Testing Matrix

Common Agentforce Security Mistakes

Mistake 1: Giving the Agent Too Much Access

More access does not mean more intelligence.

Mistake 2: Relying Only on Prompts

Security should not depend entirely on natural-language instructions.

Mistake 3: Ignoring Field-Level Security

Record access alone may expose sensitive fields.

Mistake 4: No Human Approval

High-risk operations should have clear approval paths.

Mistake 5: No Audit Trail

Organizations need to understand what the agent did.

Mistake 6: Ignoring External Systems

The agent may be secure while the connected API is overly permissive.

Mistake 7: Treating Data Quality as Separate From Security

Incorrect or stale information can create business risk even when access is technically authorized.

Mistake 8: No Continuous Monitoring

Agent behavior can change as data, instructions, integrations and models change.

Salesforce Agentforce Security Best Practices

1. Start With Least Privilege

Give agents only the permissions they need.

2. Separate Read and Write Capabilities

Retrieving information and changing information should not automatically have identical permissions.

3. Classify Actions by Risk

Use stronger controls for high-impact operations.

4. Use Deterministic Controls for Critical Rules

Do not rely entirely on an LLM to enforce critical business policies.

5. Ground Responses in Trusted Data

Use appropriate CRM, knowledge and Data 360 sources.

6. Define Human Escalation

Decide before deployment when an agent must hand work to a person.

7. Monitor Agent Activity

Use audit and analytics capabilities.

8. Test Adversarial Scenarios

Do not test only normal conversations.

9. Review External Integrations

Security must extend beyond Salesforce.

10. Establish AI Governance

Assign ownership for agents, data, actions, compliance and monitoring.

Agentforce Security Implementation Roadmap

Phase 1: Risk Discovery

Document:

• Agent purpose
• Users
• Data
• Actions
• Integrations
• Business impact

Phase 2: Data Classification

Classify:

• Public data
• Internal data
• Confidential data
• Sensitive personal information
• Regulated information

Phase 3: Permission Design

Define:

• Agent user
• Profiles
• Permission sets
• Object access
• Field-level security
• Record access

Phase 4: Guardrail Design

Define:

• Allowed behavior
• Restricted behavior
• Escalation
• Approval
• Communication rules

Phase 5: Trust Layer Configuration

Review:

• Data grounding
• Data masking
• Zero-data-retention configuration
• Toxicity detection
• Audit requirements

Phase 6: Action Security

Review every:

• Flow
• Apex action
• API
• MuleSoft operation
• MCP tool

Phase 7: Testing

Run:

• Functional tests
• Security tests
• Adversarial tests
• Integration tests
• UAT

Phase 8: Deployment

Start with a controlled scope.

Phase 9: Continuous Governance

Monitor:

• Agent actions
• Security events
• User feedback
• Failures
• Business outcomes

Agentforce Security Checklist

Identity

• Agent users defined
• Authentication reviewed
• Employee and customer agent models separated

Permissions

• Least privilege applied
• Object access reviewed
• Field-level security reviewed
• Record access reviewed
• Permission sets reviewed

Data

• Data classification completed
• Sensitive information identified
• Knowledge sources reviewed
• Data 360 sources reviewed
• Data quality assessed

AI

• Einstein Trust Layer configured
• Grounding reviewed
• Data masking reviewed
• Toxicity controls reviewed
• Prompt injection risks assessed

Guardrails

• Agent scope defined
• Subagent instructions defined
• Restricted actions defined
• Escalation rules defined
• Human approval defined

Integrations

• APIs reviewed
• MuleSoft integrations reviewed
• MCP tools reviewed
• External credentials secured
• External system permissions reviewed

Monitoring

• Audit Trail enabled where required
• Enhanced Event Logs reviewed
• Agentforce Analytics configured
• Incident response process defined
• Regular security review scheduled

How MoreYeahs Can Support Agentforce Security and Governance

Agentforce security becomes particularly important when an enterprise connects AI agents to existing Salesforce data, ERP systems, business applications and customer-facing workflows.

MoreYeahs' Salesforce capabilities include:

• Salesforce implementation
• Custom object and workflow design
• Data migration and validation
• Salesforce integration
• Marketing automation
• Analytics
• Training and adoption
• Salesforce support and managed services

MoreYeahs also states that it has built Salesforce integrations with SAP, NetSuite, Dynamics 365 and custom systems using real-time API, near-real-time middleware and batch integration patterns.

This matters because Agentforce governance cannot stop at the Salesforce UI.

A secure enterprise architecture needs to consider:

Agent → Permissions → Data → Actions → Integrations → External Systems → Human Oversight → Audit

MoreYeahs can therefore position Agentforce security as part of a broader secure Salesforce modernization and AI implementation strategy, rather than as a standalone AI configuration exercise.

Final Takeaway

Enterprise Agentforce security should not be reduced to a single feature.

It is a layered architecture:

Identity → Permissions → Data Security → Agent Guardrails → Einstein Trust Layer → Secure Actions → Human Oversight → Audit and Monitoring

The Einstein Trust Layer provides an important security foundation, but it does not eliminate the need for good Salesforce administration, least-privilege access, secure integrations, data governance and ongoing monitoring. Salesforce itself describes Agentforce security through a shared responsibility model, making customer-side configuration a critical part of the implementation.

For enterprise deployments, the real objective is not simply to make an agent autonomous.

It is to make the agent autonomous within clearly defined, auditable and enforceable boundaries.

That is what turns Agentforce from an AI experiment into a production-ready enterprise capability.