Apply Least-Privilege Controls
Learning Objectives
After completing this unit, you'll be able to:
- Define the principle of least privilege.
- Explain how identity, permissions, and tool design work together to limit headless access.
- Identify opportunities to limit the access and capabilities of agents.
In the previous unit, you learned that a headless surface doesn't create a shortcut around Salesforce security. That protection is strongest when you also follow the principle of least privilege.
Principle 2: Start with Minimal Access
The principle of least privilege gives each person, application, and agent only the access needed for its task, and no more. A safe design starts with the question, “What is the minimum useful permission or access this user needs?” Just as you might prune your tree to make it stronger, reviewing access and permissions makes your headless architecture stronger as well.
Identity: Determine the Who
Let's start with identity: identifying who can do what. This concept is clear in the movie 2001: A Space Odyssey. The AI named HAL interacts with a human user named Dave. Dave requests an action, and HAL famously replies, “I’m sorry, Dave. I'm afraid I can't do that.” In this headless experience where the human interacts verbally with the AI, the AI's programming restricts actions and access based on Dave’s identity. The mission commander determined what HAL could access and what data Dave could request.
For your AI, consider who your end user is, are they a person or another system? A user-context design focuses on preserving and honoring the end user’s Salesforce access. For example, two service reps can ask the same question of an internal agent and can receive different results because their record access differs. An integration-user design uses the permissions assigned to a dedicated account. For example, one internal agent must correspond with another agent. Using an integration user permission set might be appropriate to limit what one agent can do over another.
Sensitivity and Access
Next, analyze data sensitivity and the potential impact of data access. Classify data by impact level: low-impact (green), medium-impact (yellow), and high-impact (red). Just as HAL prevents Dave from performing certain actions, determine which access and actions each user can complete. For example, decide whether they can view, create, or delete the data.
In general you should expose capabilities that are required for the use cases, not provide full access. For example, a bank exposes a read-only operation for its service agent that returns only case status and priority. By excluding payment fields from the approved capability, the bank enforces least privilege at the API layer. This design ensures the agent can’t access sensitive data even if it receives malicious instructions. Here are some guidelines when determining access and associated actions.
- Start with read-only access when the use case doesn't require changes.
- Return only the objects, fields, and records required for the task.
- Use targeted, specific queries rather than broad or open-ended requests.
- Choose a clear, targeted action for the task rather than giving broad editing permissions.
- Add write access only after the read-only design is tested and approved.
Oversight and Guardrails
Use this information (data sensitivity, identity, and access) to determine governance controls based on actions. Then build in meaningful friction to consequential actions. Every write action must clearly define the authorized requester, specific records and fields subject to change, and also include valid input values. Additionally, the design must specify the necessary business conditions, whether confirmation or approval is required, how to prevent duplicate requests, and the methods for logging, monitoring, and reversing the action when possible.
Apply the progressive authority principle by matching the level of friction to the potential impact of the action. Some use cases require an agent to make changes. These actions need more protection than a read operation. Select the impact based on sensitivity, governance rules based on identity and access, and finally the oversight needed. For irreversible or highly sensitive areas, it’s best to keep the action unavailable to the agent unless an approved design includes strong authorization, independent verification, and recovery controls.
Impact | Governance | Example |
|---|---|---|
Low impact |
| For everyday requests like checking an account balance, the assistant can provide simple, read-only information, requiring no complex technical commands or extra permissions. |
Moderate impact |
| For standard financial disputes, such as a customer questioning an unknown credit card charge, the assistant reviews the transaction details and suggests a resolution, but requires a human representative to review the logic and approve the final action. |
High impact |
| For sensitive requests, like a customer asking to significantly increase their credit limit, the action triggers a formal approval flow and requires supervisor authorization before proceeding. |
To review these areas further, click each flashcard to learn about questions to ask and best practices for each.
Test and Iterate
After identifying ways you can control access and limit risks in your use case, it’s time to test and iterate. Testing least-privilege access means confirming that unauthorized requests properly fail. Run these tests in a test or sandbox environment using representative user permissions and document the results so you can retest when needed. Always test using the actual end-user’s identity—not your admin account—and make sure any custom Apex code explicitly enforces security controls (or request help). Salesforce permissions only govern data exiting the system, not how external third-party tools use that data. It’s important to assess the complete data lifecycle (in and out of Salesforce) including external models and vendors (such as ChatGPT). By providing only the minimum necessary data from Salesforce and analyzing and understanding external vendor policies, you can feel more confident in that hand-off of data across systems.
What’s Next
In this unit, you’ve explored how to build a more secure headless experience by applying the principle of least privilege. You’ve learned how to identify the right users, classify data based on its sensitivity, and implement progressive authority by matching the level of human oversight to each task’s impact. By narrowing access and adding smart guardrails, you’ve set a solid foundation for protecting your data while keeping your AI agents efficient. You’re now ready for the next unit, where you dive into monitoring headless activity, investigating potential issues, and managing security if trust changes.