Notifications
Clear all
Topic starter
05/07/2026 6:45 pm
TL;DR: AI gateways centralize access, policy, routing, telemetry, and scoped virtual keys across LLMs and agentic systems, according to Lakera, so enterprises can standardize governance instead of rebuilding it inside every application. The governance shift matters because AI complexity is moving from experimentation to infrastructure, and control now has to sit at the execution layer rather than in each app.
NHIMG editorial — based on content published by Lakera: AI Gateways: What They Are, What They Control, and Why They Matter
Questions worth separating out
Q: How should security teams govern access to AI models and tools?
A: They should govern AI access through a central control plane that applies identity, policy, budget, and logging rules before requests reach models or tools.
Q: Why do AI gateways matter for IAM and NHI programmes?
A: They matter because AI systems increasingly behave like non-human consumers of policy, data, and tools.
Q: What breaks when AI tool access is controlled only inside each application?
A: Policy drift breaks first, followed by inconsistent logging, duplicated permission logic, and uneven provider integration.
Practitioner guidance
- Centralise AI access policy in one enforcement layer Define which models, tools, and data sources each business function may use, and apply those rules in the gateway rather than inside every application.
- Bind AI requests to identity context and scoped entitlements Pass identity context through the gateway so downstream systems can evaluate role, purpose, and policy before allowing model calls or tool execution.
- Separate gateway governance from data-layer permissions Use the gateway to control request flow and tool invocation, but retain document-level ACLs, row-level policies, and search permissions inside the destination system.
What's in the full article
Lakera's full article covers the operational detail this post intentionally leaves for the source:
- Request-by-request policy enforcement patterns for enterprise AI gateways
- How routing, failover, and budget constraints are implemented across multiple model providers
- Practical guidance for tool invocation governance in agent and RAG workflows
- Where gateway controls stop and data-system permissions still need to be enforced
👉 Read Lakera's analysis of AI gateways for enterprise model and agent access →
AI gateways and agent access: what IAM teams need to know?
Explore further
05/07/2026 7:01 pm
AI gateway governance is the emerging control plane for non-human and agentic access. The article shows that enterprise AI has crossed from isolated experimentation into shared infrastructure, which means identity control must move closer to execution. That shift aligns with OWASP-NHI and zero trust thinking because access, routing, and logging are now enforced on the path to models, tools, and data. Practitioners should treat the gateway as a governance boundary, not just a traffic layer.
A few things that frame the scale:
- Companies are dedicating an average of 32.4% of their security budgets to secrets management and code security, with US organisations leading at 40.8%, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How do organisations decide whether an AI gateway is necessary?
A: They should assess whether they have multiple providers, multiple teams, regulated data, tool execution, or complex audit requirements. If those conditions are present, provider-native controls usually stop being enough. The gateway becomes the architectural layer that keeps AI adoption governable as usage expands.
👉 Read our full editorial: AI gateways centralize control for enterprise model and agent access
