API attack surface is becoming the AI attack surface

At a glance

What this is: This is an analysis of how API security underpins AI risk governance, with the key finding that APIs are now the effective attack surface for LLMs, agents and MCP-connected systems.

Why it matters: It matters because IAM, security architecture and AI governance teams must treat API access, data flows and posture controls as part of the identity and trust model for AI systems, not as a separate technical layer.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.

👉 Read Salt's analysis of API posture governance for AI risk management

Context

API security has become a governance problem because AI systems depend on APIs to move data, trigger model inference, and coordinate agent actions. In practice, the control plane for AI is often the API layer, which means exposure, misconfiguration and weak visibility can undermine both security and trustworthiness from the start.

For IAM and AI governance teams, the key issue is not whether an AI model is hosted in a secure environment, but whether the surrounding access paths, tokens and delegated actions are controlled, monitored and limited. That makes API posture part of AI risk management, especially where autonomous agents and MCP servers introduce machine-to-tool trust relationships.

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 autonomous agents create more risk than traditional application accounts?

A: Autonomous agents create more risk because they can change scope while they are running. A traditional application account usually follows a stable pattern, but an agent can chain tools, expand into new systems, and act faster than a human can intervene. That makes runtime authorization, not just provisioning, the core control problem.

Q: What breaks when API posture governance is missing in AI environments?

A: Visibility breaks first, then enforcement. Teams may not know which APIs are connected to models, what data those endpoints can reach, or whether the permissions match the intended use case. That creates unmanaged shadow paths, makes incident response slower, and leaves AI governance dependent on assumptions instead of controls.

Q: Who is accountable when an AI platform exposes data and behavioural controls through backend flaws?

A: Accountability sits with the teams that own application security, IAM, and the AI control plane together. If unauthenticated APIs, weak object controls, or writable prompts exist, the failure is governance as much as engineering. Organisations should assign explicit ownership for endpoint inventory, runtime policy, and privileged configuration protection.

Technical breakdown

Why API posture becomes AI posture

AI systems rarely operate as self-contained assets. They consume training data, request inference, call tools, exchange messages, and sometimes delegate actions through MCP servers. That dependency means every exposed endpoint, token and authorization path becomes part of the AI control surface. API posture governance is the discipline of inventorying those interfaces, assessing whether they are protected, and enforcing policy continuously. In AI environments, the practical failure mode is not just data leakage. It is uncontrolled access to model inputs, outputs and agent actions through an interface that was never meant to carry that level of trust.

Practical implication: classify AI-connected APIs as sensitive trust boundaries and review them with the same rigor as privileged identity paths.

How NIST AI RMF maps to the API layer

The NIST AI RMF is organised around GOVERN, MAP, MEASURE and MANAGE. In this article's framing, the API layer is where those functions become operational. GOVERN defines policy and accountability, MAP identifies dependencies and visibility gaps, MEASURE tests for misconfigurations and exposure, and MANAGE turns findings into enforced controls. That mapping matters because AI risk is often discovered only after a model or agent has already been connected to live systems. Without posture management, the framework remains aspirational rather than enforceable.

Practical implication: map AI-connected APIs to AI RMF functions so governance decisions can be translated into control checks and remediation workflows.

Shadow APIs, agent tools and unintended trust paths

Shadow APIs are exposed interfaces that support AI workloads but are not fully governed, documented or monitored. In agentic environments, those paths may include hidden model endpoints, unsanctioned data feeds, and server connections that expand what an agent can reach. The risk is magnified when agents are able to select tools or act without direct human approval, because the interface itself becomes a delegation mechanism. Once that happens, the question is not only whether the API is authenticated, but whether the scope of delegated trust is still defensible.

Practical implication: detect and retire shadow APIs before they become implicit delegation paths for AI agents.

Threat narrative

Attacker objective: The attacker wants to use the AI system's own API dependencies to exfiltrate data, manipulate model behaviour, or drive unauthorized agent actions.

1. Entry occurs through exposed or shadow AI APIs that are not fully inventoried or governed, allowing an attacker or rogue workflow to interact with model-connected services.
2. Escalation follows when the interface grants access to sensitive training data, inference endpoints, or agent tool permissions beyond the intended scope.
3. Impact comes from model extraction, data poisoning, prompt injection, or unauthorized data exposure through the compromised API path.

NHI Mgmt Group analysis

API governance is now a first-order AI security control, not an implementation detail. When LLMs, agents and MCP servers depend on APIs for data and action, the interface becomes the real control boundary. That means organisations cannot treat API security as separate from AI governance. The practical conclusion is that AI risk programmes must include inventory, posture enforcement and runtime monitoring for every connected API.

