Salesforce published its second Agentic Enterprise Index in August 2026. The headline number was agent adoption: the average Salesforce business had five activated agents in February 2025, and 13 by April 2026. Deployment time fell from roughly four days to 1.9 days, a 53% drop. The index draws on aggregated Agentforce platform usage across thousands of businesses, plus a proprietary study of 4,689 respondents fielded in May 2026.
Almost every write-up led with the agent count. It is the wrong number to lead with.
Buried in the same dataset is a second figure: the average number of distinct skills available to each agent rose from two at the beginning of 2025 to six by the end of it. Skills are what an agent can actually do — query a record set, update an opportunity, issue a refund, send an email, call an Apex class.
Multiply them. Five agents with two skills each is ten agent-skill paths. Thirteen agents with six skills each is 78. The count of things your org can do autonomously did not double. It went up roughly eightfold.
That number — call it the action surface — is the one that maps to risk, and almost nobody is tracking it.
What is an agent action surface?
Action surface is the total count of distinct operations your agents can perform without a human in the loop. It is agents multiplied by skills per agent, adjusted for the permissions behind each skill.
It matters because attackers and accidents do not target agents. They target actions. An agent with read-only access to a knowledge base and an agent that can issue refunds are the same "1" in an agent count and wildly different entries in a risk register.
This is the distinction the industry conversation has been missing. Most governance discussion — including our own handbook on agent sprawl, which counted agents — treats proliferation as a headcount problem. Headcount is the visible half. The action surface grows faster, and it grows quietly, because adding a skill to an existing agent requires no new agent, no new approval, and frequently no new review.
A caveat on the arithmetic, stated plainly: the two figures come from slightly different windows. Agent counts run February 2025 to April 2026; skills per agent are measured across calendar 2025. The 7.8x figure is directional rather than a precise same-window multiple. The direction is not in question, and no reading of those windows produces a flat action surface.
Why does action count matter more than agent count?
Because the security industry has already repriced it.
OWASP's 2026 Top 10 for LLM Applications moved excessive agency from sixth place to third, ahead of supply chain and data poisoning risks. Excessive agency is precisely this failure: an agent holding more functional capability than its task requires. It did not climb three places because agents became more numerous. It climbed because each one acquired more to do.
The incident data points the same way. Reporting on agentic deployments through 2026 puts the share of enterprises experiencing at least one agent-related security incident at 88%, with a majority of failures traced to over-permissioned credentials rather than to model behaviour. Prompt injection remains the most common initial vector, and OWASP's 2026 reporting describes it as the fastest-growing attack category year over year.
Read those together and the mechanism is unambiguous. Prompt injection is how an attacker gets an agent to act against intent. The action surface determines what "acting against intent" is able to accomplish. Injection is the key; the action surface is the size of the building.
An org running 13 agents with two skills each has a bad afternoon. The same org at six skills each, with those skills wired to write operations, has an incident.
How do Agentforce actions inherit permissions?
This is the mechanic that makes action surface a Salesforce-specific problem rather than a general AI observation, and it is worth understanding precisely.
Every Agentforce agent runs as a running user — an identity that determines what the agent can see and do. New agents start with no permissions, which is the correct default and the reason Agentforce's security model is defensible in principle.
The complication is what happens next. Agent actions inherit the permissions of what they reference. An action built on an Apex class, a Flow, or a Prompt Template carries that artefact's access rights. Adding the action to an agent extends the agent's effective capability to whatever the underlying artefact can reach.
The consequence is that an agent's real-world capability is not fully described by its permission set. It is described by the union of its permission set and the access held by every Apex class and Flow behind every one of its actions. Adding a sixth skill to an agent that had five can materially widen what that agent can do to your data without anyone opening a permission set, and without the change appearing in any review that looks at agents rather than actions.
Two failure patterns follow directly, and both are common:
- The convenient Flow. A Flow written for an internal admin process, running in system context, gets wrapped as an agent action because it already does the thing. The agent inherits system-context reach for a customer-facing task.
- The reused Apex class. One Apex class serves several actions across several agents. Widening it for one legitimate use case silently widens every agent that references it.
Neither shows up if you audit agents. Both show up if you audit actions.
Why 1.9 days is the real governance number
The index reports that deploying an agent now takes 1.9 days on average, down 53% from about four days in February 2025. That is presented as a productivity result, and as a productivity result it is genuine.
It is also a governance statement. Ask what your organisation's access review cycle looks like. For most enterprises, a permission-set change touching customer data goes through some combination of security review, change advisory, and a release window — measured in weeks, sometimes a quarter.
Agent capability is now being added in under two days. Skills are added to existing agents faster still, because that path frequently avoids the review that creating an agent would trigger.
When the rate of capability creation exceeds the rate of capability review, the gap does not stay constant. It compounds. Every cycle it widens, and the accumulated difference is unreviewed production capability. This is the same structural problem as security debt in a Salesforce org — the mechanism described in the security debt piece — except the unit is an autonomous action rather than a misconfigured field, and the clock runs considerably faster.
Salesforce has shipped tooling that helps here. Summer '26 introduced Agentforce Observability for tracing agent interactions and enforcing policy, and a Security Mesh that folds agent activity into a unified risk view rather than leaving it as a separate data source. These are real improvements. They are also monitoring and detection: they tell you what your agents did. Neither answers the prior question of what your agents are permitted to do, which is the number you can actually reduce.
How do you measure your own action surface?
The measurement is straightforward and most orgs have never run it. Four steps, roughly a day of work.
1. Count the pairs, not the agents. For every active agent, list its enabled actions. The total across all agents is your raw action surface. Include agents in sandboxes that were promoted, agents attached to inactive channels, and anything a partner deployed. If your total is meaningfully below 78 and you consider yourself an average-sized Salesforce shop, your inventory is probably incomplete rather than your estate small.
2. Classify each action by blast radius. Three buckets are enough: read-only, write to non-sensitive objects, and write-or-transact against regulated or financial data. This is the classification that turns a count into a risk figure, and it is where most of the value sits.
3. Trace each action to its underlying artefact and record what that artefact can reach. For each action, name the Apex class, Flow, or Prompt Template behind it, and note whether it runs in system context. Any action whose artefact runs in system context on a customer-facing agent belongs at the top of your remediation list.
4. Find the reuse. Identify Apex classes and Flows referenced by more than one action or more than one agent. These are your amplification points — the places where one change propagates across multiple agents. They deserve change control that individual agent configuration does not need.
The output is a table with one row per agent-action pair. If you already built the agent registry described in the sprawl handbook, this extends it by one level of granularity: the registry lists agents, this lists what each one can do and what that inherits.
What to change in the permission model
Four changes, in rough order of value returned per hour spent.
Give each agent its own running user. Shared running users across agents make the action surface unmeasurable, because the identity's permissions no longer correspond to any single agent's task. This is standard Agentforce guidance and it is frequently skipped for convenience.
Build purpose-specific artefacts for customer-facing actions. The reused internal Flow is the single most common source of inherited over-permission. A narrower Flow written for the agent's actual task is more work once and removes an entire failure class.
Make skill addition a reviewable event. Most change processes gate agent creation and ignore skill addition, which is exactly backwards relative to where the surface grows. Adding an action to an existing agent should require the same review as creating one, because the risk delta is often larger.
Review by action, on a schedule. The question is not "which agents do we have" but "which actions can be taken without a human, and does each still need to be." Actions accumulate; they are almost never removed. A quarterly pass that deletes unused actions is the only mechanism that makes the surface go down.
What this means for your next architecture review
The Agentic Enterprise Index is a genuine adoption milestone, and the deployment velocity behind it is real. The index also reports that 43% of enterprises now expect generative AI to be delivered primarily through autonomous agents, against 31% preferring copilots — so the direction of travel is toward more autonomy, not less.
None of that argues for slowing down. It argues for measuring the right thing while you speed up.
If your last agent governance review produced a count, it measured the visible half. The number that predicts your exposure is the count of distinct actions those agents can take, weighted by what each one reaches — and on Salesforce's own data, that number grew far faster than the agent count everyone reported.
Run the four-step audit. If the resulting table is longer than you expected, that is the finding, and it is better to have it now than after an injection attempt establishes it for you.
For the controls that sit around these agents, see our guide to securing AI in Salesforce and the practical AI governance programme. For the disclosure obligations that attach to customer-facing agents in the EU, see Agentforce and EU AI Act Article 50.
*Figures cited from Salesforce's Agentic Enterprise Index (August 2026) and OWASP's 2026 Top 10 for LLM Applications. Incident-rate figures are drawn from third-party 2026 reporting on agentic deployments and should be read as directional rather than audited.*
