API ecosystems and agentic AI: what changes for governance

At a glance

What this is: This is Kong's analysis of how agentic AI is changing the role of APIs from infrastructure to the capability layer for machine-driven workflows.

Why it matters: It matters because IAM, NHI, and platform teams will need to govern API access, trust boundaries, and lifecycle controls for agents as well as human developers.

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 (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).

👉 Read Kong's analysis of API ecosystems in the agentic era

Context

APIs have moved from integration plumbing to the access layer for machine-driven work. As AI prompts and agents begin initiating more real-time actions, the governance problem shifts from API consumption by developers to API consumption by software acting with runtime intent, which is an identity question as much as an architecture question.

Kong's article frames that shift as ecosystem-led growth, where API strategy, developer experience, and scalable infrastructure all become prerequisites for agentic workflows. For identity teams, the key issue is not whether APIs remain important. It is whether access, trust, and change management can keep up when the caller is no longer reliably human-paced.

That makes this topic especially relevant to NHI governance, workload identity, and API security programmes. The article's starting position is typical of the market right now: organisations understand the opportunity before they have solved the control model.

Key questions

Q: How should security teams govern agent-facing APIs in production?

A: Security teams should govern agent-facing APIs by treating each one as a non-human identity path with explicit scope, short-lived credentials, and monitored execution boundaries. Separate discovery from write access, record who owns the integration, and review schema changes as part of access governance. If an agent can trigger business actions, it needs lifecycle control, not just network reachability.

Q: Why do APIs become a bigger security issue when AI agents consume them?

A: APIs become a bigger security issue because agents do not compensate for ambiguity, broken contracts, or overbroad scopes the way humans often do. They repeat the same action at machine speed, so a small trust error can become a large blast radius. Governance has to focus on identity, action scope, and change control, not just connectivity.

Q: What breaks when API governance is built only for human developers?

A: What breaks is the assumption that a developer will notice and adapt when an API contract changes. AI agents and automations may continue acting on stale assumptions, especially if permissions remain valid. That creates hidden access risk, process failure, and harder incident response. Teams need governance that anticipates automated consumption, not just manual integration.

Q: Who is accountable when an API-connected agent causes data exposure or misuse?

A: Accountability should sit with the organisation that owns the API, the team that approved the integration, and the owner of the workload identity or token in the path. If the API is exposed to external partners or agents, the offboarding and review process must be explicit. Governance fails when nobody owns the lifecycle of the access path.

Technical breakdown

APIs as the capability layer for agentic AI

In agentic systems, APIs stop being just transport endpoints and become the actionable interface through which agents retrieve context, trigger workflows, and move data across systems. That changes the security model because the important unit is no longer only the application. It is also the identity that can invoke the API, the scope of the action, and the reliability of the schema behind it. When agents sit on top of APIs, version stability, documentation quality, and request boundaries become part of the control surface.

Practical implication: map every agent-facing API to a specific identity, scope, and approval boundary before exposing it to production workflows.

Why developer experience and governance are now linked

The article is right to connect API growth with governance squads, documentation, sandboxes, and predictable versioning. Those are not just developer convenience features. They are the mechanisms that reduce integration ambiguity, prevent schema drift, and make external use safe enough to scale. In agentic environments, ambiguous APIs create security risk because agents do not compensate for broken structure the way experienced engineers do. They amplify it through speed and repetition.

Practical implication: treat documentation, sandboxing, and version control as governance controls, not as optional developer tooling.

MCP and the new abstraction over APIs

Model Context Protocol sits above APIs as a way for agents to discover and call tools, but it does not replace the need for hard API governance underneath. If MCP becomes the connective layer, then the identity and access problem moves one layer down rather than disappearing. Teams still need to know what the agent can reach, how long the credential remains valid, and whether the tool call is consistent with the intended workflow. The protocol bridge is only as safe as the controls behind the API it exposes.

Practical implication: align MCP exposure with the same access review, secret handling, and API governance controls already used for non-human identities.

Threat narrative

Attacker objective: The objective is to use trusted API pathways to execute actions, move data, or widen access faster than governance can constrain it.

