API action layer security is becoming the new AI attack surface

At a glance

What this is: This is an independent analysis of Salt's view that API action-layer security has become the practical attack surface for AI agents, MCP servers, and modern application workflows.

Why it matters: It matters because IAM, NHI, and application security teams now have to govern who or what can act through APIs, not just who can authenticate to them.

Context

APIs are now the control point where applications, automation, and AI systems actually do work. When that layer is poorly inventoried or loosely governed, security teams lose visibility into actions, data access, and downstream privilege use, which is why traditional perimeter and app controls stop being enough.

The identity angle is real even in a broader API security story. AI agents and MCP-connected services behave like non-human identities when they request, chain, or execute actions through APIs, so governance has to extend to authorization scope, context, and action boundaries rather than stopping at login events.

Salt's year-end review frames 2025 as the point where visibility into APIs, agent integrations, and shadow workflows became a prerequisite for control. That starting position is increasingly typical across organisations adopting automation and agentic AI faster than they mature their action-layer governance.

Key questions

Q: What breaks when AI agents can reach exposed internal APIs?

A: The break point is governance, not just security tooling. Once an agent can call exposed internal APIs, it can chain permissions, query sensitive data, and trigger workflows at machine speed. That turns a single weak endpoint into a broad access path. Teams need to assume discoverability and chaining, then constrain each callable service with authentication, scoping, and runtime policy.

Q: Why do unmanaged APIs create a bigger risk in large platform environments?

A: Because scale turns small visibility gaps into structural blind spots. When teams cannot reliably identify what services exist, who owns them, or which controls apply, security reviews, compliance checks, and incident response all lose precision. That is how routine sprawl becomes a material governance failure.

Q: How can security teams tell whether API risk controls are actually working?

A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why. If the control is effective, suspicious traffic should be slowed, challenged, or blocked before it reaches core systems, while legitimate integrations continue to function normally.

Q: What is the difference between API authentication and API authorization?

A: API authentication verifies who or what is making the request. API authorization decides what that identity is allowed to access or do. Strong authentication does not prevent misuse if authorization is broken, and strong authorization cannot compensate for stolen or poorly validated credentials. Both controls must work together at object, property, and function level.

Technical breakdown

Why the API action layer is now the security boundary

The API action layer is the place where an authenticated caller becomes an operational actor by creating, changing, or retrieving data through application functions. In AI-heavy environments, that boundary matters more than the model itself because the real risk is not language generation, it is delegated action. If the action path is unknown, excessive, or poorly segmented, security teams cannot reason about blast radius, misuse, or trust boundaries. That is why inventory, authorisation, and runtime observation now need to converge around API calls rather than sit in separate toolchains.

Practical implication: Practitioners should treat API actions as governed business operations and map them to explicit authorisation scope.

How MCP and AI agents expand the attack surface

MCP servers and AI agents increase surface area because they connect decision-making systems to multiple tools and data sources through structured actions. Each integration creates another place where trust can be overextended, especially when the agent can choose timing, tool order, or target system with limited human oversight. The security problem is not merely access, but delegated context. Once an agent can combine prompts, credentials, and API functions, the environment needs controls for tool use, action approval, and abuse detection at runtime.

Practical implication: Practitioners should govern agent tool access as a separate control plane, not as a side effect of application authentication.

Shadow and unmanaged APIs create hidden action paths

Shadow APIs, zombie APIs, and unmanaged endpoints widen exposure because they preserve working functionality without being fully owned, monitored, or retired. In practice, that means attackers may find live business flows that no one is actively reviewing for schema drift, broken authorisation, or exposed data. The same pattern appears in NHI governance when service accounts or tokens continue to call APIs long after the team that created them has moved on. Visibility is therefore not just an inventory problem, it is an access lifecycle problem.

Practical implication: Practitioners should align API discovery with owner assignment, entitlement review, and retirement processes.

Threat narrative

Attacker objective: The objective is to abuse trusted API action paths to reach data, functions, or automated workflows that should not have been accessible in the first place.

