API action layer security is becoming the new AI attack surface

At a glance

What this is: This is a year-end analysis of how APIs, AI agents, and MCP servers combined to expand the attack surface, with a focus on the API action layer as the control point.

Why it matters: It matters because IAM, PAM, and security teams now have to govern machine-to-machine and agent-driven access patterns that can outpace traditional review, inventory, and perimeter controls.

👉 Read Salt's year-end analysis of API action-layer risk and AI agents

Context

API security is moving from a perimeter and inventory problem to an action-governance problem. As AI agents and MCP servers sit on top of the same API fabric that powers applications and data exchange, the real risk is not just exposure but uncontrolled execution across service boundaries. For identity and access teams, that creates a direct link between API governance, NHI controls, and agentic AI oversight.

The article’s core point is that visibility, context, and enforceable policy now matter more than static discovery alone. When automated systems can call tools, execute actions, and move data without clear human oversight, the identity question shifts from who signed in to what identity is authorised to do at runtime. That is a familiar IAM and PAM problem, but in a new operational shape.

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 APIs create a larger identity risk surface in AI-enabled environments?

A: APIs become the execution boundary for software agents, workflow automation, and backend services, so any overbroad token can reach multiple systems. The risk is less about the endpoint itself and more about delegated capability spreading across connected services. Teams should measure blast radius, not just access count.

Q: What breaks when shadow APIs are not inventoried and owned?

A: When shadow APIs are not inventoried and owned, security teams lose the ability to prove who exposed them, which identities can reach them, and whether logs exist for investigation. That creates a blind spot for access control, incident response, and compliance evidence. The practical failure is not just unknown traffic but unknown responsibility.

Q: What should organisations do when API security and AI governance overlap?

A: Unify discovery, access control, and runtime monitoring under a single operating model. The goal is to know which identities, human or non-human, can invoke which actions, under what conditions, and whether those actions still match the approved business purpose.

Technical breakdown

Why the API action layer is now the control plane

The API action layer is where applications, agents, and data exchange decisions become real. In practice, this is the point where authentication, authorisation, and request context converge, so weaknesses here affect both traditional app traffic and agent-driven workflows. When AI agents operate over APIs, they inherit whatever trust model those APIs expose, including excessive permissions, vague scopes, and poor context enforcement. That makes API governance a runtime control problem, not just a design-time one.

Practical implication: teams need to govern API permissions as runtime access decisions, not just catalogue endpoints.

How AI agents and MCP servers widen the attack surface

AI agents can chain tool calls, and MCP servers extend that behaviour by connecting models to external data sources and actions. That expands the attack surface because each tool connection introduces new credentials, scopes, and trust assumptions. If those connections are weakly scoped or poorly monitored, an agent can misuse legitimate access in ways that look operationally normal but are security-relevant. The result is a blended identity and application risk, where machine identities and delegated actions become the control boundary.

Practical implication: inventory tool connections, bound scopes, and delegated privileges before agent workflows reach production.

Why discovery alone is not enough for API governance

Discovering APIs, shadow services, and unmanaged connections is only the first step. The harder problem is understanding which APIs are business-critical, which identities can invoke them, and which actions are safe under current policy. Modern environments accumulate zombie APIs, misconfigured integrations, and automation paths that survive longer than the teams that created them. Without policy enforcement and continuous context, discovery becomes a list of assets rather than a usable control system.

Practical implication: pair discovery with ownership, policy enforcement, and continuous review of high-risk API paths.

Threat narrative

Attacker objective: The objective is to turn legitimate API and agent access into unauthorised execution, data movement, or operational disruption across connected systems.

1. Entry occurs when attackers or rogue automation reach exposed APIs, shadow APIs, or MCP-connected services that were never intended for broad use.
2. Escalation follows when those interfaces expose over-scoped credentials, weak request validation, or insufficient action-level controls that let the caller do more than intended.
3. Impact lands in the form of data exposure, unauthorised actions, or abuse of automated workflows that can cascade through connected systems.

NHI Mgmt Group analysis

API action-layer governance is now part of identity security, not separate from it. When AI agents, applications, and MCP-connected services share the same execution paths, the practical control point is no longer just authentication. It is runtime authorisation, delegated scope, and action-level policy. That makes API security a direct extension of IAM and PAM for machine-driven access, especially where NHI governance is already under strain.

