API security is now the control plane for agentic AI

At a glance

What this is: Salt frames APIs as the control plane for agentic AI and says the operational risk is rising faster than current governance, monitoring, and authorisation controls.

Why it matters: This matters because AI agents, machine workflows, and human users increasingly converge on the same API layer, making inventory accuracy, authorization, and runtime visibility core identity-security issues.

By the numbers:

• 96% of attack attempts originate from authenticated entities, according to Salt.
• 80% of organisations still lack continuous API monitoring, according to Salt.
• 19% of organisations say they are very confident in the accuracy of their API inventories, according to Salt.

Context

APIs have become the operational boundary for AI-driven systems, which means API governance now carries identity, authorization, and workload-risk consequences at the same time. When agents, MCP-style tool calls, and human applications all rely on the same API surface, weak inventory data or misapplied trust assumptions quickly turn into access-control failures rather than just technical defects.

Salt’s analysis argues that the problem is not simply more API traffic. It is that AI adoption expands the number of calls, identities, and privileges faster than teams can monitor or govern them, so the control plane itself becomes the security plane. For IAM, PAM, and NHI programmes, that makes authorization and visibility first-class controls, not back-end operational details.

Key questions

Q: How should security teams govern API access for AI agents and service accounts?

A: Security teams should treat API access as a governed identity path, not a transport detail. That means assigning ownership to each machine consumer, limiting scopes to specific tasks, enforcing token binding where possible, and maintaining audit logs that tie every call to an identity and policy decision.

Q: Why do authenticated API calls create so much risk in agentic AI environments?

A: Because authentication only proves identity, not intent or scope. Once an agent, service account, or compromised user is inside the trust boundary, broken object-level authorization and misconfiguration can turn valid access into repeated unauthorized actions. In agentic environments, that abuse scales faster than manual detection and review.

Q: What breaks when API inventories are incomplete?

A: When inventories are incomplete, teams cannot reliably know which APIs exist, what data they expose, or which identities and tokens can reach them. That breaks risk assessment, ownership, logging coverage, and incident scoping. The result is usually delayed remediation, hidden exposure, and inconsistent control enforcement across production services.

Q: When should organisations prioritise runtime monitoring over periodic API reviews?

A: Prioritise runtime monitoring when APIs support high-frequency automation, agentic workflows, or business-critical data flows. Periodic reviews cannot keep up with call volume, privilege drift, or changing dependencies. Continuous observation is the only way to see misuse after authentication and before it becomes release disruption or data exposure.

Technical breakdown

Why authenticated API traffic is now the main attack path

Traditional perimeter thinking assumes hostile traffic arrives from outside the trust boundary. Salt’s data shows the opposite pattern, with most attack attempts coming from authenticated entities such as compromised users, insiders, or rogue automated actors. In API-heavy environments, authentication only proves a caller is known; it does not prove the caller should reach a particular object, function, or workflow. That is why broken object-level authorization and misconfiguration dominate real-world abuse. For agentic systems, the issue becomes sharper because a legitimate identity can invoke large numbers of API actions at machine speed.

Practical implication: shift detection and control investment from login success to authorization checks, runtime policy enforcement, and anomalous API behaviour.

How inventory gaps become governance gaps

An API inventory is not a catalogue exercise. It is the authoritative map of what can be called, by whom, through which credentials, and for what purpose. Salt’s figures show that only a small minority of organisations are highly confident in inventory accuracy, which means many teams are governing partial or stale information. In an agentic AI environment, undocumented APIs, shadow integrations, and brittle service-to-service dependencies create hidden access paths that no review process can reliably see. Continuous discovery matters because the asset being governed changes as quickly as the application architecture.

Practical implication: treat API discovery as an identity control surface and reconcile it continuously against NHI, service, and application ownership.

Why agentic AI amplifies api8 and api1 weaknesses

Agentic AI does not invent new classes of API risk so much as it accelerates old ones. Security misconfiguration and broken object-level authorization become more dangerous when an agent can chain requests, repeat actions, or explore a workflow faster than a human can. That means a single weak rule can scale into systemic misuse across many transactions. This is the practical meaning of calling APIs the AI action plane: the API layer is where intent becomes action, and any ambiguity in scope, privilege, or object ownership becomes exploitable at machine pace.

Practical implication: review API scopes, object ownership, and function-level permissions as if every high-frequency caller were a potential automated adversary.

Threat narrative

Attacker objective: The attacker aims to turn legitimate API access into unauthorized actions, data access, or workflow abuse inside AI-driven systems.

