You are here:
Security and Governance in Headless Experiences
Headless capabilities enable users, apps, and AI agents to reach Salesforce data and processes outside the traditional Salesforce interface. That flexibility opens more places where access gets requested, but it doesn't change how you govern that access. Learn how identity, permissions, and monitoring work together to keep headless access to your org secure.
Headless Security Layers
Headless architecture has a visible surface and an unseen foundation, and both matter to security. The visible surface includes user-facing touchpoints such as Slack, conversational chat interfaces, and the actions a user or agent takes day to day.
Security controls anchor the entire system below the Einstein Trust Layer. These controls include identity authentication, access and field-level permissions, and audit trails.
Open Access and Least Privilege
The principle that defines headless architecture is “open access, not open bypass.” Salesforce hosted Model Context Protocol (MCP) servers are disabled by default. You explicitly turn on the servers that agents can access. Only you can deliberately decide to expose data to an agent. Headless calls inherit the same identity, permission, and credential checks as standard Salesforce requests.
To minimize security risks, enforce the principle of least privilege in these ways.
- Limit the scope of external tools
- Grant only necessary user or integration permissions
- Restrict exposure to sensitive data
- Require human approval for high-impact actions
- Named queries are parameterized query expressions scoped to what the agent needs.
Governance and Monitoring
Here’s a simple approach to governance and monitoring for any headless use case.
- Know the task. Understand the use case, owners, users, data, and involved actions.
- Limit access. Grant only the access that the use case or task needs.
- Monitor. Watch the task, know what's normal, and flag the steps that need review.
- Stop issues. Know how to stop a task, who to contact, and how to cut off access.
Following the principle of least privilege reduces risk, but it doesn't eliminate it. A secure headless architecture also needs monitoring, which helps you understand normal activity and detect behavior that needs attention. Salesforce monitoring stops at the Salesforce boundary, but headless requests often cross multiple systems—like messaging apps, custom software, and agent tools—before reaching Salesforce. Because no single log captures the entire path, tracking requests across these systems is essential.
Before You Begin
For headless use cases, document all steps and associated permissions across all sources (such as your third-party apps, external model providers, or your own logs). Exhaustive documentation includes: systems and ownership, access and data sensitivity, data integrations, and log information. Next, develop a monitoring and incident respose plan for each use case.
To feel confident in your headless use case before launching to production, make sure you’ve applied the principle of least privilege and have your monitoring and incident response processes in place.
