Treat AI agents like you treat your colleagues

AI agents will wreak havoc on your security posture. But they don’t have to.

Indeed, AI agents are already forcing the identity and access management (IAM) market to consider how to solve a dual challenge: setting effective security rules for machines that behave unpredictably (like humans!), but also keeping an ever-growing army of malicious actors out of enterprise networks.

The element of unpredictability is key here, because what are AI agents at the end of the day? They’re software entities backed by LLMs that can autonomously use tools to complete multi-step workflows. It might be early days, but there’s a growing consensus that agentic AI is the future of generative AI apps.

If that future does happen, then enterprises will inevitably want to give their AI agents access to data on their networks. Unfortunately, most cyber solutions today simply aren’t designed to set effective security rules for AI technology that has unrestricted access to data.

AI is too dangerous to be given access to everything at once

What makes AI agents so unique, and potentially dangerous, is that they represent the first example of software that is vulnerable to both malware and social engineering attacks. That’s because they’re not as deterministic as a typical piece of software. They’re far more unpredictable, kind of like humans, and can be manipulated by very creative prompts. This isn’t theoretical, since we’ve already seen more than enough cases of clever prompt injection. One that comes to mind is a crypto user who recently manipulated AI Agent Freysa into handing over $50,000.

For that reason, AI agent technology is far too dangerous to be given permission to do everything at once. It needs to be constrained because we, as an industry, spend a considerable amount of time and effort coming up with roles for people, and each role has its own permissions and limitations, but we’ve never bothered doing that for the software that we run in data centres.

Well, the time to do it is now, because as it turns out, we now have software that is very much capable of behaving just as unpredictably as humans. In other words, leaving agents excessively privileged is just dangerous. You might have an LLM that generates thumbnails for your website, but then someone can trick that LLM to hand over the credit card numbers for all of your customers and upload them to an FTP site. With traditional software, that wasn’t possible, but with LLMs? It’s a dangerous new world of possibilities for malicious actors.

‘Access denied’ should be the default

Think of every piece of code that is AI as a highly privileged user with non-deterministic behaviour. If you’re devising guardrails for agentic AI environments, they have to account for the fact that agents straddle the line between humans and traditional machine workloads.

We need to apply the same treatment to agents that we do to people. Think of them as a digital colleague: if an agent is supposed to generate thumbnails, it should only have access to data tables related to generating thumbnails. If someone does trick the agent to instead access credit card tables, it should be greeted by an ‘access denied‘ notification. That’s what we do for people, and it should be no different for AI. If you are in a design department in an organisation, you shouldn’t have access to the information that the finance team has access to.

There are a few things to think about when designing your approach to protecting infrastructure against vulnerable AI agents. The most important thing is for your computing environment not to be anonymous. All connections, workloads, and datasets need to be maintained, which means that all identities for your servers, workloads, engineers, and AI agents need to be in place.

If you have processes or engineers running and accessing infrastructure behind aliases like ‘admin’ or ‘dev’, that is not the correct approach. There’s no such thing as anonymity in a trusted computing environment, which means you have to treat AI agents as employees. They need their own identity, just like your servers, workloads, engineers, and laptops.

Don’t make AI another silo

The danger that exists today with identity, however, is how extremely fragmented it is.

Usually, when people talk about identity, they’re referring to humans. And most of the time, that identity is some kind of a record in a database, or an identity management platform, as it’s called. At some point, folks realised we need to issue identities for machines, for workloads, for endpoints, etc. But that has led to severe fragmentation of identity that prevents enterprises from setting good policy in one place. It also prevents us from having visibility of what’s going on in one place.

This is why AI agents potentially present a problem, because they imply needing to go acquire yet another solution to manage the identity of AI agents. That is just simply not sustainable. We cannot afford to have an identity management platform for every single technology we deploy.

So if you deploy AI agents, they need to be integrated into a trusted compute paradigm. There’s already an approach for this that’s gaining traction in the cybersecurity market called Infrastructure Identity. Basically, it means the identity for everything and everyone is managed in the same layer within your infrastructure stack. The point of that approach is to make AI agents behave just like anyone else in your organisation.

There’s no anonymity in a trusted computing environment. That’s the biggest advantage of the Infrastructure Identity approach. By consolidating cryptographic identities and managing them within a zero-trust model, this architecture basically eradicates anonymity in computing, making every action accountable and auditable. This transparency is absolutely essential for enforcing security policies and maintaining a robust security posture, directly supporting the implementation of short-lived privileges for a truly secure, scalable, and trustworthy infrastructure.

It even gives companies an advantage with respect to emerging technology. Every emerging technology being brought into production is, on the one hand, critical for businesses to stay competitive, because your competitors are adopting that tech as well. On the other hand, every new technology represents yet another attack vector.

Every single layer of a technology listening on the network has its own idea of users, its own role-based access control, its own configuration and configuration syntax. That requires expertise, which most teams today lack, to secure every little thing they have, and yet the future keeps bringing new things they need to secure. Trusted computing environments enable organisations to incorporate new technology into a unified security model, which reduces complexity and speeds up innovation.

This consolidated infrastructure identity approach doesn’t just give you security but productivity gains as well! It’s so easy to get wrapped up in just the security implications of data breaches. But whenever I’ve spoken to enterprises about the primary benefits of adopting an infrastructure identity model, they always say that it actually improves productivity for engineers.

That’s not surprising, because if you have things like just-in-time access, cryptographic identity, and you’ve extended zero trust to all your identities, then you never even have to think about access. Everyone should have what they need at their fingertips, when they want it, but never more than that. That’s a level of peace of mind I think we all need right now.

So, yes, AI agents may wreak havoc, but they don’t have to…

Also from our opinions section

About The Author

Ev Kontsevoy, Teleport (1)
Ev Kontsevoy

Ev Kontsevoy is a serial tech entrepreneur and CEO of infrastructure access firm Teleport. He has contributed to TechFinitive under our opinions section

Read more from this author.

We take journalism seriously. To learn more on why you should trust us, head to our editorial guidelines page or meet our team.