What it is
Field-Level Security, or FLS, is a Salesforce access control that governs whether a given user can read or edit each individual field on an object, set through profiles and permission sets. Even if someone can open a record, FLS decides which fields on that record are visible and which are editable. It is the finest-grained layer of Salesforce's permission model, sitting beneath object permissions and sharing rules, and it is enforced at the platform level across the UI, reports, and the API.
Why it matters
FLS is the concrete control that keeps an Agentforce agent inside its lane. Agentforce agents run as a specific user and are bound by that user's object permissions, Field-Level Security, and sharing rules, so an agent literally cannot read or write a field the running user is not permitted to touch. That turns an abstract goal — least privilege for a digital worker — into a configuration you set in the Salesforce UI rather than code you have to trust. If a support agent should never see a Social Security number or a contract's margin field, you remove read access via FLS on its permission set, and the platform enforces it for every prompt, forever. This is why FLS is the load-bearing answer to 'how do we know the agent won't expose something it shouldn't.'
Key capabilities
- Controls read and edit access per field, independent of whether the record itself is visible
- Configured through profiles and permission sets, not custom code
- Enforced platform-wide across the UI, reports, SOQL, and the API
- Applies to Agentforce agents through the running user's permissions, scoping what an agent can see and change
- Complements object permissions and sharing rules as the most granular layer of Salesforce access
- Auditable and reversible, so access can be tightened or granted without touching business logic
How it works
- Define a permission set that represents what an agent, or its running user, is allowed to do
- Set each sensitive field to hidden or read-only on that permission set via Field-Level Security
- Assign the permission set to the user the Agentforce agent runs as
- When the agent queries or updates a record, the platform checks FLS on every field
- Fields the running user cannot read are withheld from the agent; fields it cannot edit reject writes
- Adjust FLS as the agent's role changes, and the new limits apply immediately with no redeployment
Examples
“A billing support agent runs as a user whose permission set hides the Contact's SSN field and makes the Account's internal margin read-only. The agent can resolve billing questions and update case status, but it physically cannot read the SSN or change the margin, because FLS blocks it at the platform level.”
Good to know
A subtle trap: custom Apex classes declared 'without sharing' or code that queries with elevated permissions can bypass FLS, so an agent invoking such an action may see data its running user cannot. If you build custom actions for an agent, enforce FLS in Apex with WITH SECURITY_ENFORCED or Security.stripInaccessible() so the code honors the same field-level limits the platform does everywhere else.
Related terms
Agent Governance
The policies, controls, and monitoring systems that ensure AI agents operate safely, compliantly, and within business-approved boundaries.
Agentforce
Salesforce's AI agent platform that enables businesses to build, customize, and deploy autonomous AI agents across sales, service, marketing, and commerce.
Apex
Salesforce's proprietary programming language for custom business logic — the backend code behind your automations, integrations, and agent actions.
Capability-Based Authorization
Authorizing an AI agent by granting narrow, revocable permissions for specific actions, rather than handing it a broad API key or a human's full access.
Salesforce
Salesforce is a leading cloud-based customer relationship management (CRM) platform that helps businesses manage their sales, customer service, and marketing efforts.