H&M’s AI gateway shows how enterprise AI governance scales

At a glance

What this is: H&M’s AI gateway story shows how centralised control can turn scattered GenAI pilots into a governed enterprise capability.

Why it matters: It matters because IAM, NHI, and AI governance teams are all being asked to control authentication, logging, and access risk before AI sprawl becomes operational debt.

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, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Kong's analysis of H&M's enterprise AI gateway model

Context

Enterprise AI becomes a governance problem the moment different teams start wiring LLMs directly into business systems. Without a control plane, organisations inherit fragmented authentication, inconsistent logging, weak secrets handling, and limited cost visibility, which creates the same kind of sprawl identity teams have seen before with unmanaged machine access.

Kong’s H&M example is useful because it treats the issue as infrastructure, not experimentation. That framing aligns closely with how IAM and NHI programmes should think about AI connectivity: if access, auditability, and policy are not centralised early, the organisation ends up retrofitting controls after usage is already embedded.

For teams already dealing with workload identity, API keys, and service-account governance, this is a familiar pattern. The new variable is that AI traffic multiplies the number of trust decisions being made, and the blast radius grows when those decisions are scattered across teams.

Key questions

Q: How should organisations govern AI applications that connect directly to models?

A: They should place a central control layer between applications and model providers so authentication, routing, logging, and policy are enforced consistently. That prevents each team from inventing its own access pattern and makes AI usage auditable across the enterprise. A gateway also gives security and platform teams one place to manage trust boundaries.

Q: Why do direct LLM integrations create governance risk?

A: Direct integrations spread credentials, logging, and policy decisions across many teams, which creates inconsistent access control and weak auditability. The risk is not only security exposure but also operational and financial opacity. When access is decentralised, it becomes much harder to prove who used what model, for what purpose, and under which policy.

Q: What breaks when AI logging is not centralised?

A: Auditors and security teams lose the ability to reconstruct what data was sent to a model, which application initiated the request, and whether the access was approved under the right policy. Without central logs, investigation and compliance both become guesswork. That makes the programme harder to defend and harder to govern.

Q: How do IAM and NHI teams fit into AI gateway governance?

A: They should treat AI connectivity as part of the same control problem as workload identity and secrets management. The gateway becomes the enforcement point for access, audit, and policy, while IAM and NHI teams define the rules for who or what may call the models. Shared governance prevents AI sprawl from creating a second identity estate.

Technical breakdown

Why AI gateways become identity control points

An AI gateway sits between applications and model providers, so it becomes the enforcement layer for authentication, routing, rate limiting, logging, and policy decisions. In practice, that makes it closer to an identity and governance checkpoint than a simple traffic proxy. For AI systems, the gateway is where the organisation decides which workloads may call which models, what data may pass, and how those calls are recorded for audit. Without that layer, every team creates its own trust pattern, and none of them are consistent.

Practical implication: centralise model access policy where AI traffic exits the application, not inside each team’s codebase.

Secrets management and logging for LLM integrations

Direct LLM integrations often scatter API keys, callback credentials, and data-handling rules across multiple applications. That creates an exposure pattern very similar to unmanaged non-human identity sprawl, except the business impact includes prompt data, output data, and model usage metadata. Centralised logging matters because AI governance fails when you cannot prove what was sent, which model saw it, and which application triggered the request. Rate limits and auth controls are only part of the story; the record of use is what makes oversight possible.

Practical implication: treat AI logs and secret inventories as first-class governance artefacts, not optional engineering telemetry.

Cost attribution as an identity governance signal

The article links AI adoption to cost opacity, which is more important than it first appears. When individual teams can open their own model connections, spend becomes impossible to attribute and policy becomes impossible to enforce consistently. That is a governance smell, because the same identity sprawl that hides access risk also hides economic risk. A central gateway gives finance, security, and platform teams a shared view of usage patterns, making controls easier to review and misuse easier to spot.

Practical implication: use AI usage attribution as a control signal, not only a finance metric.

Threat narrative

Attacker objective: The objective is not a single exploit outcome but uncontrolled AI access that expands data exposure, cost leakage, and governance blind spots.

1. Entry occurs when individual teams connect applications directly to LLMs through their own credentials and integrations, bypassing a central control layer.
2. Escalation follows as authentication, logging, and secrets handling diverge across projects, creating inconsistent trust boundaries and fragmented audit evidence.
3. Impact is organisational sprawl, where sensitive data exposure, untracked costs, and weak compliance visibility accumulate across the AI estate.

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

