AI agents have quietly become one of the most significant ungoverned attack surfaces in the modern enterprise. They are running on developer laptops, embedded in cloud workflows, and integrated across internal systems — yet most security teams have no visibility into what those agents are accessing, what credentials they are using, or what actions they are taking. Unlike external threats that security tools were built to intercept at the perimeter, AI agents have been invited inside the organization. They operate with implied human credentials, generate no meaningful audit trail, and face no standardized identity or access controls. The result is a governance gap that is growing faster than enterprises can respond.

The problem is not a lack of technology in general — it is a lack of technology designed specifically for this class of threat. Existing identity management systems, SIEM platforms, and cloud security tools were architected around human actors and deterministic software behavior. AI agents are neither. They are non-deterministic, capable of building their own tools, able to connect to arbitrary data sources, and increasingly deployed autonomously with minimal human supervision. The frameworks built to secure the last decade of enterprise infrastructure simply do not map onto this new reality.

What makes the situation especially urgent is the speed at which adoption is accelerating. Coding agents like Claude Code and OpenAI Codex are already standard tools for developers across engineering, marketing, and go-to-market teams. Each of those agents has access to the operator’s file system, network connections, and potentially production credentials. The enterprise perimeter is not being breached from outside — it is being bypassed from within, one developer laptop at a time.

Secrets management compounds the problem further. AI agents require authentication to every internal system they touch. In most deployments today, that means agents are holding live credentials — API keys, tokens, passwords — that, if the agent is compromised, can be exfiltrated to third-party destinations with no mechanism for detection or prevention. Building a system where secrets can be exposed to an agent at the moment of need without the agent retaining those secrets at any point in time is one of the hardest unsolved problems in enterprise AI operations.

Mirantis, through its Lens product team, has been building a solution to this problem — not as a theoretical exercise, but as a direct response to the governance challenges it encountered while becoming an AI-native organization itself. The result is Lens Agent, a unified platform that applies policy-driven governance to AI agents running across any environment: on-premises, in hyperscaler clouds, or on individual developer machines. It is currently in early access at lensh.io.

The Guest: Miska Kaipiainen, Head of Product at Lens, Mirantis

Key Takeaways

• Traditional IAM and perimeter security tools are architecturally incapable of governing AI agents that operate on implied human credentials inside enterprise systems — a fundamentally new identity class requiring purpose-built controls.
• Lens Agent is built on Micro VM-based sandboxing technology — not containers — with a supervisor component that inspects all inbound and outbound data traffic in real time and enforces policy at the network layer.
• The secret injection problem is one of the hardest challenges in AI agent governance: agents need authentication to every system they touch, but holding live credentials creates catastrophic exfiltration risk if an agent is compromised.
• Agent autonomy and safety are not opposites — controlling which software repositories agents can access, which tools they can build, and which data sources they can connect to is how enterprises preserve utility while limiting blast radius.
• Mirantis’s acquisition of Iron extends its “metal to model” infrastructure narrative to a “metal to model to agents” story, with Lens Agent positioned as the governance layer for the agentic tier of that stack.

***

In this exclusive interview with Swapnil Bhartiya at TFiR, Miska Kaipiainen, Head of Product at Lens, Mirantis, discusses how Lens Agent works under the hood, why the AI agent governance problem is categorically different from traditional enterprise security challenges, what the secret injection problem is and how it can be solved, how organizations can balance agent autonomy with meaningful safety controls, and what the Mirantis Iron acquisition means for the Lens platform and its enterprise roadmap.

The Origin of Lens Agent: Built From Internal Pain

Lens Agent was not conceived as a market opportunity — it was built because Mirantis needed it for itself. As the company moved to become an AI-native organization, teams across engineering, marketing, and go-to-market began deploying autonomous AI agents for individual and team-level workflows. What they found was a fragmented landscape of point solutions that addressed individual pieces of the problem but left the core governance challenge completely unaddressed.

Q: AI agents are spreading fast across developer laptops, cloud services, and internal systems. As that sprawl happens, governance hasn’t kept pace. Why does that distribution across environments make these agents so difficult to govern in the first place?

Miska Kaipiainen: “We actually noticed this ourselves about half a year ago. We started moving to become an AI-native organization and we started running autonomous AI agents for our own individual needs, within our teams. We have multiple teams — marketing, GTM, engineering. All of these teams want to run agents. And we found out that actually it’s not the problem of having great technologies. There are bits and pieces of technologies everywhere and each one of those technologies addresses different pieces of the puzzle. But we didn’t find anything that we could actually use ourselves to really understand where the agents actually have access and how we can actually govern that access. That’s basically why we started building this platform — initially for our own needs. And we found out at the end that, hey, this is actually pretty cool and maybe other organizations are in the same spot as we are. So that’s where it all started, with our own internal needs, and it took off from there.”

