API attack surface is becoming the AI attack surface

At a glance

What this is: Salt’s analysis says AI risk management now hinges on the API layer because AI systems use APIs for data ingestion, inference and agent-to-server communication.

Why it matters: For IAM, NHI and AI governance teams, this shifts attention to API inventory, policy enforcement and runtime controls that govern how agents, models and services exchange data and actions.

Context

AI systems do not become safer because the model is better governed in isolation. Once training data, inference calls, tool use and agent-to-server exchanges move through APIs, the governance problem shifts to the interfaces that connect those components.

That matters for AI, IAM and NHI programmes because the same control plane now carries model prompts, agent actions, service credentials and sensitive data. In practice, API posture becomes the enforcement layer for AI risk management, not a separate technical concern.

Key questions

Q: How should security teams govern AI infrastructure that depends on APIs and microservices?

A: They should treat the combined stack as one identity system and map every machine-to-machine handoff, token, and delegated permission to an accountable owner. The key control is not the API gateway alone. It is the ability to trace, limit, and revoke access across the entire runtime path without relying on manual exception handling.

Q: Why do APIs create more risk when AI and automation depend on them?

A: Because APIs become the enforcement layer for machine and AI access, so weak authorization can widen blast radius quickly. When service accounts, tokens, and delegated permissions are too broad, normal traffic patterns can hide abuse. Teams need identity scope, context, and session purpose to stay tightly bound to the function being called.

Q: What signs show that AI API controls are not keeping up?

A: Common warning signs include incomplete API inventories, inconsistent authentication across AI services, unclear ownership of machine credentials, and data paths that cannot be traced from input to inference to output. If those signals exist, governance is lagging the actual attack surface.

Q: Should AI teams prioritise API posture governance before broader model controls?

A: Yes, when the model’s real risk comes from exposed interfaces, not from the weights themselves. If the system relies on APIs for data access, tool calls and orchestration, fixing the interface layer first usually delivers the fastest reduction in exploitability and privacy exposure.

Technical breakdown

Why APIs become the AI control plane

Large language models and autonomous agents rarely act alone. They depend on APIs to fetch context, call tools, submit prompts, retrieve outputs and move between services. That makes the API layer the operational control plane for AI behaviour, because the system’s effective trust boundary sits where those calls are authenticated, authorised and monitored. If discovery is incomplete, shadow APIs and unmanaged endpoints remain outside policy. If authorisation is weak, agent actions can exceed intended scope. For NHI teams, these API interactions often ride on service identities and tokens rather than human sessions, which means governance has to cover machine credentials as first-class access paths.

Practical implication: Inventory AI-facing APIs continuously and bind them to explicit authentication, authorisation and ownership controls.

How API posture governance maps to NIST AI RMF

The NIST AI RMF frames risk through GOVERN, MAP, MEASURE and MANAGE. API posture governance makes those functions enforceable in production by translating policy into discovery, configuration control, monitoring and remediation. MAP depends on knowing which APIs support training, inference and agent workflows. MEASURE depends on testing those APIs for misconfiguration, logic flaws and sensitive-data exposure. MANAGE depends on being able to block or remediate unsafe API behaviour as AI systems change. The point is not that APIs replace AI governance, but that without API-level control the framework remains declarative rather than operational.

Practical implication: Tie AI governance reviews to API inventory, misconfiguration testing and runtime enforcement evidence.

Shadow APIs and exposed data create the real risk

The article’s core warning is that unvetted AI models can be deployed through shadow APIs and sensitive training data can leak through misconfigured interfaces. That is a visibility problem first and a confidentiality problem second. In AI environments, hidden API paths often emerge faster than review cycles, especially when teams add orchestration, retrieval and agent tools incrementally. Once those paths exist, they can bypass intended data handling rules and make privacy controls hard to prove. For organisations running agentic workflows, the control gap is not abstract model risk. It is unmanaged interface exposure.

Practical implication: Treat shadow API discovery and sensitive-data tracing as ongoing controls, not one-time assessments.

Threat narrative

Attacker objective: The attacker seeks to reach AI data and actions through the interface layer, rather than attacking the model directly.

