9.2 Trusted AI, Security, Data Access, and Permission Implications

Trust starts with Salesforce security

Trusted AI is not a slogan for admins; it is an implementation discipline. Agentforce uses Salesforce configuration, data, actions, and channels, so the same security questions still apply. Who is the user? What license do they have? Which app and tab can they access? What objects, fields, records, files, and knowledge articles can they see? Which actions can they run? Which audit trail proves what changed?

A common exam trap is assuming the agent is a special superuser. Do not. Admins should design agents so users receive help within approved access boundaries. If a service rep cannot see a field because field-level security hides it, an agent response should not reveal that field by summarizing it from another source. If an Experience Cloud user cannot see another customer account, a customer-facing agent should not expose that account through a grounded answer.

Builder access and runtime access are different. A business operations lead might need to help design an internal productivity agent, but that does not mean the person should receive System Administrator, Modify All Data, or unrestricted Setup access. Current Agentforce Studio guidance supports access through the App Launcher and feature-specific permissions, such as Manage AI Agents, with additional permissions depending on the agent type. The admin should use permission sets and permission set groups to assign only the required capabilities.

User permissions also govern agent actions. If an agent can trigger a flow, invoke an action, update a case, create a task, or retrieve a knowledge article, those capabilities must be reviewed the same way any automation entry point is reviewed. The admin should ask whether the action runs in user context, system context, or a named integration context, and whether the result could expose data the user should not see. If context is unclear, test it with restricted users before production.

Grounding deserves special care because it determines what the agent can use as source context. Approved grounding might include public knowledge articles, internal knowledge, CRM records, Data Cloud segments, uploaded documents, or an Agentforce data library. Each source has a security classification. A public warranty FAQ is not the same as a case transcript, product defect spreadsheet, or employee HR policy. The admin should tag sources by sensitivity before connecting them.

Security test checklist:

• Log in or test as a user with minimal intended permissions.
• Ask for records the user should not see and verify the agent refuses or cannot retrieve them.
• Ask for hidden fields, restricted files, unpublished knowledge, and private records.
• Test external users separately from employees because sharing models differ.
• Test actions that create or update records and confirm ownership, required fields, validation rules, and sharing side effects.
• Review conversation logs, feedback records, and audit data for sensitive data exposure.
• Confirm deactivation and rollback steps before opening access to a broader audience.

External channels raise the risk level. A customer-facing agent in Experience Cloud or chat must be tested for authentication state, guest access, account relationship, contact relationship, and data leakage between customers. Guest and unauthenticated access is especially sensitive. If the business wants a public agent, start with public content and no record-specific actions unless the identity and sharing design is fully approved.

Admins should also think about prompt and response data. Users may paste sensitive information into a conversation. If conversation, feedback, or audit data is stored for monitoring, the organization must decide who can view that data, how long it is retained, and whether it can include personally identifiable, financial, health, or regulated details. Monitoring is useful only when the monitoring data is governed.

Study trap: do not solve an agent access problem by making everyone more powerful. If Agentforce Studio is not visible, check app visibility, profile or permission set assignments, tab settings, feature enablement, and required agent permissions. If an agent cannot answer from a knowledge article, check publication status, data category visibility, channel availability, and user access before changing broad permissions. Least privilege is still the admin standard.