By NHI Mgmt Group Editorial TeamPublished 2026-05-22Domain: Breaches & IncidentsSource: Kong

TL;DR: Anthropic’s acquisition of Stainless signals that generating SDKs and MCP servers is becoming routine, but governing agent-to-tool and agent-to-model traffic remains the harder enterprise problem, according to Kong. Runtime policy, telemetry, and auditability now define whether AI connectivity is deployable at scale.


At a glance

What this is: Kong argues that Anthropic’s Stainless acquisition makes connector generation look solved while leaving runtime governance as the real enterprise gap.

Why it matters: For IAM, NHI, and agentic AI teams, the issue is shifting from building access paths to proving who or what can use them, under which policy, with auditable outcomes.

By the numbers:

👉 Read Kong’s analysis of AI connectivity, agent governance, and control plane design


Context

AI connectivity is the control problem that appears when agents must reach APIs, models, events, and memory without losing policy, auditability, or cost control. The Kong piece uses Anthropic’s Stainless acquisition to argue that connector generation is getting easier, but governance across those connections is not.

For identity teams, that means the bottleneck has moved from creating agent-ready interfaces to enforcing who or what can use them, when, and with what traceability. That challenge spans NHI, agentic AI, and broader IAM governance because the access path is only useful if the enterprise can control and prove how it was used.


Key questions

Q: How should teams govern AI agents that can reach APIs, events, and memory?

A: Teams should govern those agents as runtime identities, not as isolated integrations. That means enforcing policy at execution time, logging every tool and data access, and binding actions back to a clear initiating workflow or identity. If the control plane cannot show who acted, what they reached, and why, the programme does not have usable governance.

Q: Why do AI agents create a different access problem from standard automation?

A: AI agents can combine tools, events, and memory dynamically, so their access path is not fixed at provisioning time. Standard automation follows predetermined rules, but agent behaviour can drift within a session and across tools. That makes static approval models and narrow endpoint controls insufficient for enterprise governance.

Q: What breaks when agent connectivity is built without a runtime control layer?

A: Without a runtime control layer, enterprises lose visibility into which model or agent made each call, which data was consumed, and whether the action was within policy. The result is fragmented audit evidence, inconsistent rate control, and weak accountability when costs spike or data exposure occurs. Build-time tooling alone cannot close that gap.

Q: Which frameworks should guide governance for agent connectivity and AI tool use?

A: Use a combination of identity, zero trust, and AI risk frameworks to define control boundaries across models, tools, and memory. For agentic systems, align governance with neutral policy enforcement, auditability, and least privilege so changes in vendor runtime do not change the control standard.


Technical breakdown

Why API spec generation does not solve runtime governance

Turning an OpenAPI spec into an SDK or MCP server only addresses build-time plumbing. Runtime governance is the enforcement layer that sits in the request path, applies policy, captures telemetry, and produces audit evidence for every agent-to-tool and agent-to-model call. Without that layer, the enterprise can create connectors quickly but cannot answer basic control questions such as which agent acted, on whose behalf, or whether the call exceeded its intended scope. The technical issue is not connectivity alone. It is whether connectivity is policy-bearing and observable end to end.

Practical implication: Treat spec-to-SDK tooling as developer acceleration, not as a control plane.

Why agent systems need events, memory, and APIs together

Production agentic systems do not behave like simple request/response integrations. They are triggered by events, make tool calls, and persist context in memory across sessions and workflows. That means governance has to extend beyond API gateways into event routing, memory access, and replayable logs, because an agent can drift across all three surfaces in a single workflow. When those layers are governed separately, the enterprise loses a coherent view of what the agent knew, what it touched, and why it acted. This is where AI connectivity becomes an identity and telemetry problem as much as an integration problem.

Practical implication: Map policies across event streams, memory stores, and tool calls before scaling agent deployments.

Why control planes must stay neutral across models

The article’s architecture argument is that model vendors will continue to pull connectivity deeper into their own ecosystems, but enterprises are rarely single-model environments. A neutral control plane is therefore necessary because governance cannot depend on the runtime chosen by one vendor. Policy, audit, routing, and metering need to work across Anthropic, OpenAI, Google, AWS, and self-hosted models as peer endpoints. That is a structural requirement, not a preference. Once agents span multiple models and tools, governance that is tied to one vendor stack becomes fragmented by design.

Practical implication: Standardise governance above the model layer so policy survives vendor and runtime changes.


NHI Mgmt Group analysis

Generation-to-governance gap: The market is converging on fast connector generation, but the real enterprise risk sits in runtime control. SDK and MCP creation make access paths cheaper to build, yet they do not establish who can use them, when, or how actions are audited. The implication is that connectivity tooling without governance now creates operational debt rather than capability.

