The Objective and Purpose of Salesforce Guardian
Guardian's purpose is to let organisations increase the autonomy and scale of Agentforce without lowering the security standard applied to people, applications and customer data. It connects four responsibilities that are often managed separately: access control, data protection, activity monitoring and operational resilience.
The distinction matters. Agentforce itself has a built-in trust baseline: agents inherit Salesforce's identity, permissions, sharing and field-level security, while the AI Trust Layer provides protections including dynamic grounding, toxicity detection and zero data retention by third-party model providers. Guardian extends that baseline when risk, regulation or operating scale demands more visibility and control.
Guardian is not a replacement for a sound Salesforce security model. If an agent's running user has excessive permissions, its actions are too broad or its grounding data is poorly governed, adding monitoring later only documents the exposure. Secure implementation begins with design.
What Is Included in the Guardian Strategy?
Salesforce groups a portfolio of trusted services under the Guardian narrative. Customers select the capabilities that match their data, threat and compliance requirements.
Shield
Adds Event Monitoring, Platform Encryption, Field Audit Trail and Data Detect for deeper visibility, enforcement, audit evidence and sensitive-data discovery.
Security Center
Brings security posture, compliance and governance signals into one view, with Agentforce assisting investigation and remediation workflows.
Privacy Center
Supports consent, privacy policies and data-management obligations; Agentforce can help identify and prioritise exposure risks.
Customer Identity and Mobile App Security
Strengthen identity assurance and protect Salesforce data at mobile endpoints with centrally managed policies.
Data Mask & Seed, Archive and Backup
Protect non-production data, reduce live-data volume and improve recovery readiness as autonomous activity scales.
Data 360 Governance
Extends policy and governance across structured and unstructured connected data used to ground agents.
How Guardian Protects Agentforce and AI Agents
Before an agent acts
Identity, the running user, permission sets, sharing rules and field-level security define the maximum boundary. Data classification, encryption and consent determine what information can safely enter the workflow.
While an agent acts
The AI Trust Layer protects model interactions. Event Monitoring can add near-real-time visibility into data access and agent activity, while Transaction Security policies can alert on or block defined high-risk behaviour.
After an agent acts
Event records and Field Audit Trail support investigation and audit evidence. Security Center helps teams review posture and incidents, while archiving and backup controls protect continuity and recovery.
When an agent changes
Masked sandbox data, permission-negative testing and release controls reduce the risk of introducing a new topic, action, prompt, skill or connected tool. Every material capability change should trigger a fresh threat review.
Do You Need Shield or Event Monitoring?
Shield and Event Monitoring are specific add-on products—not automatic entitlements created by the Guardian name. Salesforce Shield is a premium suite containing Event Monitoring, Platform Encryption, Field Audit Trail and Data Detect. Salesforce also offers Event Monitoring as a separate add-on.
Real-Time Event Monitoring requires Salesforce Shield or an Event Monitoring add-on subscription and is documented for Enterprise, Unlimited and Developer Editions. Confirm current edition, storage, retention, regional availability and commercial terms with your Salesforce account team.
You may not need every advanced product on day one. A lower-risk internal agent can begin with strict permissions, limited actions, representative testing and standard auditing. A customer-facing agent handling health, financial, employee or payment data will usually justify stronger encryption, longer audit history, real-time visibility, blocking policies and formal recovery controls.
Implementation Steps for Your Salesforce Org
Treat this as a risk-led implementation, not a shopping list. The control set should follow the agent's actual access and impact.
- 1
Inventory every agent and action
Record each agent's job, running user, topics, actions, data sources, channels and connected tools. Remove anything that is not necessary for the defined outcome.
- 2
Apply least privilege
Start the running user with no access, then grant only the objects, fields, flows, Apex classes and prompt templates required. Test denied paths as carefully as successful ones.
- 3
Classify and minimise data
Identify regulated and sensitive fields, remove unnecessary grounding data, mask realistic sandbox data and decide where encryption or retention controls are required.
- 4
Create monitoring and blocking policies
If licensed, configure Event Monitoring dashboards, alerts and Transaction Security policies for bulk exports, unusual logins, excessive API use and sensitive-data access.
- 5
Test in a safe environment
Use representative masked data, adversarial prompts and permission-negative tests. Verify human approval, escalation and failure behaviour before production access.
- 6
Operate with evidence
Review event trails, agent outcomes, false positives, access changes and recovery readiness on a schedule. Update controls whenever an agent gains a new skill, tool or dataset.
KVP View: Guardian Is an Operating Model, Not a Shield You Switch On
Start with the agent's authority, not the security product catalogue. The most important question is what this digital worker is allowed to decide and execute. Products can enforce and evidence that boundary; they cannot define the business's risk appetite.
Observe agents as identities. Security teams already monitor privileged users, integrations and APIs. Autonomous agents belong in the same operating model, with named ownership, least privilege, behavioural baselines, change control and incident response.
Use Shield where the evidence or response time matters. For regulated data, high-volume customer interactions and actions with financial or operational impact, near-real-time events, blocking policies, encryption and durable audit history can turn an AI promise into a governable service.
Resilience is part of AI safety. A secure agent programme also needs recoverable data, controlled test environments and the ability to investigate what happened. Backup, archive and masking are not secondary controls when an agent can act at scale.
Five Steps to Get Started
Choose one bounded use case
Prefer a measurable workflow with known data, clear actions and a human escalation path.
Run an access review
Compare the agent's effective access with the minimum needed for its job.
Map data and obligations
Identify sensitive fields, retention rules, consent requirements and connected systems.
Decide the advanced-control gap
Assess whether Shield, Event Monitoring, Security Center, Privacy Center or resilience products are justified.
Pilot with an evidence pack
Capture test cases, denied paths, approvals, event visibility, outcomes and rollback steps before scale.