Blind spots in API inventories create a false sense of control. Discovery tooling can show what exists, but it does not tell you who can call it, what data it can reach, or whether the action is still legitimate. That is the governance gap the article surfaces: unmanaged APIs and agent connections persist because ownership, lifecycle, and policy are not being enforced together.

AI agents behave like a new class of non-human identity, but with faster decision cycles. The security issue is not merely that they use credentials. It is that they can sequence actions, call tools, and reach data paths in ways conventional review processes were never designed to observe in time. The named concept here is action-layer drift: the widening gap between approved access and actual runtime behaviour. Practitioners should treat that drift as a governance signal, not an anomaly to ignore.

MCP security is becoming a control problem about scoped delegation. Once a model can use tools through MCP, the quality of the surrounding identity and access model matters more than the model itself. If tool permissions are broad or loosely monitored, the agent inherits a privilege footprint that is difficult to reason about after deployment. The implication for security teams is to move from model-centric oversight to delegated-action governance.

The market is converging on runtime visibility, but governance maturity will decide outcomes. The article points to an industry shift where security teams can no longer rely on static inventories, periodic reviews, or perimeter assumptions. The organisations that will manage AI and API risk best are the ones that can tie discovery, authorisation, and telemetry into a single control loop. For identity programmes, that means extending lifecycle discipline to API and agent permissions.

What this signals

Action-layer drift: the next governance problem is not whether AI agents exist, but whether their approved access still matches what they actually do. As agent workflows, API calls, and delegated tools multiply, security programmes need a tighter link between identity ownership, policy enforcement, and runtime telemetry. The governance model that wins will be the one that can prove where machine access starts and stops, not just where it was created.

For identity teams, the shift is operational as much as architectural. Service accounts, API keys, and agent permissions should be treated as living access pathways with owners, expiry expectations, and review triggers. That aligns well with the logic of zero standing privilege and continuous verification, and it is reinforced by the API action-layer view of risk described by Salt and by the broader NHI patterns in the 52 NHI Breaches Analysis.

For practitioners

• Map API action paths to business ownership Build an inventory that links each high-risk API and MCP connection to a named service owner, a business purpose, and a review cadence. Without ownership, discovery data cannot support revocation or policy decisions.
• Scope delegated permissions for AI agents Limit each AI agent and automation path to the smallest viable set of tool permissions, data scopes, and execution contexts. Revisit those scopes whenever the workflow changes or a new integration is added.
• Add runtime telemetry to API governance Monitor who or what is invoking critical APIs, from where, and with which actions. Correlate that telemetry with identity context so you can detect agent misuse, unexpected chaining, or access outside normal operating patterns.
• Treat shadow APIs as identity risk Classify unmanaged or undocumented APIs as access-control issues, not just technical debt. If an API cannot be tied to an owner and a policy, it should be treated as an ungoverned access path until proven otherwise.

Key takeaways

• AI agents and MCP-connected APIs are turning the API action layer into a primary security boundary for identity teams.
• Discovery without ownership, policy, and telemetry leaves organisations with visibility but not control.
• Runtime delegation, scoped access, and continuous review are now the controls that separate managed automation from exposed attack surface.

Key terms

• API action layer: The API action layer is the part of the application stack where requests become real business actions. It sits between identity, workflow, and data, so weaknesses here can let legitimate callers do more than they should, even when authentication itself appears to work correctly.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Action-layer drift: Action-layer drift is the gap between what an identity or automation path was approved to do and what it actually does at runtime. The drift grows when permissions, integrations, and workflows change faster than governance, leaving teams with access that is technically valid but operationally out of bounds.

What's in the full article

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

• Month-by-month product and research milestones across 2025, useful for tracking how the vendor positioned API and AI risk through the year.
• Specific product capabilities such as Salt Illuminate, Salt Surface, GitHub Connect, and MCP Finder, which are not unpacked here.
• Examples of how the vendor describes runtime protection for AI agent actions across APIs and MCP servers.
• The closing 2026 outlook that links visibility, context, and stopping attacks to the next phase of API security practice.

👉 Salt's full post covers the 2025 innovation timeline, product milestones, and 2026 outlook in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners translate identity controls into operating models that work across modern automation and AI-driven environments.