Who Has Access to Your AI Agent? A Governance Framework for Agentforce in Production

On August 8, 2025, an attacker who had never logged into your Salesforce org started running SOQL against your Account table. They didn't need a password. They had an OAuth token for Salesloft Drift, a chatbot. By the time Salesforce revoked the tokens on August 20, more than 700 organizations had been compromised, User and Case records had walked out wholesale, and embedded credentials buried in support comments (AWS keys, Snowflake tokens, VPN URLs) were on someone's hard drive in another country.

Now ask yourself the same question about your Agentforce agent.

Drift was a third-party chatbot with broad scope and indefinite tokens. Your Agentforce agent is first-party Salesforce. The brand on the door is different. The failure mode is identical: an over-permissioned, persistently authenticated, AI-adjacent identity with no anomaly detection, sitting on top of years of permission drift no one has time to clean up.

This post is the governance framework we use with clients moving an Agentforce pilot into production. Six layers, in priority order, with the parts most teams skip called out by name.

What "the agent" actually is

Before the framework, a vocabulary check.

An Agentforce agent is not a black box. It is a Salesforce user — license type Einstein Agent, auto-provisioned the moment you create the agent in Setup. Like any user, it has a profile, permission sets, sharing access, FLS, and a stack of permission set groups. Whatever that stack adds up to is the entire blast radius of every conversation, every Apex action, every external callout the agent makes. Nothing more. Nothing less.

Two execution patterns matter:

Agent-as-user. When you call the Agent API with bypassUser=false, the agent answers in the context of the logged-in user authenticated via OAuth Web-Server flow. Sharing rules, FLS, and permission sets all evaluate against that human. Demos work. Audits work. Everyone sleeps.