AI connectivity is becoming an identity architecture problem: Once agents can trigger on events, read memory, and call APIs, the access story is no longer limited to a single token or endpoint. The enterprise must understand identity across tool invocation, event consumption, and persisted context, which means NHI governance and IAM observability become inseparable from agent design. Practitioners should treat agent connectivity as a governed identity path, not a convenience layer.

Runtime policy is the real control plane: The article is right that build-time tooling can accelerate development, but the control plane that matters is the one that enforces policy at execution time. That control plane must capture telemetry, preserve accountability, and survive model switching across vendors and deployment patterns. The practitioner takeaway is that governance has to exist where the action occurs, not where the connector is generated.

Identity blast radius: When agent connectivity expands across models, events, and memory, a single permissive interface can propagate access far beyond the original use case. That is not a simple least-privilege failure. It is an identity blast radius problem in which every additional integration enlarges the scope of possible misuse, correlated failure, and audit uncertainty. Practitioners need to evaluate connector sprawl as an exposure multiplier, not as a feature count.

Vendor-pinned connectivity will not scale for enterprise governance: The piece correctly signals that model vendors will keep internalising parts of the stack, but enterprises cannot let governance fragment along those lines. A multi-model environment needs a neutral policy layer or the organisation will end up with inconsistent enforcement, incomplete logging, and weak cost attribution. The practitioner conclusion is that neutrality is a governance requirement, not an architectural nice-to-have.

From our research:

  • 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%), according to AI Agents: The New Attack Surface report.
  • 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 SailPoint.
  • That gap matters because 98% of companies plan to deploy even more AI agents within the next 12 months, according to AI Agents: The New Attack Surface report, so governance has to scale before the footprint does.

What this signals

Generation-to-governance gap: Connector generation will keep getting easier, but the enterprise still needs a neutral runtime layer that can enforce policy across tools, events, and memory. Without that boundary, agent deployments will outpace the organisation’s ability to explain or contain their actions.

With 80% of organisations already reporting AI agents acting beyond intended scope, the practical signal is that governance cannot wait for perfect tool maturity. Teams need to align identity, telemetry, and cost controls now so that model changes do not become control failures.

The next planning question is whether your programme can survive a multi-model estate without fragmenting audit and policy enforcement. That is where internal references such as the NHI Lifecycle Management Guide become operationally relevant for machine identities, access review, and offboarding discipline.


For practitioners

  • Define a runtime governance boundary Place policy enforcement, telemetry, and audit capture in the path of every agent-to-tool and agent-to-model call. Separate that boundary from build-time connector generation so teams do not confuse scaffolding with control.
  • Classify agent-accessible systems by risk and cost Inventory which APIs, events, and memory stores agents can reach, then assign policy based on blast radius and business impact. Include rate-limited endpoints, high-cost services, and long-lived context stores in the same review.
  • Create a neutral multi-model control plane Standardise routing, logging, and policy evaluation across all model runtimes, including hosted and self-hosted deployments. Avoid embedding governance in a single vendor stack if the estate already uses multiple models.
  • Instrument agent memory and event paths Track what data agents read from memory and which events triggered actions, then tie those records back to the initiating identity or workflow. Use the NHI Lifecycle Management Guide where lifecycle, offboarding, or access review processes apply to machine identities.

Key takeaways

  • Connector generation is becoming routine, but runtime governance is still the enterprise control problem that matters.
  • AI agent deployments already show measurable scope creep, so visibility and auditability are now baseline requirements, not future enhancements.
  • Enterprises need a neutral control plane across models, tools, events, and memory if they want agentic systems that security and finance teams can sustain.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10A1Agent connectivity and tool use create risks around governance and runtime misuse.
OWASP Non-Human Identity Top 10NHI-03Connector and secret governance is central to AI tool access and runtime exposure.
NIST CSF 2.0PR.AC-4Access management is needed for agents, tools, and memory stores across the estate.

Track agent credentials and secrets lifecycle, then enforce rotation and least privilege.


Key terms

  • Agentic connectivity: Agentic connectivity is the set of links that lets an AI agent reach tools, APIs, events, and memory during execution. The governance challenge is not just creating those links, but ensuring every one of them is policy-bound, observable, and attributable across the full workflow.
  • Runtime governance: Runtime governance is the control layer that evaluates policy while a system is operating, not just when it is built or deployed. For agentic and NHI use cases, it captures identity, tool use, data access, and audit evidence at the moment of action.
  • Agent memory: Agent memory is the persistent context an AI system reads and writes across sessions, workflows, or other agents. It can hold state, history, and retrieved data, which makes it part of the identity governance surface when access to memory affects what the agent can do.
  • Identity blast radius: Identity blast radius is the amount of access, data exposure, and operational impact that can spread from one identity or connector if it is over-permissioned or misused. In agentic systems, the blast radius expands quickly when connectors, memory, and events are governed separately.

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 lifecycle governance, it is worth exploring.

This post draws on content published by Kong: Anthropic Acquires Stainless. What's It Mean for AI Connectivity? Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-05-22.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org