1. Entry occurs through authenticated access rather than anonymous probing, with compromised users, insiders, or rogue AI agents using valid credentials to reach exposed APIs.
2. Credentialed callers exploit security misconfiguration or broken object-level authorization to invoke unintended objects, methods, or workflows at scale.
3. Automation turns each weakness into repeated abuse, increasing the chance of release disruption, data exposure, or downstream business impact.

Breaches seen in the wild

• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.
• McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.

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 security has become identity governance by another name. When AI agents, service accounts, and human users all operate through APIs, the governance question is no longer only who logged in. It is what each authenticated identity can do, at what object scope, and under which runtime conditions. For IAM and NHI teams, API authorization is now a primary control boundary, not a secondary application detail.

Authenticated abuse is the dominant risk signal, not perimeter breach. Salt’s finding that 96% of attack attempts originate from authenticated entities reflects a deeper shift in attacker economics. Once identity is trusted, security failures move into object access, workflow abuse, and privilege misuse. Practitioners should read this as a signal that access policy quality matters more than the source IP of the request.

Inventory accuracy is the hidden control that determines whether governance exists at all. If teams cannot reliably enumerate APIs, associated service identities, and dependent workflows, then authorization reviews become partial theatre. This is the point where NHI governance, cloud security, and application security intersect. The practical conclusion is simple: unmanaged APIs create unmanaged identities, and unmanaged identities create unmanaged access.

AI agent control requires runtime guardrails, not policy optimism. Agentic systems can generate high-volume, adaptive API behaviour that outpaces periodic review cycles. That means governance must move to continuous monitoring, scoped credentials, and enforced object-level authorization. Teams that treat agentic AI as just another application integration will miss the scale and speed of the risk.

API governance is now part of the AI management system. The article’s references to the EU AI Act and ISO/IEC 42001 are directionally correct because API behaviour is where many AI risks become operational. Organisations need to treat API inventories, authorization rules, and monitoring evidence as governance artefacts, not only engineering outputs. The practitioner takeaway is that AI governance fails if API governance is weak.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to the 2026 Infrastructure Identity Survey.
• Read next: Shadow AI and AI Agent Discovery Guide

What this signals

Authenticated API traffic now needs to be treated as a governance signal, not a trust signal. In environments where agents, services, and humans all share the same access paths, the meaningful question is whether each caller is still constrained by purpose, object scope, and runtime policy. That is where API governance and NHI governance converge for most practitioners.

API inventory drift is becoming a practical identity problem. When undocumented endpoints and unmanaged service identities accumulate together, teams lose the ability to prove who can invoke what. For organisations adopting AI workflows quickly, the first control failure is often discovery, not detection.

Control-plane security now sits inside the AI management conversation. If security teams cannot monitor authenticated behaviour continuously, the AI programme inherits hidden risk from the API layer. The right response is to govern AI access where it is actually exercised: at the API, not only in the model or the perimeter.

For practitioners

• Establish a real-time API inventory Map every exposed, internal, and agent-facing API to an owner, caller type, credential type, and business function. Reconcile the inventory continuously against CI/CD, cloud, and NHI records so shadow and undocumented APIs do not become hidden access paths.
• Enforce object-level authorization checks Review every high-risk endpoint for broken object-level authorization and function-level overreach, especially where service accounts or agents can enumerate resources. Make authorization the primary control, not a post-login assumption.
• Monitor authenticated API behaviour in runtime Build detections for unusual request volume, sequence changes, privilege drift, and machine-speed repetition from otherwise valid identities. Focus on authenticated caller patterns because the source data shows that is where the abuse starts.
• Tie agent onboarding to API governance Require every new AI agent or MCP-style integration to have a named owner, a scoped API contract, and an explicit review of the data and actions it can invoke. Do not allow autonomous access to expand faster than governance.

Key takeaways

• API security is no longer a narrow application concern because agentic AI, service identities, and human users now meet at the same control plane.
• Salt’s data points to a governance gap marked by authenticated abuse, incomplete visibility, and delayed release decisions when API risk rises.
• The practical response is continuous API discovery, stronger object-level authorization, and runtime monitoring that can see machine-speed misuse.

Key terms

• API Control Plane: The API control plane is the management layer that defines how APIs are discovered, governed, secured, and observed. In modern environments it often spans gateways, policies, identity controls, and telemetry, giving teams a central place to enforce access rules and operational standards across hybrid and multi-cloud systems.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• API Inventory Drift: API inventory drift is the gap between the APIs an organization believes it has and the APIs that actually exist, are exposed, or are in use. It occurs when services change, shadow APIs appear, or documentation falls behind. This weakens governance, expands attack surface, and complicates access control, monitoring, and incident response.

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 connect access control and lifecycle management to broader identity security programmes.