Agentic AI expands the identity problem into the trust path between systems. Once an agent can call tools or act through delegated permissions, the security question shifts from model safety alone to the governance of machine-to-machine authorisation. This is where NHI thinking becomes relevant: service identities, tokens and API keys are now part of AI control design. Practitioners should evaluate whether their identity model can express least privilege for agent action, not just user access.

Shadow API sprawl creates AI governance debt. Unvetted interfaces accumulate faster than policy teams can catalogue them, especially where experimentation is encouraged and environments are constantly changing. That leaves organisations with invisible routes to sensitive data and unmeasured model exposure. The named concept here is API governance debt, and it is what happens when AI connectivity grows faster than the controls that are supposed to bound it.

NIST AI RMF only works when governance is technically enforced. The framework's value lies in turning risk principles into measurable controls, but APIs are where that translation succeeds or fails. If posture checks, visibility and remediation are weak, the organisation has policy without enforcement. The practitioner conclusion is clear: AI governance should be assessed by the strength of the API layer that carries it.

Security teams should expect AI risk to converge with identity and data governance. API access controls, secrets handling and data minimisation are becoming inseparable in AI operations. That convergence means AI programmes will increasingly require IAM, PAM, data security and application security to operate as one governance system. The practical implication is to build cross-functional ownership now rather than retrofit accountability after an incident.

What this signals

API governance debt will show up first as identity debt. As AI systems multiply, the weakest point is often not the model but the delegated access used to reach it. Teams should expect secrets sprawl, unclear ownership and inconsistent scoping to become the practical indicators that AI governance is slipping, especially where agent actions are tied to service identities.

The operational signal to watch is whether AI-related access can be discovered, scoped and audited end to end. Where that is not possible, the programme is already carrying risk in the same way unmanaged NHI populations do. For practitioners, the next step is to align AI access paths with control frameworks such as the NIST AI Risk Management Framework and NIST Cybersecurity Framework 2.0.

The more AI workflows depend on APIs, the more security teams will need cross-domain ownership across IAM, secrets management and application security. That is where the distinction between a functional integration and a governed trust relationship becomes decisive. For identity programmes, the real change is that AI connectivity now belongs inside access governance, not outside it.

For practitioners

• Inventory every AI-connected API Create and maintain a complete list of APIs used for training, inference, model orchestration and agent-tool communication. Include shadow APIs and internal endpoints that support experimentation, because those paths often become the least governed. Treat missing inventory as an exposure issue, not a documentation issue.
• Enforce posture checks on delegated access paths Apply policy checks to authentication, authorization, token scope and data access for every AI-facing interface. Where agents or services can act independently, verify that permissions are task-scoped and that secrets are not over-privileged. Use the NIST AI Risk Management Framework as the governance map, then prove it with technical controls.
• Monitor for shadow APIs and anomalous agent behaviour Use discovery and runtime telemetry to detect unapproved API endpoints, unusual data requests and tool-use patterns that indicate policy drift. Feed those signals into security operations so AI-related issues are triaged alongside other high-risk access events.
• Test AI-connected APIs for misconfiguration and exposure Assess logic flaws, excessive data access, weak rate limits and broken authorization around model and agent interfaces before they are exposed to production workloads. Prioritise issues that would let a compromised token reach more data or actions than intended.

Key takeaways

• AI systems inherit their risk posture from the APIs they depend on, which makes the interface the real security boundary.
• When agentic systems gain broad or invisible API access, governance failures turn into data exposure, tool misuse and audit blind spots.
• Practitioners should treat AI API posture as an identity and access problem, with inventory, scoping and runtime monitoring as core controls.

Key terms

• API-first governance: API-first governance is the practice of enforcing access and control decisions at the programmatic interface rather than relying on what a user can see or click. In a SOC, that means permissions, approval gates, and logs must be attached to the action path the agent actually uses.
• 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.
• NIST AI Risk Management Framework: A voluntary framework for organizing AI risk governance around clear outcomes rather than fixed compliance steps. It helps enterprises define accountability, map AI context, measure risk, and manage treatment, but it does not itself provide enforcement or certification.
• 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.

What's in the full article

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

• A deeper breakdown of API posture governance across discovery, policy enforcement and runtime protection for AI-connected services.
• Specific examples of how insecure APIs enable model extraction, prompt injection and sensitive data exposure in production environments.
• The article's mapping of API security capabilities to NIST AI RMF functions, including how each control supports GOVERN, MAP, MEASURE and MANAGE.
• Salt's recommended approach to securing the AI action layer across models, agents and MCP-connected servers.

👉 Salt's full post covers the AI action layer, posture governance and threat-detection details behind this analysis.

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 is designed for practitioners building disciplined access control across identity-heavy programmes.