What AI Agent Governance Actually Means Beyond the Buzzword

The word “governance” carries significant baggage in enterprise technology — often perceived as friction imposed on developers rather than infrastructure that makes developers more capable. Kaipiainen, who describes himself as a developer by background and a heavy user of Claude Code and OpenAI Codex, reframes governance not as a compliance exercise but as a practical safety layer that even individual developers have begun to demand for their own protection.

Q: Governance is a word that gets thrown around a lot. What does governing AI agents actually mean in practice, beyond the marketing language?

Miska Kaipiainen: “I’m a developer by heart myself, and governance is kind of not one of my favorite words, to be honest. But what I learned by being a massive user of Claude Code and Codex and all of these coding agents is that I started to feel that, hey, actually I want to have a little bit of governance for the AI agents that I’m now running on my laptop. Even. If you think about all the places where these AI agents have access to — they have basically access to my entire operating system. Even though sometimes they might be asking permission if they can do something or not, we all know that sometimes they just don’t. And that drove us to the realization that the problem starts from the individual user’s machine already, and what can we do there? And then it goes all the way to the autonomous agents that enterprises run on their production environments. There are multiple layers. It’s the connectivity to all the critical business contexts, and also how do you manage secrets and everything related to that. It’s a very, very complex topic and it took quite some time for us to put all the bits and pieces together for this solution.”

Why Traditional Security and Identity Systems Fail for AI Agents

Enterprises already operate mature security stacks — SIEM tools, identity platforms, cloud security posture management, endpoint detection and response. The instinctive assumption is that these systems should extend naturally to cover AI agent behavior. Kaipiainen explains why that assumption is architecturally flawed and why AI agents represent a genuinely new identity class that existing enterprise security infrastructure was never designed to handle.

Q: Organizations like Mirantis already have cloud platforms, security tools, and identity systems in place. Why are those systems not sufficient for managing AI agents? What is fundamentally different about this specific problem?

Miska Kaipiainen: “That’s a funny thing, because for a very long time we have been used to protecting against threats that are coming from the outside to inside our organization. And now it’s been almost like a paradigm shift. We have been basically inviting the AI agents inside our organization. It’s not anymore defending threats that are coming from outside — it’s actually the threats that the AI agents themselves cause by being inside the systems already. And often these AI agents are using the human credentials. It’s not like the AI has its own credentials — they are working on behalf of humans, and it’s kind of implied credentials. And that’s a very problematic case, because not many organizations have a system or identity solution to answer: how do we identify agents, what are the AI behaviors, and how do we distinguish those from the human actors that are using our systems? It’s a completely new kind of set of identities that needs to be governed.”

Balancing Agent Autonomy With Safety Controls

One of the central tensions in enterprise AI deployment is the tradeoff between agent capability and organizational control. An agent constrained to the point of uselessness provides no value. An agent given unchecked autonomy creates unacceptable risk. Kaipiainen walks through the specific technical mechanisms — data source connectivity, tool-building restrictions, software repository controls, and secret injection strategies — that define what a well-governed agent environment actually looks like in practice.

Q: There is a real tension between letting agents be autonomous enough to be useful and keeping enough control to stay safe. How do organizations actually balance that — especially as agents are becoming more capable and organizations want them to do more?

Miska Kaipiainen: “I think it’s kind of manageable. Hallucination is still happening — it has not disappeared. Of course it’s getting better and better because the models themselves are just becoming so much more amazing all the time. If you compare the models we had a year ago to the models we have today, it’s like night and day — the difference in quality of responses and capabilities. But in essence, what agents need — they need two things. They need connectivity to relevant data sources. Whether it’s your Salesforce data, your financial data, maybe some internal knowledge-based systems, whether it’s a source code system, whether it’s some production environment that you need to be monitoring or want these agents to be interacting with. So it’s all about managing connections. And then at the same time it’s managing what is the available toolbox that the agents have at their disposal for actually doing something with those connections. Now, very capable agents — you basically give them full freedom to build the tools they need themselves if you give them a challenge. They can create the tools they need to accomplish the task even if they don’t have the tools. They can be pretty good at figuring out how to solve different problems. And for that, of course, you need to start restricting: what kind of tools can you actually build and how? It’s not a deterministic system. Agents might do whatever. And for that the only way is you need to control, for example, what kind of software repositories you are giving these agents access to — to go and install tools and libraries. So when they are building their internal tools to accomplish a task, they are less likely to introduce security vulnerabilities that might then do something bad with your production environments. Another thing is how do you manage the secrets, because every place in your internal systems needs authentication. You need to grant identities to your agents and they need to be authenticating to these external systems with their own identities. But even there it’s not easy, because if the agent is compromised it might be sending these secrets already to third-party places where you don’t want any information sent. So you need to develop a system where the secrets can be exposed to an agent while the agent actually doesn’t have any secrets at any moment in time. We are talking about secret injection, and there are different strategies for how this can be accomplished. It’s very difficult. Agents are fast, they are doing all kinds of things all the time. We have to trust them — they are not malicious by nature — but you just need to put in checks and balances so that you as a human are still on top of things and have all the controls in place so that the agents just don’t go wild and do things you don’t want. It’s a very, very complex topic, this whole governance topic for agents.”

