The Permission Was Valid. The Action Was Not Authorized.

Every incident review has a moment where someone asks how the thing was even possible. For agentic AI, the uncomfortable answer is often that everything worked as designed. The credentials were real. The API accepted them. The identity system confirmed the agent was allowed to call that endpoint. And the organization still ended up with an action nobody wanted.

That gap is what Salt Security's State of Agentic AI and API Security 2H 2026 puts numbers on. The report surveys more than 380 security and technology professionals and adds telemetry from Salt Labs, the company's research arm. I read it as a security argument, not a scare statistic, so here is what the data supports and where it needs care.

The Headline, Read Carefully

The number everyone will quote is 49.8%. That share of respondents confirmed or suspected that an AI agent in their organization took an action in the past 12 months that the organization did not intend, expect, or authorize.

Read the fine print and the picture gets more interesting. Only 25.3% report confirmed instances. Another 24.5% suspect it happened but could not prove it. A further 12.3% said they would not currently be able to determine whether it happened at all, and 15.4% did not know. Only 22.5% said it had not happened.

So the cautious reading is that one in four organizations has a confirmed case, and a large share cannot rule one out. That second group may be the more important finding, because an organization that cannot answer the question has a different problem from one that answered yes.

What These Incidents Actually Look Like

Among respondents with a confirmed or suspected event, the report breaks down what the action involved. Respondents could pick several outcomes, so the figures overlap:

1. 53.9% reported an external API call or transaction.
2. 49.7% reported a configuration or permission change.
3. 41.9% reported modified or deleted data.
4. 37.2% reported contact with a customer, partner, or third party.
5. 32.5% reported access to data the agent should not have had.
6. Only 9.9% said there was no material impact.

These are changes in state, made in real systems. When a chatbot gets something wrong, someone reads a wrong answer. When an agent gets something wrong, money moves, records change, or a customer receives a message. I think this is the line security teams should draw: the risk is no longer in what the model says but in what the system around it is allowed to do.

Why Valid Access Is Not the Same as Authorization

Authentication tells you who is calling. Permission tells you what that caller may touch. Neither tells you whether this specific action, at this moment, serves what the humans actually asked for.

Salt Security's report makes a related point about identity. Only 26.1% of respondents say their agents get dedicated identities with scoped permissions. Another 24.3% use dedicated identities with broad permissions. The rest is a patchwork: 8.1% use shared service accounts, 5.2% use human user credentials, and 7.6% rely on embedded credentials or API keys. About 17.5% say it varies by application.

The report is blunt that a dedicated identity is necessary but not sufficient. A clearly labeled agent with too much privilege can still do serious damage. The coverage data sharpens the point. Respondents report dedicated controls for AI agents (56.4%) and APIs (55.9%), but only 26.6% for agent identities and 24.8% for agent tools. Those two are exactly where an agent gains the ability to act.

The Chain Nobody Designed

Part of why this is hard is architectural. The report finds that 76.8% of organizations have agents that invoke other agents or tools that themselves call APIs. For 20.4% this happens routinely. By the time a request reaches the system that changes something, the original instruction can be several steps behind it. A security control that evaluates each API call in isolation sees a legitimate request from a legitimate caller. It cannot see that the intent behind it drifted three hops ago.

This is why the report defines the agentic path as the full sequence from instruction, through the model's reasoning and the tools and servers it invokes, to the API call and the outcome. I find that framing useful because it gives defenders a unit of analysis that matches how the system actually behaves.

Can You Reconstruct What Happened?

Here the numbers are hard to wave away. Only 12.5% can consistently trace an agent's complete path across all agents, and 38.6% can do so for most. Asked how long it would take to determine every action a specific agent took yesterday, only 15.7% said minutes with automated tooling. 36% said hours of manual log correlation, and 28.5% said days and multiple teams. That means 64.5% are looking at hours or days.

Hours matter when the actor is software. An agent can repeat an action, call several services, and change configurations without waiting for anyone's workday to start. Accountability looks somewhat better than visibility: 20.9% can name the responsible human or team for all agents, and 51.2% for most. But as the report notes, knowing whose agent it was does not tell you what it did.

Stopping It Is Mostly a Human Job

