Agentic AI Security: Why Valid Credentials Can Still Enable Risky Actions

When valid access produces the wrong action

An AI agent can use valid credentials and send a request through an API that accepts it, yet still take an action its organization never intended. That gap between technical access and organizational authorization is the security issue examined in Salt Security’s State of Agentic AI and API Security 2H 2026. The distinction matters because an accepted request proves only that the system permitted the call under its current rules. It doesn't prove that the agent had a sound reason to make it, or that the resulting action fits the organization’s expectations.

That’s a more useful way to frame agent security than treating every unwanted action as a conventional break-in. An agent might operate within the permissions it was given and still produce an outcome that people consider improper, excessive, or out of bounds. The failure can sit in how permissions were assigned, how the task was described, or how the API interprets a request. In practice, those causes may overlap.

What the report sets out to examine

The report draws on a survey of more than 380 security and technology professionals, alongside telemetry from Salt Labs, Salt Security’s research arm. Those are different forms of evidence: a survey captures what practitioners report and perceive, while telemetry can reflect observed activity in the systems Salt Labs monitors. The source doesn’t specify the survey questions, the telemetry’s scope, or the findings themselves, so the stated methodology should be read as context for the report rather than proof of any particular trend.

Its stated value is in treating agent permissions as a governance question, not as automatic evidence of a broad security crisis. That restraint is useful. A report about a growing technology category can easily turn a plausible risk into an inevitable catastrophe; here, the central question is narrower and more actionable. Do the API calls an agent is allowed to make match the actions the organization expects it to take?

Why API access and authorization can diverge

An API is an interface through which software requests data or actions from another system. In a typical setup, credentials and permission checks help determine whether the requester can make a particular call. Those controls answer a defined technical question: is this identity permitted to perform this operation? They may not answer the more contextual question of whether this operation makes sense for the current task, user, or business process.

Agentic systems add a layer between a person’s goal and the API request that carries it out. The agent interprets instructions, selects steps, and may call tools along the way. If an organization gives it broad access to make that process easier, the agent could have room to act beyond what a person meant by a particular instruction. Conversely, narrow permissions can limit the damage from a mistaken or misunderstood request, though they can also constrain what the agent can accomplish.

Here’s the thing: the API can behave exactly as designed and still be part of a bad outcome. If the agent’s credentials authorize an action and the request meets the interface’s requirements, the system may have no basis for distinguishing a sensible call from one that violates an unstated expectation. The technical control has done its job according to its rules. The organization may still have failed to make those rules reflect its intent.

Permission design is a continuing task

Permission decisions are often made around identities, software roles, and categories of operation. Agent behavior introduces another practical consideration: what actions should be available for a given task? An agent that needs to read information may not need permission to change it. A workflow that calls one service may not need authority to reach several others. This is the logic behind limiting access to what a system needs, applied to software that can choose and sequence actions on a person’s behalf.

That design can be difficult because an agent’s usefulness often depends on being able to complete multi-step work. Grant too little access, and routine tasks can stall or require repeated human intervention. Grant too much, and an error in interpretation can travel farther through connected systems before anyone notices. There’s no single permission setting that resolves this tension; the relevant boundary depends on the task and the consequences of each available action.

(And this is the part most people overlook.) A list of approved API calls is only one piece of the governance problem. Organizations also need a clear account of why an agent is permitted to make those calls, which tasks the permissions support, and how people can review activity when an outcome looks wrong. If those connections aren’t clear, teams may know that a request succeeded without being able to explain whether it should have happened.

What security teams should take from the framing

Salt Security’s framing points security and technology teams toward a practical review: compare the agent’s permissions with the organization’s intended use of it. That means looking at the actions an agent can take through APIs and asking whether each one belongs in its assigned role. It also means checking whether the task description and the permission model leave room for different interpretations. The report’s summary doesn’t provide specific findings or a checklist, so those questions are implications of its stated argument, not claims about what the report recommends in detail.

If you’re working in this space, the important distinction is between a control that blocks an unauthorized request and a control that helps keep an authorized agent within an appropriate task. The first may be relatively straightforward to define in an API. The second depends on organizational choices about scope, oversight, and acceptable behavior. Those choices need to be reflected in the system’s permissions if they’re to affect what it can do.

Implications for agent deployment

This is more significant than it looks because successful API authentication can create a false sense of reassurance. A request can carry valid credentials, pass the available checks, and still expose a mismatch between what the organization intended and what the agent was allowed to do. That doesn’t establish that such failures are widespread, and the source provides no figures about incidents. It does identify a real design question for any organization connecting agents to APIs.

For now, the useful test is concrete: can the organization explain why an agent has each permission it holds, and how that permission relates to the work it’s supposed to perform? If the answer depends on assumptions no one has written down, the permissions may be broader than the intended role. A narrower, task-aligned model won’t settle every question about agent behavior. It can, however, make the boundary between an allowed call and an expected action easier to see.

That’s the report’s most grounded contribution as described here. It directs attention to the distance between what software can do and what an organization means for it to do. A valid credential establishes access. Intent requires governance.