1. Entry begins when attackers or risky integrations reach exposed APIs, MCP-connected workflows, or unmanaged endpoints that were never brought under full governance.
2. Credential or trust misuse follows when an agent, token, or service account can execute actions beyond the intent of the original workflow owner.
3. Escalation happens through over-permissioned API functions, chained tools, or hidden dependencies that let the actor expand from one action path to many.
4. Impact is loss of visibility and control over business flows, with data exposure, unsafe automation, or operational disruption downstream.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API action-layer governance is the missing control plane for agentic systems. The article correctly shifts attention away from model outputs and toward the actions that AI systems can trigger through APIs. That is where business risk becomes operational risk, because the system is no longer merely generating text, it is creating effects in production. For identity teams, the key question is whether each action path has explicit authorisation and ownership.

Shadow APIs are an identity lifecycle problem as much as an application problem. Unmanaged endpoints behave like orphaned credentials because they remain usable after the team that created them has lost sight of them. In a world of AI-assisted automation, that creates a durable trust gap between deployment speed and governance reach. The practical conclusion is that API discovery must be tied to lifecycle ownership, not just scanning.

AI agents should be treated as constrained non-human identities when they act through APIs. When an agent can select tools, sequence calls, and operate across contexts, its effective privilege model matters as much as its prompt safety. That makes authorisation scope, session constraints, and runtime monitoring the decisive controls. Organisations that do not model agents this way will keep misclassifying action risk as simple integration risk.

Action-layer visibility creates a new named governance concept: API action fabric. This is the combined inventory, authorisation, and monitoring layer that shows who or what can do what across APIs, MCP servers, and agent workflows. Without it, teams can see traffic but not intent, and they can see authentication but not consequence. Practitioners should build governance around the fabric of actions, not around isolated interfaces.

The market is moving toward policy enforcement at the point of execution. The article's trajectory is consistent with a broader shift in cybersecurity: static review is not enough when actions are assembled dynamically at runtime. That matters for IAM, PAM, and NHI governance because the decisive control is increasingly issuance-time and action-time, not after-the-fact audit. Teams should expect more convergence between API security, runtime authorisation, and identity governance.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

API action fabric: organisations need a single view of which identities, agents, and services can perform which actions across APIs and MCP-connected workflows. Without that fabric, teams keep finding traffic without understanding consequence, which means governance follows incidents instead of preventing them.

The practical shift for 2026 is from perimeter visibility to execution-time authorisation. That is where non-human identity controls, agent tool permissions, and API security now converge, and the teams that align those controls will have a much clearer picture of actual blast radius.

Salt's framing also reinforces a broader market signal: API security is no longer a niche control set, it is the operational layer where identity, automation, and application risk meet.

For practitioners

• Map exposed API actions to business owners Create an owner-to-action inventory that ties each high-risk API and MCP workflow to a named system owner, approval path, and review cadence.
• Classify AI agents as governed non-human identities Assign each agent a scoped identity, explicit tool permissions, and an approval boundary for sensitive API actions rather than letting it inherit broad application trust.
• Discover and retire shadow API paths Continuously find unmanaged, zombie, and orphaned endpoints, then decommission or re-own anything that still accepts production traffic without current governance.
• Separate action approval from authentication Require policy checks on the action itself, including method, target object, and data sensitivity, so a valid login cannot automatically authorize every downstream call.
• Instrument runtime monitoring for agentic workflows Track tool selection, API sequence, and anomalous action bursts so misuse shows up at execution time rather than only in post-incident logs.

Key takeaways

• API security is becoming an identity and governance problem because the highest-risk events now happen at the point of action, not at login.
• AI agents and MCP-connected workflows expand risk by chaining legitimate API calls into outcomes that traditional perimeter controls do not fully govern.
• The decisive control shift is toward action-level authorisation, ownership, and runtime monitoring across the full API fabric.

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.
• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to real operational risk across modern automation and API-driven environments.