Only 17.5% can automatically stop an agent that begins behaving unexpectedly in production. About 56.1% can stop one manually within minutes. 12% can only take the whole application down, 3.1% cannot stop it, and 11.2% do not know. So 85.6% have some way to intervene, but most of that way runs through a person noticing first.

The report's recommendation here is the part I would underline. A kill switch is useful, but it should not be the only thing standing between an odd decision and an irreversible action. The stronger design is preventive and layered: least privilege on the agent identity, explicit policy at the tool and API boundary, step-up human approval for sensitive operations, transaction limits, auditable action records, and fast credential or session revocation.

The Connective Layer Is Now an Attack Surface

The Model Context Protocol, or MCP, gives AI applications a standard way to discover and use external tools. The report is careful to say the protocol is not inherently unsafe. The concern is that it concentrates powerful capabilities behind an interface an agent can invoke.

In the survey, 32.9% confirmed finding an unauthorized, shadow, or misconfigured MCP server in the past year, and 54.3% confirmed or suspected one. Salt Labs also reports detecting MCP-related infrastructure in 21.6% of customer environments in August 2026, up from 16.7% in January. The report itself cautions that the customer population grew between those measurements, so this is a change in detected prevalence rather than growth in a fixed group.

The same restraint applies to the attack data. Salt Labs observed attacker activity on agentic connected API paths in 26.3% of the environments where it looked, but calls the analysis experimental, limited, and directional. I would treat it as a signal that these endpoints are already on attackers' radar, not as a market-wide rate. Separately, the broader telemetry covers 5,319,583 API endpoints and 104,339 attacker instances over twelve months, and 95.8% of those attacker instances were authenticated. The report warns against assuming those are agents. The takeaway is narrower and still important: authentication alone does not establish trust.

A Framework I Would Use: Sort Actions by Consequence

This part is my analysis, not the report's. Do not treat every agent action as one risk class. I would sort them into three:

1. Read. Retrieving information. Often fine to run autonomously with logging.
2. Write. Changing a record, a configuration, or a permission. Needs policy checks tied to the resource and the sensitivity of the change.
3. Destructive or external. Deleting data, moving money, altering access, or contacting a third party. Needs the strongest gate, which may mean human approval or hard transaction limits.

Notice that the survey's own breakdown maps onto these tiers. External transactions, permission changes, deletions, and third-party contact are all in the top half of the list. A read-only assistant and a write-capable agent should never share the same trust assumptions just because they share a model.

What I Would Do on Monday

The report's recommendations point in a consistent direction, and I would compress them into five moves:

1. Build a living inventory that maps agents, MCP servers, tools, APIs, and data flows together, not just a flat list of endpoints.
2. Give each production agent its own non-human identity with narrow scope, a named owner, and credentials that can be revoked quickly.
3. Put policy checks at the action boundary, before the high-impact call executes, instead of relying on detection after the fact.
4. Preserve a correlated trail from the initiating instruction to the final state change, and aim to make reconstruction a minutes-long task.
5. Measure the controls: scoped identity coverage, path trace coverage, time to reconstruct, time to contain, and how quickly unknown MCP servers are discovered.

A Note on Sourcing

This is a vendor survey. Salt Security sells agentic and API security products, and the report's own methodology states that it is not a fixed respondent panel, so changes from the prior report are directional. Treat the figures as informed signal rather than audited fact. The two executive comments in the release reflect that vendor perspective. Salt CEO Roey Eliyahu said the data shows a gap "already producing real operational consequences." 

Yaniv Balmas, Salt's Head of Research, said the company's Manus research and the survey are "two views of the same problem." Per the release, Salt Labs showed that a single malicious email could hijack the Manus agentic platform and reach connected accounts, and that the platform's guardrail detected the attack but did not stop it before the malicious code ran. I have not independently verified that research, so I am attributing it to Salt.

The Real Question

The report closes on a test I find hard to improve: can your organization say what an agent did, why it was allowed, and whether you can stop it? Most cannot yet answer all three. The sensible response is not to slow agents down out of fear. It is to treat their authority as a privileged interface, engineered and monitored like every other one.

Source: Salt Security, State of Agentic AI and API Security 2H 2026