API security is now the control plane for agentic AI

At a glance

What this is: This report argues that APIs have become the AI action plane, and its key finding is that authenticated abuse, weak monitoring, and governance gaps are already slowing releases and driving incidents.

Why it matters: It matters to IAM practitioners because API governance now intersects directly with NHI, agentic AI, and human access patterns, making authorization and visibility central to identity risk management.

By the numbers:

• 96% of attack attempts originate from authenticated entities, such as compromised users, insiders, or rogue AI agents.
• 80% of organizations still lack continuous, real-time API monitoring.
• 50% of all organizations have slowed or halted a new application release due to API risk.
• 19% of organizations are very confident in the accuracy of their API inventories.

👉 Read Salt’s H2 2025 State of API Security report on agentic AI and API risk

Context

API security has become an identity and governance problem as much as a technology problem. When AI workflows, agents, and tool calls all depend on APIs, the security model shifts from perimeter defence to control over who and what can call which interface, under what conditions, and with what effective privileges.

The article’s core claim is that this shift is happening faster than current controls can absorb. For IAM and PAM teams, the intersection is obvious: API authorization now governs human users, service accounts, and AI agents alike, which means identity inventory, privilege scope, and runtime oversight are now part of the same control surface.

Key questions

Q: What breaks when API security is treated as a perimeter problem instead of an identity problem?

A: Controls miss the real attack path, which now often begins with valid credentials and moves through excessive authorization. Once a user, service account, or AI agent is authenticated, the risk shifts to what that identity can do next. If teams do not govern post-login actions, attackers can exploit normal traffic patterns to reach data and functions at scale.

Q: Why do AI agents create a governance problem for IAM teams?

A: AI agents create a governance problem because they authenticate and act as autonomous software entities with tool access. If their actions are logged only as application activity, teams lose accountability, context, and revocation clarity. IAM must therefore extend to agent identity, delegated authority, and control-plane audit trails.

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: Which frameworks help teams govern AI systems that use internal tools?

A: NIST AI Risk Management Framework, OWASP Agentic AI Top 10, and MITRE ATLAS are the most relevant starting points when AI systems can reason, call tools, and touch data. Identity teams should pair them with NHI governance so credentials, permissions, and runtime reach are reviewed together instead of in separate silos.

Technical breakdown

Why authenticated API abuse is now the dominant failure mode

Modern API attacks often begin after authentication, not before it. Once an attacker, compromised user, or rogue AI agent has a valid identity, the control question becomes authorization, object-level access, and runtime behaviour. Broken object level authorization, excessive trust in session context, and weak segmentation let authenticated callers reach data or functions they should never see. In an AI-driven environment, this matters because automation can amplify a single misused token into repeated, system-wide abuse.

Practical implication: move detections and policy checks from login events to post-authentication actions and object access patterns.

How API inventories become a governance failure in AI programmes

An API inventory is only useful if it is accurate, current, and linked to ownership. AI development increases API creation speed, introduces shadow interfaces, and spreads access across tools, agents, and internal services. Without real-time discovery, teams cannot confidently answer which APIs exist, who owns them, or which identities can reach them. This is a governance failure because undocumented APIs become unreviewed trust paths, especially when agents can call tools automatically.

Practical implication: treat inventory freshness as a security control, not a documentation task.

What runtime protection must do when AI agents call APIs

Runtime protection needs to inspect behaviour, not just credentials. For API security, that means watching for abnormal call volume, unusual object access, sequence deviations, and policy violations that emerge after authentication. For agentic AI, the challenge is sharper because an agent can chain requests, choose tools dynamically, and repeat actions at machine speed. Static code review and perimeter controls are too slow for that pattern, so the defence has to verify the action itself as it happens.

Practical implication: pair authorisation policy with behavioural detection and enforcement at the API layer.

Threat narrative

Attacker objective: The attacker aims to use valid identity and API trust to access sensitive systems and data at scale while staying inside normal-looking traffic.

1. Entry occurs through authenticated access, typically via a compromised user, insider, service account, or rogue AI agent that already holds valid credentials.
2. Escalation follows when the authenticated caller exploits misconfiguration or broken object-level authorization to reach data and functions beyond its intended scope.
3. Impact comes from repeated automated calls that expose sensitive data, disrupt releases, or let attackers persist inside business workflows without needing perimeter bypass.

NHI Mgmt Group analysis

API security has become an identity governance problem, not just an application security problem. The article shows that authenticated entities now drive most abuse, which means the decisive control is no longer perimeter blocking but authorization quality. For IAM and PAM teams, that creates a direct bridge to service accounts, machine identities, and agent permissions. The practitioner conclusion is that API governance now sits inside the identity programme.

