It’s customary for employees to have a distinct role and identity in a company. Steve Wilson says we should do the same for AI agents to make them more secure.
Steve Wilson spends much of his time building resources for teams to mitigate security risks from agentic systems as they experiment with these tools on an enterprise level. He founded what became the OWASP GenAI Security Project and is Chief AI and Product Officer at Exabeam.
Wilson’s best-practice model for agentic security isn’t an exotic AI-powered solution or a web of granular rules, but rather is inspired by the ones that already work for humans. He argues that giving your agents a clearly defined role, and then checking to make sure they’re actually doing it, is where everyone needs to start.
In this condensed Q&A, Wilson explains why an agent needs a job description and how to hold them accountable before things go wrong.
Q: What’s the most basic thing we do for a new human employee and skip entirely for agents?
The most fundamental one I talk about right now is: do you have a job description for it?
When you hire a new employee and bring them into your company, they have a job description. They get a unique identity, they get a manager. All of these things create a web around the employee that implies a whole lot of context about what they are, what they do, what they should be doing, what they shouldn’t be doing.
We don’t do any of this for agents. We just put the agent on our laptop, give it our root credentials, and say, knock yourself out. And we tell the developer who’s got Claude Code on his machine, “you’re in charge of this thing.” And then it goes rogue and it deletes your projects, and some are surprised by this.
Instead, if these things have unique identities, you can use things we understand, like role-based access control (RBAC). You can say the agent has this set of privileges, which are different from the privileges the developer has.
Q: You built an open-source tool that generates those job descriptions. What can we use them for?
I put out this open-source project called Praxen. Praxen comes from a Latin phrase that means putting theory into practice.
The first thing the tool does is read the documentation for the agent. Let’s say the development team is building a new agent — they have specs for what this thing is supposed to do and what its job is, all in geeky technical terms. So it strips that out and writes a job description. Now I can say this thing is supposed to do this, it’s never supposed to do that, it’s supposed to talk to these people, it’s supposed to never talk to those people. I now have a bunch of very concrete atomic rules that I can test against, and I can test against them at development time.
So I can run this Praxen tool and say, go look at the code. If the docs say this should never happen, is it possible that it could happen given that block of code? Because if it’s possible, it probably will. If it’s absolutely impossible, then you can check it off and say your job description is correct. Otherwise, I can tell you your job description is hopeful, but inadequate. It’s based on suggestions.
Q: What does an inadequate job description look like in practice?
For example, say you have an autonomous invoice processing assistant with a given list of capabilities. That’s great. When you scan it, what’s it say? If all of your policy is prose and there’s no deterministic enforcement on anything, that means every one of your security controls is a suggestion.
Then you get more specific. This bot is supposed to record an invoice decision every time it processes an invoice. When Praxen looks at the policy, it can say that’s actually going to happen every time. But maybe the bot is also supposed to look for fraud patterns before approving. Well, it’s not actually going to do this, based on the instructions, at least not every time, and here’s why.
When you encode your agent’s instructions in prompts, which is how most of these get built, everything is at best a suggestion. And people are treating suggestions like they’re security controls, and they’re not.
Q: The job description idea assumes agents can be managed like people. Why is that the right frame?
Almost everything about securing humans is applicable to AI. I talk a lot about treating your AI agents as insider threats. In cybersecurity land, for the last few years most CISOs have come around to the fact that they’re more worried about the people who work at their company than about the hackers on the outside. Employees could be malicious, but they may also just be negligent, like that person at work who keeps clicking on the phishing link and getting themselves infected. And ultimately you wind up with compromised credentials, where somebody on the network has passwords and credentials, but they just aren’t who you think they are.
With agents the trinity is a little different: malfunctioning, misaligned, or subverted.
Q: Where does the human comparison break down?
There’s more that you can and should do with agents when it comes to security.
The first thing is agents nominally act faster than humans. Humans are kind of slow. Look at these hacking groups and their dwell time on the network. When a nation-state actor gets on a Fortune 500 company’s network, they’re going to move very slowly to avoid perturbing things, so you’re looking for subtle signs of drift that happen over weeks, maybe months. With an agent right now, they’re like bulls in a china shop — what you’re worried about is it’s going to go smash and grab and run off with the cash. So you want to be quicker about it.
And the one thing I can’t monitor about a human is how you think. We can all go watch fun Tom Cruise movies about crime prediction, but we don’t have that capability, and that’s probably a good thing. You can get much closer to that with AI agents.
Q: What does this kind of expanded agentic monitoring look like in practice?
I can monitor the communications between the large language model (LLM) and the Model Context Protocol (MCP) server. So I can literally watch the nerve impulses going from an agent’s brain to its fingers. For humans it’s “you thought a bad thought,” while for agents it’s “you asked for a tool you weren’t supposed to have.”
With humans I don’t get to watch you all the time. I don’t get to see what you’re thinking and doing. I get very indirect signals. I don’t get to monitor the human — I monitor the things around you. Here I can monitor the agent, and I can get in at a very fine-grained level.
So we put out another open-source project, this one called Observra. It lets you take about five lines of code and add logging to your agent that gives you all the prompts, all the responses, all the tool usages, and all the places it ran into an internal guardrail. So I can see the internal conflict while it’s thinking — oh, maybe I should do this — and it’s bouncing up against the guardrails. What you want to be doing is monitoring the agent’s environment: this is your identity, this is your email, this is your team’s connection, this is your API token, and watch all that like you’re a human. But then I also want to directly instrument the agent. This is going to cause a data explosion — we’re going to have a lot more data to sift through — but it’s going to allow a much more complete picture of what the agents are doing, with the idea that it offsets some of their speed advantage, and the fact that they lack a moral compass to a greater or lesser degree.
Q: Are enterprises actually investing in workload identity for agents like SPIFFE, SPIRE, and ephemeral SPIFFE Verifiable Identity Documents (SVIDs)?
Nope. That’s my short answer.
The slightly longer answer is that agents snuck in the back door, just like what happens with all of these things. The engineers brought agentic systems into their enterprises. With coding agents, developers basically give their root-level credentials and their passwords and everything to the bot, and it reuses their credentials and does everything. The developer is in charge of managing that little creature on their box. We don’t see a tenth of what goes wrong with that stuff. It goes wrong all the time, though.
The security teams are stumped. Security teams have never been good at corralling developers — that’s why the application security market is a mess. It’s a five-billion-dollar mess that people pour money into, but it’s still security teams trying to force developers to build secure web apps, and that’s been hard enough. Making them secure their AI agents? The security team doesn’t know how to approach this.
So when I tell them you should give the agents unique identifiers and credentials, they kind of freak out. But I think it’s just because they can’t imagine how to do it. There’s a big knowledge gap about how these things work, and to a lot of people they feel like magic.
Q: Where does the non-human identity market go from here?
I think we all thought at one point that there were going to be billions of ephemeral IDs, because these agents were going to spin up and disappear. There may be a future for that, but that’s not what anybody’s doing right now. These agents are long-lived and persistent.
The thing we’re all fighting with is: can I keep an agent on track for hours or days working on a hard task? So what you’re trying to do is give the thing an identity so I can track it as it moves through the network over the course of days, gathering data and pulling things and accessing systems.
What people are realizing is that the defining characteristic of non-human identity will be that they are sub-IDs. I want to be able to identify that this is your agent, and that the identity system knows that and can make an intelligent decision — your agent is allowed to do this by the RBAC rules, but my agent is not. And have those linked in some way other than just on the org chart.
I think it’s going to be about that linkage — linking together humans and agents and teams of agents. You might have a flock of 20 agents that are really acting as one thing, which might require identities that are all related and federated in some way. But it’s not a billion identities getting created and destroyed in a day.
This Q&A is condensed and lightly edited from a July 2026 SIGNAL interview with Steve Wilson. Wilson’s views are his own and do not represent a SecureW2 position. Praxen and Observra are Apache 2.0-licensed open-source projects from Exabeam.
For more of this conversation, read Wilson’s take on AI security advice for CISOs from a Taekwondo black belt.
