By NHI Mgmt Group Editorial TeamDomain: Agentic AI & NHIsSource: SaltPublished June 22, 2026

TL;DR: AI agents connected to APIs can explore and exploit weak authorization paths faster, turning an already serious API vulnerability into a scalable access problem, according to Salt Security. The underlying issue is that agentic access changes the speed and reach of abuse before teams have closed governance gaps.


At a glance

What this is: This is a Salt Security blog collection on AI agents, APIs, and the risk that agentic access makes weak authorization paths easier to exploit.

Why it matters: It matters because IAM, IGA, PAM, and platform teams need to understand how agent-driven API use changes access control assumptions across both NHI and human-admin workflows.

👉 Read Salt Security’s analysis of AI agents, APIs, and weak authorisation paths


Context

AI agents connected to APIs can accelerate abuse of weak authorization paths because they do not just call endpoints, they can chain calls and explore surface area faster than a human operator. In identity terms, that turns API authorization from a static permission check into a runtime governance problem for non-human access.

Salt Security frames the issue around the action layer, where one API call, one tool invocation, and one data request can look normal in isolation while the combined sequence produces an unintended result. That is the core IAM challenge for teams governing NHI, delegated access, and emerging agentic workflows.


Key questions

Q: How should security teams govern AI agents that call APIs instead of using a UI?

A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login. The key control is to limit which APIs, data sources, and write actions the agent can chain together in one session. That keeps machine-paced behaviour inside a reviewable boundary instead of relying on human-style session assumptions.

Q: Why do AI agents make broken authorization more dangerous?

A: AI agents make broken authorization more dangerous because they can call APIs repeatedly and at machine speed using the same credential scope. If that scope is too broad, the agent can enumerate or retrieve far more data than a human user could before detection. The underlying issue is blast radius, not just identity.

Q: What breaks when API security focuses only on single requests?

A: Single-request thinking misses the combined effect of sequential calls. An agent can use several individually valid actions to reach data, trigger approvals, or change state in ways no isolated request would justify, so the real control boundary is the workflow.

Q: How do organisations reduce risk from delegated access in agentic systems?

A: They should restrict tool discovery, separate read and write paths, and limit which context travels between tools. If the agent cannot discover unnecessary capabilities or carry broad context forward, the chance of unintended action sequences drops sharply.


Technical breakdown

Why API authorization breaks down with AI agent behaviour

Traditional API security assumes a relatively stable client, known call patterns, and predictable intent. AI agents weaken that model because they can decide which endpoint to call next, which tool to use, and how to combine requests across a session. Even when each individual call is valid, the sequence can create privilege amplification, data exposure, or workflow abuse. The issue is not only authentication. It is the mismatch between static authorization decisions and dynamic runtime behaviour across delegated access paths.

Practical implication: map which APIs can be reached through delegated or agent-driven paths and review them as an access chain, not as isolated endpoints.

The action layer creates compound risk

The article’s key point is that the visible request is often not the actual risk. A normal-looking API call can become harmful when paired with other calls, context, or timing inside the same agent workflow. This is especially relevant where tools expose search, write, approve, or export functions through one identity. For IAM teams, the concern is not simply whether a token exists. It is whether the identity can compose valid actions into an outcome that no reviewer would have approved upfront.

Practical implication: treat multi-step agent workflows as a control boundary and test for harmful outcomes that emerge only after call chaining.

MCP security changes the trust model for delegated access

MCP introduces an additional decision layer between the agent and the tools it can reach. That means authorization is no longer just client-to-server access control. It also involves tool discovery, delegated authority, and context that may influence what the agent chooses to do next. Once that layer exists, policy must account for both permitted access and the behaviour enabled by context propagation. This shifts the control problem toward governance of tool reach, not just secret possession or API authentication.

Practical implication: restrict tool discovery, scope delegated authority tightly, and validate that context passed into tools cannot widen effective access.


Threat narrative

Attacker objective: The attacker wants to use agentic access to discover and exploit weak authorization paths at scale, producing outcomes that bypass the intent of the underlying access model.

  1. Entry occurs when an AI agent is connected to APIs through valid delegated access and begins using normal-looking requests to reach sensitive functions.
  2. Escalation occurs when the agent explores weak authorization paths, chains permitted calls, and uses contextual data to broaden the effective scope of access.
  3. Impact occurs when the combined sequence produces an unintended business or data outcome that no single request would have triggered alone.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Agentic access turns API security into an identity governance problem. The article is not really about APIs alone. It shows that once an AI agent can choose actions across tools and endpoints, the control question becomes who or what is allowed to assemble those actions into an outcome. That matters because identity teams are responsible for the permission model behind the workflow, not just the API surface. Practitioners should treat agent-connected APIs as governed identities with behavioural risk.