How Lens Agent Works Under the Hood

Lens Agent is built around two core technical components: a Micro VM-based supervised sandbox and a centralized control plane for visibility and audit. The platform is infrastructure-agnostic — deployable on-premises, on AWS, on Azure, or on Google Cloud — and supports both Mirantis’s own agent and any third-party or custom-built agent that enterprises are already running. The architecture is designed to insert governance into the agent execution environment without requiring agents to be rebuilt or replaced.

Q: Talk about how Lens Agent works under the hood — it’s described as a unified platform that brings policy-driven governance to AI agents running anywhere across your environment.

Miska Kaipiainen: “Basically we have two major components. First of all, we have been building our own sandboxing technology that is not based on traditional container technology — it’s based on Micro VM technology. And we have a supervisor component that is watching all the time what is happening inside this sandbox, and every kind of data traffic that goes in or out from this sandbox is basically policy-managed. That’s one of the core components of this technology stack. It’s the supervised sandbox technology, and we are providing it as a platform. An enterprise can run multiple tens or hundreds or thousands of these supervised sandboxes on their target environment — whether they want to deploy these on-premises or on AWS or Azure or Google Cloud, they can leverage their hyperscaler capacity to run these sandboxes. What we do is provide that control plane for centralized visibility. All the audit trails and everything that the agents are doing basically comes to our central location for central IT governance. That’s the platform piece of the story. A side story to that is that we also provide our own agent for those organizations that are still trying to figure out what kind of agent they should be running in their enterprise setting — we make that decision slightly easier. They can take our agent. But at the same time, basically any agent — if you have already developed agents or anything like that — they run on top of this platform just fine, and you gain all this visibility, governance, and control for all your agents.”

The Biggest Risks From Ungoverned AI Agents Right Now

Kaipiainen makes clear that the threat from poorly governed AI agents is not a future-state risk — it is present and active. The entry point is not an exotic attack vector. It is the coding agent already running in the background on a developer’s laptop inside the corporate network.

Q: What are the biggest dangers enterprises are facing right now from agents that are unmanaged or poorly governed?

Miska Kaipiainen: “Oh gosh. And by the way, this is a serious threat because I think all of us — probably everybody who is listening to this show right now — they are probably having somewhere on their machine already maybe Claude Code doing some work in the background. So it’s just a matter of time when something very, very bad will happen. I hope that just raising the awareness that even an innocent-looking agent running on your laptop is a massive security threat for many enterprises. How can you actually govern even those agents that run on your employees’ laptops? That is a question that I think we need to have an answer to very soon. Otherwise it’s going to be wild times ahead.”

Lens’s History and Why the Developer Footprint Matters

Lens began as a Kubernetes IDE that grew to more than one million developers. That installed base is not incidental to the Lens Agent story — it represents a direct distribution channel into the exact environment where AI agent governance risk is most acute: individual developer machines inside enterprise networks.

Q: Lens started as a Kubernetes IDE with over a million developers. How does that foundation inform how you approach building a governance layer, and why does that existing footprint matter for where agents actually live and operate?

Miska Kaipiainen: “Well, I think first of all, since we have quite many users, we are able to help those users almost immediately by providing them with the safe technology to run agents on their local machines, just like that. That’s of course what we are hoping to do right away. And hopefully later on the companies employing these people will also find value with Lens Agent as a platform for the same reasons. We try to use our bigger reach to spread the solution that we feel is fundamentally making use of AI and AI agents more safe for everybody. We hope that many people will find us and start using our technologies.”

The Mirantis Iron Acquisition and the Metal-to-Model-to-Agents Vision

Mirantis recently acquired Iron, extending its existing “metal to model” data center infrastructure narrative. Kaipiainen explains how that acquisition and Lens Agent together complete what is becoming a vertically integrated story from bare metal infrastructure through AI model deployment and into the agentic execution layer — positioning Mirantis to serve enterprise customers at every layer of the emerging AI operations stack.

Q: Last week we talked about the Iron acquisition. What will be the impact of that acquisition on projects like Lens, which are a core part of what Mirantis is offering to the community and the enterprise ecosystem?

Miska Kaipiainen: “Mirantis is of course a very well-known name in the market for bringing data center technology from metal to model, and I think what we can now do is expand this concept from model to agents. Basically, you have the models — and then what you need next is of course the agents. I think there is a very good play in there and how these offerings are going to be supporting each other. We are looking forward to serving all these Mirantis Iron and Vikra accounts and customers.”