Real-time API inventory is the new trust baseline for AI programmes. If organisations cannot continuously discover APIs, they cannot govern the identities that call them or the privileges those calls expose. That is a classic control-plane failure, because unknown interfaces cannot be reviewed, scoped, or monitored. The named concept here is API visibility debt: the longer inventory lags behind AI development, the more ungoverned access paths accumulate. The practitioner conclusion is to treat discovery freshness as a measurable control objective.

Authentication is no longer the security boundary once AI agents begin chaining API calls. The article’s emphasis on authenticated attacks shows why post-login behaviour is where policy breaks down. A valid identity can still abuse broken object-level authorization, over-broad scopes, or missing runtime checks. This is especially relevant where AI agents and MCP-driven tool use expand machine-to-machine trust. The practitioner conclusion is to move governance from access grant to action control.

AI adoption is exposing a governance gap between development speed and control maturity. The report links GenAI-driven API growth with low confidence in inventories and weak monitoring, which is exactly how shadow interfaces become risk multipliers. NIST CSF, OWASP NHI, and the OWASP Agentic AI Top 10 all point toward the same issue: control coverage must scale with automation. The practitioner conclusion is that AI strategy now depends on identity-aware API governance, not after-the-fact review.

What this signals

The operational signal for practitioners is that API governance must now be measured in identity terms. If discovery does not keep up with release velocity, the programme will accumulate unreviewed access paths faster than IAM or AppSec teams can validate them. The practical next step is to link API inventory, ownership, and runtime monitoring into one control loop.

API visibility debt: when AI development outpaces discovery, the enterprise builds trust paths it cannot explain or review. That debt shows up later as incident response blind spots, failed attestations, and brittle authorisation exceptions. Identity teams should treat every undocumented API as a potential ungoverned NHI or agent access path.

This is where agentic AI changes the workload for IAM and PAM teams: machine callers become frequent, distributed, and policy-sensitive at the same time. The right response is not more manual review. It is better inventory, stronger action-level authorisation, and control coverage that can survive machine-speed API use.

For practitioners

• Build a real-time API inventory tied to identity ownership Map every API to a business owner, calling identity, and data sensitivity level. Refresh discovery continuously so new endpoints, agent tool calls, and undocumented interfaces do not sit outside governance review. Use the inventory as the source of truth for access review and monitoring.
• Shift controls to post-authentication authorization checks Prioritise object-level and action-level authorization because most abuse is coming from authenticated entities. Enforce least privilege on service accounts, user sessions, and AI agent tokens, and verify the specific resource or function requested before allowing the call.
• Instrument runtime detection for abnormal API behaviour Watch for unusual call frequency, sequence drift, bulk reads, and access to objects outside the normal pattern. Feed those signals into incident response so automated abuse can be contained before it spreads across dependent workflows.
• Govern agent and MCP access as part of identity lifecycle Treat AI agents and their tool permissions like other non-human identities: assign ownership, review scopes, and remove stale access when workflows change. Where MCP is used, document which tools each agent can invoke and under what policy conditions.

Key takeaways

• API security is now inseparable from identity governance because authenticated entities are the dominant attack path.
• Inventory drift and weak runtime monitoring create the conditions for shadow APIs, uncontrolled agent access, and release delays.
• Practitioners should move from login-centric controls to action-level authorization, behavioural detection, and identity-owned API inventories.

Key terms

• AI Visibility Debt: AI visibility debt is the growing gap between how quickly employees adopt AI and how slowly the organisation discovers and governs that use. It builds when sanctioned tools lag behind user demand, leaving security teams with incomplete inventories, weak policy enforcement, and limited evidence for access reviews.
• Authenticated Abuse: The misuse of legitimate credentials or sessions to perform actions that are technically allowed but operationally unsafe. In API environments, this often means an attacker uses valid keys, tokens, or accounts to access data or trigger functions in ways that bypass perimeter thinking.
• Sequence-Level Authorisation: Sequence-level authorisation is control over the full chain of actions an autonomous agent can take, not just the permissions on each individual request. It matters because an agent can combine several valid calls into an outcome that no single policy check would flag.
• Agentic API Access: API access granted to an AI agent that can decide which requests to make and when to make them. The security challenge is not only who authenticated, but whether the delegated authority remains constrained while the agent chains actions across tools and services.

What's in the full report

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

• Per-domain breakdowns of API risk patterns across AI development and production environments
• Specific monitoring and governance benchmarks that help teams compare current inventory and response maturity
• Practical guidance on securing authenticated API traffic, including runtime detection and authorisation controls
• The report's readiness checklist for discovery, governance, and threat protection across agentic systems

👉 Salt’s full report covers the attack patterns, monitoring gaps, and governance steps in more operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of modern identity programmes. It helps security practitioners align identity control design with the operational realities of automation and agentic systems.