Weak authorization paths become more valuable when an agent can search for them dynamically. A human attacker can only probe so fast, but agentic access compresses discovery, testing, and exploitation into the same runtime window. That changes the economics of abuse across NHI and delegated human workflows. The practical conclusion is that speed is now part of the authorization threat model, not just a detection concern.

Context propagation is the hidden risk multiplier in tool-driven systems. When an agent carries context from one tool to another, the security boundary is no longer the token alone. The identity problem shifts to what the context lets the agent infer, request, or trigger next. That is why teams need to govern tool reach and data exposure together, especially where APIs expose write or approval functions.

Action-sequence risk deserves its own named concept: action-layer exposure. One request may be harmless, but the sequence of requests can still create an unintended outcome. That means review processes built around single-call authorisation miss the actual threat surface. Practitioners should reframe controls around the full action chain, because that is where agentic misuse becomes visible.

Existing API security assumptions were designed for deterministic clients, not runtime decision makers. That assumption fails when the actor can select tools, change paths, and continue without human approval. The implication is not simply that more controls are needed. It is that the governance model must be rebuilt around behaviour, delegation, and session-level intent rather than static endpoint trust.

From our research:

  • 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
  • 52 NHI Breaches Analysis shows that standing access and weak lifecycle offboarding remain recurring breach patterns across machine identities.
  • As AI agent deployments grow, review how OWASP Agentic AI Top 10 maps tool misuse and action-chain abuse to your control model.

What this signals

With 80% of organisations already reporting AI agents acting beyond intended scope, the governance problem is no longer hypothetical. Teams that still manage agent access like static automation will miss the moment when a request sequence turns into an access decision.

Action-layer exposure: the real boundary is the sequence of tool calls, not the first authenticated request. That means identity programmes need review points for tool reach, context propagation, and downstream effect, or else API authorisation will continue to fail at runtime.

For practitioners building controls around agent-connected APIs, the next step is to align governance with OWASP Agentic AI Top 10 and test whether delegated access can be abused without any single control visibly failing.


For practitioners

  • Audit agent-connected API paths Inventory every API, tool, and data source reachable through AI agents or other delegated non-human identities. Rank paths by write capability, approval capability, and access to sensitive records so you can focus review on the highest blast radius first.
  • Constrain tool discovery and delegated authority Limit which tools an agent can discover, not just which credentials it holds. Review context propagation, deny unnecessary write functions, and ensure delegated authority cannot silently widen through chained tool use.
  • Test for harmful call chains Simulate multi-step agent workflows and look for unintended outcomes that only emerge after several valid requests. Use these tests to expose where sequential actions cross from legitimate access into business logic abuse.
  • Separate authentication from behavioural trust Treat a valid token as necessary but not sufficient. Add controls that evaluate the action sequence, session context, and downstream effect before sensitive operations are permitted.

Key takeaways

  • AI agents change API abuse from isolated request risk into workflow risk, which pushes the problem squarely into identity governance.
  • The article’s central warning is that weak authorisation paths become easier to exploit when an agent can explore and chain calls in one runtime window.
  • Practitioners should govern tool reach, context propagation, and multi-step outcomes together because single-call review no longer captures the real exposure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10Agent-connected API abuse and tool misuse are core agentic risks in this article.
OWASP Non-Human Identity Top 10NHI-01The article centres on NHI access paths and delegated credential abuse.
NIST Zero Trust (SP 800-207)Section 3The article’s weak authorization paths map to zero-trust verification of every access decision.
NIST CSF 2.0PR.AC-4Least-privilege access and access authorisation are the primary control themes here.

Review agent workflows for tool misuse, prompt injection, and chained actions before broad deployment.


Key terms

  • Action-layer exposure: The risk that emerges from a sequence of valid actions rather than from any single request. In agentic systems, this matters because the harmful outcome often appears only after tool calls, context propagation, and state changes combine inside one session.
  • Delegated Agent Authority: The permission granted to an AI agent to act on behalf of a human user or another agent, inheriting some or all of their access rights. Delegated authority must be explicitly scoped, time-limited, and auditable.
  • Context propagation: The passing of prior conversation, data, or state between tools or sessions so an actor can make use of it later. In agentic environments, context can become an access multiplier if it helps the system infer, trigger, or justify actions beyond the original request.

What's in the full article

Salt's full blog covers the operational detail this post intentionally leaves for the source:

  • Step-by-step examples of how AI agents exploit weak authorization paths across API-connected workflows
  • Operational detail on MCP-driven tool discovery and how delegated authority changes the trust model
  • Implementation guidance for separating read, write, and approval paths in agent-connected systems
  • Examples of how to test harmful multi-step outcomes before they reach production

👉 Salt Security’s full post covers the action-layer problem and the API security implications in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org