Notifications
Clear all
Topic starter
18/08/2026 2:37 pm
TL;DR: Enterprise AI is repeating the cloud-native identity lesson in a new form: agents need controlled access, transaction context, and interoperability, not vertically integrated lock-in, according to Stacklok. The practical break point is not model quality but whether identity, tool access, and data egress can be governed across the full agent path.
NHIMG editorial — based on content published by Stacklok: Navigating the AI Infrastructure Landscape, Lessons from Kubernetes Creators
By the numbers:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
Questions worth separating out
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring.
Q: Why do AI agents complicate least-privilege design?
A: AI agents complicate least-privilege design because their tool use can change dynamically while the underlying permissions remain persistent.
Q: How do organisations avoid lock-in in AI infrastructure and identity controls?
A: Prefer open protocols, portable identity layers, and policy enforcement points that sit between agents and upstream systems.
Practitioner guidance
- Map agent access paths end to end Document every system, tool, and data source an agent can reach, then identify where identity context is lost between the caller and downstream services.
- Constrain agent privileges at the boundary Start with isolated execution, read-only access, and explicit egress controls for new agent workflows.
- Treat MCP endpoints as governed access surfaces Apply policy, logging, and review to every protocol endpoint that can invoke tools or retrieve context.
What's in the full article
Stacklok's full blog post covers the operational detail this analysis intentionally leaves for the source:
- How the team thinks about MCP as a protocol boundary for AI-native applications and enterprise tool access
- The role of LLM gateways in cost control, model routing, and sensitive data egress management
- Why transaction tokens need to persist across agents, interfaces, and downstream systems
- How developers, knowledge workers, and infrastructure teams may adopt different trust thresholds for agent access
👉 Read Stacklok's analysis of AI infrastructure identity and agent governance →
AI infrastructure identity controls: are your guardrails keeping up?
Explore further
18/08/2026 3:22 pm
Interoperability is now an identity control requirement, not a platform preference. The article’s Kubernetes comparison is really about who owns the trust boundary when agents access enterprise systems. Open protocols matter because they let identity teams govern access without hard-coding a single vendor stack into the control plane. The practitioner conclusion is that portability and enforceable boundaries now belong in the identity architecture discussion, not just the platform roadmap.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- The same survey found that only 13% of organisations feel extremely prepared for the reality of agentic AI, which helps explain why governance lags deployment.
A question worth separating out:
Q: What should teams do first when agent access starts reaching production systems?
A: Start by reducing blast radius. Put the agent in an isolated environment, remove unnecessary write access, define clear ownership, and require evidence before expanding permissions. The goal is to make the workflow observable and revocable before it becomes business-critical.
👉 Read our full editorial: AI infrastructure needs identity controls that preserve interoperability