Agent-with-its-own-identity. When you call with bypassUser=true (most production deployments, because the use cases that justify Agentforce don't have a logged-in user attached), the agent runs as the agent user. Every reply is governed by what the agent user can see and do, not the requester. This is the path where a sloppy permission set group becomes a regulatory event.

If you don't know which pattern your team picked, that's the first finding to log.

The six-layer framework

Treat this as layered defense. Each layer assumes the one above it might fail, because in the orgs that get breached, exactly one layer usually has.

Layer 1: Identity and authentication for the agent itself

The agent gets its own license. Its own permission set group. Its own Connected App with its own client_id, scoped IP ranges, and short-lived OAuth tokens. Refresh tokens with no expiry are the Drift mistake; do not repeat it.

Rotation is calendared, not "when something breaks." Vault the secret. Audit who can read it.

If your agent is sharing credentials with a human user or with another integration, you don't have an agent. You have a backdoor.

Layer 2: Permission scope, persona-based and least privilege

This is where most production agents fail their first audit.

Build the agent user's access from a permission set group composed of three layers: a base set (login, app access), a read set (UI navigation), and one or more persona sets that grant the actual data permissions. This is the pattern the Salesforce Admins blog documents for Agentforce readiness.

Three rules, no exceptions:

• FLS is audited explicitly per topic. Default deny. A field gets read access only when a topic demonstrates need.
• View All Data and Modify All Data never appear on the agent user. Ever.
• The persona set is named for the agent's job, not cloned from a power user "to make the demo work."

If you cannot do this, if the conversation in the room is "we have several dozen nearly-identical sales profiles and nobody knows which one to clone," you don't have a permissions problem you can solve in a sprint. You have an over-permissioning problem that is going to swallow this whole project. Stop and fix that first. The rest of the framework cannot help you.

Layer 3: Topic and action allowlisting

A topic groups instructions. An action is the thing the agent can actually do: Apex, Flow, Prompt Template, External Service. Layer 3 is about the action list.

Maintain it as a controlled artifact, not a screenshot. Every action gets classified: read-only, write, external-callout, or financial. Anything write-tier gets routed through Layer 5 (approvals). Anything financial gets reviewed by name.

The setting most teams miss: every action is either public (no end-user identity required) or private (verification required). Salesforce ships a Customer Verification topic out of the box that can email a one-time code and gate access to the private subagent. Default to private for anything touching a Person Account, Case, Opportunity Amount, or Quote. The OTP friction is real. So is a refund issued to the wrong customer.

One more trap. Apex actions can run without sharing. The topic-level access list says one thing; the Apex underneath ignores sharing rules entirely. FLS still applies, but only if the developer enforced it explicitly. Ask your team to grep your action classes for without sharing and review every result. This is how the access matrix gets bypassed without anyone changing a permission set.

Layer 4: Audit logging and monitoring

Three Salesforce features, three jobs.

Event Monitoring (or Shield Event Monitoring for the full 74+ event types and EventLogFile retention up to your contracted Shield window, typically a year) captures API events, Apex execution, and login events. EventLogFile is the system of record. Without it, "who did this?" has no answer.

Setup Audit Trail captures every change to the agent definition, the topic list, the action wiring, and the permission sets. You will need this in month three when someone added an action and forgot to mention it. Plan the retention now.

Field Audit Trail (Shield) goes on the high-risk objects the agent touches: Case, Opportunity, Contact. The retention window is your compliance requirement, not Salesforce's default.

Agentforce's own observability (Agent Analytics, Agent Optimization, Agent Health) is operational telemetry. It tells you uptime, latency, KPIs. It is not a substitute for security event logging. Don't conflate them.

Layer 5: Approval and escalation patterns

Some actions don't get to autocommit. The list is short and concrete:

• Mutating an Opportunity past Closed/Won
• Sending a contract or DocuSign envelope
• Issuing a refund or credit
• Modifying user records, sharing rules, or permission sets

Wire these through an approval Flow. The agent surfaces the proposed write. A named human confirms. Both sides of the transaction get logged. The pattern is "speak before you act," and it's the only thing standing between a 3 a.m. mistake and a Monday-morning incident call.

Add volume thresholds to the same monitoring layer. An agent that updated one record per hour for a month and then updates 200 in ten minutes is telling you something. Catch it on the agent's session and action telemetry, alert on it, and treat the alert as a potential security event until proven otherwise.

Layer 6: Lifecycle, from dev to test to prod gating

The agent is metadata. Treat it like metadata.

New topics and actions land in a sandbox first. They get tested in the Agentforce Testing Center. Their permission diff is reviewed. Then they promote.

Production deployment requires sign-off from a named role: data owner, security, or RevOps lead. That role is not "the admin who built the agent." If the same person designs and approves, the framework's six layers reduce to one person's judgment, and that's the governance posture Drift's customers had.

A pre-prod permission audit runs on the agent user before every promotion. If the permission set group has expanded since the last review, the promotion blocks until someone explains why.

The mess underneath

The framework above assumes you can answer one question: what does the agent user actually have access to?

In most orgs we audit, you cannot.

Years of profile inheritance, ad-hoc permission set assignments, FLS that nobody remembers granting, and 30 sales profiles that differ from each other in ways no one can fully explain. That's the substrate the agent inherits. Layer 2 is impossible on top of that. There is no clean baseline to least-down from.

Permission set hygiene is a prerequisite for safe AI agent deployment, not a parallel project. Permission set migration is no longer optional, and the Spring '26 profile-to-permission-set transition has put a clock on it.

If your team is staring at 40–80 hours of profile-to-permission-set conversion work, SimplePerm is the tool we built for this. It does the mapping work and gets you to a clean baseline the framework above can sit on top of.

What to do this quarter

You don't need a quarter to make this safer. You need a week.

1. Pull the permission set group on your Agentforce agent user. Read it line by line. If View All Data is in there, that's your first finding.
2. Open Setup Audit Trail. Look at the last 90 days of agent definition changes. If you can't reconstruct who added what, your audit posture is already a finding.
3. Grep your action Apex for without sharing. Review every match.
4. Turn on Event Monitoring against the agent user, even if all you do this week is start collecting.
5. Decide which two or three actions need approval flows. Wire those before next week's release.

Six months from now, your auditor will ask: who edited that opportunity?

The right answer is the agent user, then a topic, then an action, then an Apex class, then a logged approval, then a named human, with a timestamp on every step.

The wrong answer is the one most orgs will give.

If you're standing up an Agentforce production deployment and the access matrix isn't clear, Simplementix audits the agent user's permission set group, the topic-action wiring, and the event-monitoring posture as a one-week engagement. The specific six-layer audit above, run by people who have shipped agents and cleaned up the orgs underneath.

Related articles

Picking Your Post-CPQ Path for Mid-Market RevOps: Revenue Cloud, Composable, or Wrap-with-Agents

Salesforce CPQ went end-of-sale. Choose between Revenue Cloud, composable, and wrap-with-Agents using a four-axis framework built for mid-market RevOps.

Read Article →

Lightning Sync to Einstein Activity Capture: a 4-sprint migration playbook for mid-market RevOps

Salesforce retires Lightning Sync in August 2026. Migrate to Einstein Activity Capture without breaking dashboards: a 4-sprint playbook for mid-market RevOps.

Read Article →