1. entry: An agent or automation layer gains access through an API integration, gateway, or MCP-enabled connector that was designed for broad ecosystem use.
2. escalation: The caller expands from read-only discovery into write-capable or workflow-triggering API usage as trust and scope widen across the session.
3. impact: The resulting blast radius is business-process manipulation, data movement, or credential exposure through a machine-consumed API path.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API governance is now an identity control problem, not just an engineering discipline. Once agents become real consumers of APIs, the control question changes from whether an endpoint works to whether the caller should be trusted to use it at runtime. That pushes API governance into the same domain as NHI and workload identity management. The practitioner conclusion is that API strategy must be reviewed as part of access governance, not only platform engineering.

Documentation and versioning are security controls when machines are the consumers. Humans can tolerate ambiguity in an API and recover through judgment. Agents cannot. If schemas drift, permissions become broader than intended, and the workflow may continue at machine speed before anyone notices. That makes predictable versioning and clear capability maps part of the security baseline. The practitioner conclusion is to treat change control as a guardrail on machine access.

Capability ecosystems create identity sprawl unless every integration is lifecycle-governed. The article's ecosystem-led growth model is attractive because it scales value through many participants, but it also multiplies non-human identities, tokens, and connectors. That expands the governance surface faster than most IAM programmes are designed to absorb. The practitioner conclusion is that external API growth must be tied to inventory, offboarding, and review discipline.

Runtime API trust depends on a named concept: identity blast radius. This is the distance between a single agent or integration and the maximum business impact it can create through API access. In the agentic era, blast radius is determined less by how many APIs exist than by how broadly they can act once a caller is trusted. The practitioner conclusion is to measure API privilege in terms of business impact, not only endpoint count.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• Another finding in the same research shows that 80% of organisations report AI agents acting beyond intended scope, including unauthorised access and sensitive data sharing.
• For a broader control lens, see NHI Lifecycle Management Guide for how inventory, review, and offboarding discipline close lingering access paths.

What this signals

Identity blast radius: As agent-driven API adoption grows, the useful question is no longer how many APIs exist but how far each trusted caller can move once access is granted. That shifts programme design toward scope isolation, offboarding, and reviewable ownership, which are core disciplines in the NHI Lifecycle Management Guide.

With 92% of organisations saying AI agent governance is critical but only 44% having implemented policies, the market is signalling a control gap that will widen as API ecosystems become more autonomous. The next practical move is to align API exposure with identity review cycles and access revocation workflows, not only with developer velocity.

Enterprises that already treat workload identity and secret handling as lifecycle problems will adapt faster than those still framing APIs as static integration assets. The operational test is whether a machine caller can be inventoried, scoped, and removed with the same discipline as any other privileged non-human identity.

For practitioners

• Inventory every agent-facing API path Classify each endpoint, gateway route, and MCP-exposed tool by business function, data sensitivity, and whether it can initiate writes, not just reads.
• Bind API access to workload identity Use short-lived, uniquely attributable credentials for integrations, and separate discovery access from execution access so agents cannot move directly from inspection to action.
• Review version drift as a control failure Set a change threshold for schema updates, response shape changes, and permission expansion, then force re-approval when the contract changes.
• Tie external APIs to offboarding discipline Remove unused keys, connectors, and partner routes when projects end, because ecosystem-led growth creates lingering access paths unless lifecycle ownership is explicit.

Key takeaways

• Agentic AI turns APIs into an identity and access problem because machine callers can consume and chain actions at runtime.
• API growth and ecosystem expansion increase the blast radius of every exposed connector, token, and MCP-enabled route.
• Governance has to cover documentation, versioning, lifecycle offboarding, and workload identity if organisations want agentic scale without uncontrolled access.

Key terms

• Agent-facing API: An agent-facing API is an interface designed or exposed so software agents can call it directly to retrieve data or trigger actions. In practice, it becomes part of the machine identity surface and must be governed for scope, ownership, and lifecycle just like any other privileged connector.
• Identity blast radius: Identity blast radius is the maximum business impact a single identity, token, or integration can create if it is trusted too broadly. For agents and APIs, it is shaped by write permissions, reachable systems, and how far a machine caller can chain actions before review occurs.
• Workload identity: Workload identity is the machine-held identity used by services, applications, agents, and automation to authenticate to other systems. It should be uniquely attributable, short-lived where possible, and governed through inventory, rotation, and offboarding so access does not outlive the workload.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Kong: Insights from eBay: How API Ecosystems Are Ushering In the Agentic Era. Read the original.