1. Entry begins when AI workflows are exposed through unmanaged or shadow APIs that were not included in policy review.
2. Escalation follows when misconfigured interfaces allow access to training data, inference paths or agent tool actions beyond intended scope.
3. Impact occurs when attackers use those API pathways to extract data, manipulate model behaviour or trigger unsafe downstream actions.

Breaches seen in the wild

• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.
• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.

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 posture is now identity governance for AI systems: the control point that matters is no longer just the model or the agent, but the authenticated API path they use to act. That is where service credentials, delegated permissions and sensitive data flow meet in production. For identity programmes, this means AI governance must include machine identity ownership, token scope and lifecycle control.

Shadow API discovery is the new visibility baseline: organisations cannot govern AI risk if they cannot enumerate the APIs their models, agents and retrieval layers actually touch. Hidden interfaces create blind spots that MAP and MEASURE functions cannot close after the fact. The practical conclusion is that AI discovery has to extend to every interface that can move data or trigger action.

Agentic AI exposes a governance trust gap, not just a technical one: teams often assume the model boundary is the risk boundary, but the article shows the interface boundary is where policy is enforced or defeated. This changes how NHI, PAM and AI security teams should assign accountability for shared credentials, tool permissions and runtime access.

API attack surface is the named concept that explains the whole pattern: when AI behaviour depends on APIs for data, tools and orchestration, the interface layer becomes the real attack surface. That framing is useful because it forces security teams to govern the connectors, not only the model artefacts. Practitioners should treat API security as a core AI governance discipline.

Secure and resilient AI depends on enforceable interface controls: the article’s NIST AI RMF alignment only works when controls can block risky API behaviour at runtime, not simply document it. That means policy, visibility and enforcement need to operate as one system. For security leaders, the implication is clear: AI governance succeeds only when interface control is measurable and repeatable.

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.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Read next: MCP Security Guide

What this signals

API posture governance is becoming the practical control plane for AI risk: organisations that cannot enumerate and enforce policy across AI-facing APIs will struggle to prove they are managing model, agent and data exposure coherently. The governance question is no longer whether AI uses APIs, but whether those interfaces are owned, measured and constrained.

Shadow API discovery should be treated as part of AI governance debt: every unmanaged endpoint expands the gap between declared policy and actual behaviour. That gap matters because AI systems can appear compliant at the model layer while still leaking data or enabling unauthorised action through exposed connectors.

For practitioners

• Implement continuous API discovery for AI systems Map every API used for training, inference, retrieval and agent actions, including shadow APIs that may sit outside normal inventory processes.
• Bind AI governance to runtime API posture control Require configuration checks, auth validation and policy enforcement for all AI-connected APIs before they can move data or execute actions.
• Track service credentials behind agent and model traffic Identify the machine identities, tokens and service accounts that AI workflows use so ownership and revocation are explicit.
• Test AI-facing interfaces for sensitive-data exposure Assess whether prompts, training data and inference outputs can be observed, exfiltrated or mishandled through exposed API paths.

Key takeaways

• AI risk now concentrates in the API layer because models, agents and retrieval workflows depend on interfaces to move data and actions.
• Visibility, posture governance and runtime enforcement are the difference between documented AI policy and operational AI control.
• For identity and security teams, the hard problem is not model ownership alone but the machine identities and API paths that let AI systems act.

Key terms

• API posture governance: API posture governance is the ongoing discipline of defining, measuring, and enforcing how APIs are exposed, secured, and used across an organization. It covers authentication, authorization, inventory, schema control, rate limits, logging, versioning, and risk review, so APIs remain discoverable, least-privileged, and aligned with security and compliance requirements.
• 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.
• AI Risk Management: AI Risk Management is the discipline of identifying, assessing, treating, and monitoring risks created by artificial intelligence systems. It covers model behavior, data quality, misuse, security, privacy, compliance, and operational impact, with controls applied across the AI lifecycle from design and training through deployment, monitoring, and retirement.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity and machine identity security. It is designed for practitioners who need to connect identity controls to emerging AI operating models.