AI connectivity is becoming an identity governance problem before it becomes an AI architecture problem. The H&M pattern shows that once LLM access is distributed across teams, the organisation inherits the same failure mode seen in unmanaged NHI estates: inconsistent authentication, incomplete logging, and no reliable governance boundary. The practical conclusion is that enterprise AI programmes need a control plane mindset, not a collection of isolated integrations.

Centralised policy is the only credible way to keep AI experimentation auditable at scale. When each team builds its own credential handling and logging, the result is policy drift rather than innovation velocity. That makes AI gateway governance structurally similar to NHI lifecycle governance, where visibility and standardisation matter more than the number of tools involved. Practitioners should view central enforcement as the baseline for any serious AI programme.

Scope creep in AI integrations is a non-human identity problem in disguise. The access pattern is not just model invocation, but a growing mesh of API keys, tokens, and data routes that behave like machine identities with expanding blast radius. H&M’s approach shows that organisations can reduce fragmentation before it becomes technical debt. Practitioners should map AI traffic into the same inventory and control model used for other privileged non-human access.

Platform-first AI governance is now a programme design choice, not a later optimisation. Enterprises that postpone control-plane design end up trying to recover auditability after usage patterns have already spread. That makes governance more expensive and less reliable because the organisation is certifying behaviour after the fact instead of shaping it at the point of access. Practitioners should treat central AI governance as part of the operating model from day one.

Identity teams should expect AI gateways to converge with workload identity and secrets governance. The same policy logic that governs service accounts, tokens, and API access is now being extended into AI traffic, which means IAM, platform, and security teams will increasingly share responsibility for the same control surface. The implication is clear: if those functions do not align early, the governance model will fragment along organisational lines rather than technical ones.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, which leaves compliance and investigation teams operating with incomplete evidence.
• For a broader governance lens, see OWASP Agentic AI Top 10 for the control failures that emerge once AI behaviour moves beyond simple automation.

What this signals

AI gateway programmes will increasingly be judged by whether they unify identity, policy, and evidence. If the organisation cannot show who accessed which model, what data moved, and which rule governed the request, the platform is not mature enough for scale. The control plane is becoming the governance plane, and that shift will shape procurement and architecture decisions across IAM, NHI, and platform engineering.

NHI teams should expect AI traffic to look less like application traffic and more like privileged machine access. The operational pattern includes secrets, tokens, scoped access, and data movement, so the right comparison is not generic API management but governed non-human identity. That means inventory, lifecycle, and audit disciplines now need to extend into AI integration design.

With 80% of organisations already reporting AI agents acting beyond intended scope, per the AI Agents: The New Attack Surface report, the risk is no longer theoretical. Enterprises that centralise AI access now will be better positioned to absorb agentic growth without multiplying blind spots or policy drift. The same governance logic that controls machine identities will increasingly govern AI-mediated access paths.

For practitioners

• Standardise AI access through a central control plane Require model access, routing, and policy enforcement to pass through a single gateway layer so teams do not create separate trust paths for each integration.
• Inventory every AI credential and callback path Track API keys, service tokens, and downstream data routes used by LLM-enabled applications so you can see where access is granted and where data can leave.
• Tie AI logging to compliance evidence Make request logs, prompt handling records, and access events available for audit review so governance teams can verify what was sent to which model and when.
• Align platform, IAM, and finance controls Use shared ownership for authentication, rate limits, and cost attribution so security and business teams are reviewing the same AI usage signals.

Key takeaways

• Enterprise AI sprawl quickly becomes an identity and governance problem when each team connects directly to LLMs without a control plane.
• Centralised authentication, logging, and policy enforcement create the auditability needed to scale AI safely across the organisation.
• IAM, NHI, platform, and finance teams need shared ownership of AI access and usage controls before fragmented integrations harden into technical debt.

Key terms

• AI Gateway: An AI gateway is a control layer that sits between applications and model providers. It centralises authentication, routing, rate limiting, logging, and policy enforcement so organisations can govern model access consistently instead of letting each team build its own trust path.
• Control Plane: A control plane is the place where policy decisions are made and enforced for a shared service. In AI environments, it defines who or what can call a model, what data can move, and how those actions are observed for security, compliance, and cost management.
• Non-Human Identity: A non-human identity is any machine, workload, token, secret, or service account that authenticates and acts on behalf of a system rather than a person. In AI programmes, these identities often carry the credentials, permissions, and audit gaps that determine whether access remains governable.
• Auditability: Auditability is the ability to reconstruct what happened, who or what did it, and under which policy. For AI traffic, it depends on complete logs for requests, credentials, and data handling so security and compliance teams can verify behaviour after the fact.

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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by Kong: Building the Nervous System for Enterprise AI, about H&M’s generative AI gateway approach. Read the original.