Salesforce has been clear that agents operate on your existing permissions and business rules. That is reassuring until you consider what your existing permissions actually look like.
At Dreamforce, the message on security was consistent: there is no new permissions model. Every agent request runs on the permissions and rules already configured in your org.
Read one way, that is excellent news. No parallel security system to learn, no second set of access rules to maintain.
Read another way, it is the whole problem. Your permissions model was built over years, by different people, for human users who were slow, who paused, and who occasionally asked a colleague whether something seemed right. An agent inherits the permissions without inheriting the hesitation.
Nobody is asking whether your sharing rules are correct. The platform is simply going to act on them, at speed, in more places.
Here is the question that decides how this goes for your organisation: what is an agent allowed to do without a human approving it?
It is not an admin question. An admin can implement any answer you give them, but choosing the answer requires knowing what the business can tolerate getting wrong — and that sits with whoever owns the process, not whoever owns the org.
It is not a security question either, though security has to sign off. Security can tell you what access is dangerous. It cannot tell you whether an agent updating an opportunity stage without review is an acceptable trade for the speed it buys.
In most organisations right now, this question has no owner. It gets answered implicitly, by whoever enables the feature, on the afternoon they enable it.
The most useful governance exercise we run with clients is sorting agent capabilities into four tiers. It takes about ninety minutes and it ends arguments that would otherwise run for weeks.
Tier 1 — Read and summarise. The agent retrieves information and presents it. No record changes. Risk is limited to showing someone data they should not have seen, which is a permissions question you should have answered anyway.
Tier 2 — Draft. The agent produces something a human sends or saves: an email, a summary, a suggested next step. Nothing happens without a person acting. This is where most organisations should start and where many should stay for a quarter.
Tier 3 — Act, reversibly. The agent changes a record, creates a task, updates a field. If it gets it wrong, you can undo it, provided you can detect it. Field History Tracking and audit logging stop being nice-to-have at this tier.
Tier 4 — Act, irreversibly or externally. The agent sends a message to a customer, triggers a payment, updates a system outside Salesforce, deletes something. You cannot unsend an email. This tier needs explicit approval, named ownership, and a documented rollback plan that is more than optimism.
The exercise is not to decide that Tier 4 is forbidden. It is to make sure nobody reaches Tier 4 by accident while enabling something that sounded like Tier 2.
The single most common governance failure we find has nothing to do with agents specifically. It is the integration user running as System Administrator.
It is everywhere, it is almost never necessary, and it becomes considerably more consequential when the thing using those credentials can act autonomously.
What good looks like:
- A dedicated user per agent or per agent function, never a shared one
- Permissions scoped to the objects and fields that function actually needs
- No Modify All Data, no View All Data, unless you can articulate precisely why
- API access granted deliberately rather than inherited from a profile
- Login IP restrictions where the architecture allows
- An owner’s name attached, so there is somebody to ask in six months
If an agent can do everything, then anything that compromises it can do everything. That was always true of integration users. The difference is that an agent is designed to act without being asked.
Blanket approval requirements get disabled within a month because they make the agent useless. Blanket autonomy gets you an incident. The workable answer is thresholds.
Thresholds people actually use:
- By value. Agent acts freely below a deal size; requires approval above it.
- By object. Free rein on activities and tasks; approval on opportunities and contracts.
- By audience. Internal actions unsupervised; anything customer-facing reviewed.
- By volume. Single-record actions proceed; bulk operations above a record count stop and ask.
That last one catches the failure mode that actually hurts: not the agent doing one wrong thing, but the agent doing one wrong thing four thousand times before anyone looks.
You cannot govern what you cannot see. Before any agent reaches Tier 3, you need to be able to answer three questions after the fact:
What did it do? A log of agent actions, attributable to a specific agent and a specific request.
Why did it do that? Enough context to reconstruct the reasoning, or at least the inputs. “The agent decided to” is not an acceptable answer in an incident review.
Who was affected? The ability to identify every record touched in a given window, so remediation is a query rather than an archaeology project.
If your answer to any of these is that you would have to work it out, you are not ready for Tier 3.
The governance structure that works in practice is small:
A named business owner per agent. Not a committee. One person who can say what that agent is for and what it must never do.
Security as approver, not operator. They sign off on the permission scope. They do not run the agent.
The admin as implementer. They build what the business owner and security agreed on, and they are not the ones deciding the policy.
A review cadence. Quarterly is enough. What changed, what it did, what it got wrong, what the threshold should be now.
Four roles. Most organisations can fill them in a week and most have not filled them at all.
Week 1. Inventory what is enabled today. Not what you plan to enable — what is already on, and under whose credentials.
Week 2. Run the four-tier exercise with the business owners of each process. Write down where each capability lands and why.
Week 3. Fix the integration users. Scope the permissions. Remove the administrator profiles that were never justified.
Week 4. Set thresholds, turn on logging, name the owners, and schedule the first quarterly review.
None of this requires buying anything. All of it is cheaper than the alternative.
The reassuring version of “agents use your existing permissions” and the alarming version are the same sentence. Which one applies to your org depends entirely on whether your permissions model was designed or accumulated.
Most were accumulated. That is normal, it is not anyone’s fault, and it is fixable — but it is fixable before you scale agent capability, not afterward.
Decide what agents may do without a person. Write it down. Give it an owner. Then enable things.
