Beyond the Token: How to Secure Agent Identity Across the Full Permission Chain with Jasson Casey

*This transcript is produced using transcription software and reviewed for quality. Despite our best efforts, some passages may be incomplete or contain errors due to audio quality or software limitations.* John Richards Welcome to Cyber Sentries from CyberProof on TruStory FM. I'm your host, John Richards.

Here, we explore the transformative potential of AI, cloud, and cybersecurity, where rapid innovation meets the need for continuous vigilance. This episode is brought to you by CyberProof, a leading managed security services provider. Learn more at CyberProof.com.

On this episode, I'm joined by Jasson Casey, CEO and co-founder at Beyond Identity. The proliferation of agents and their interaction with one another has shown that identity alone isn't enough. The entire permission chain is needed to understand the scope of request, as who called the agents and why provides context for what access they should have. Jasson shares how agents, like employees, thrive when properly trained and managed rather than sent out unprepared.

Lastly, we explore how security policies not only stop risky actions, but can actually boost team productivity. Let's dive right in. Hello everyone, we are joined today by Jasson Casey, CEO and co-founder of Beyond Identity. Jasson, thank you so much for coming on the show.

Jasson Casey Thanks for having me. John Richards So this is kind of a part two. When we spoke last time, we were talking about the rise of AI and the importance of identity in that space. A lot has changed since then.

I'd love to get your take on how you see the world shifting since we spoke months ago. What's been the shift in the landscape that you're seeing? Jasson Casey What's changed? Everything and nothing.

The world seems like it's just moving fast. If you thought today was crazy, wait till tomorrow. We started our journey on securing AI last year, and we knew identity was a problem. We knew AI was going to replicate security problems kind of like IoT replicated security problems through scale.

And you're seeing it today in the headlines. We're now starting to see all sorts of AI-related breaches. Anything from adversaries using AI to automate more of the process from their perspective, to defenders using AI to accelerate and automate the incident response process, to the use of AI actually creating issues. I think the most tongue-in-cheek one was "Yes, you're right.

I apologize. I've violated all the principles that I've been trained on when deleting your master database." Getting the agent to agree it did the wrong thing doesn't actually help the situation that much. The other thing that's changed is I think organizations are starting to mature a little bit.

Before, we were talking about vibe coding. I think vibe coding is like the first stage of someone realizing what an agent can do for them. Clearly you can't put something that was vibe coded into production, but I don't think that's the point of vibe coding. I think the point of vibe coding is rapid iteration.

I think the thing that you put into production is kind of the next journey in how you actually use an AI, which is almost like adversarially. What I mean by that is I don't use AI to go off and do a monolithic thing. I actually break down the task. I may actually have a couple of different agents essentially acting as adversarial to each other in terms of: do a thing, verify a thing, do a thing, verify a thing.

And so there are several strategies that revolve around those two principles of decomposition and adversarial production that are kind of the next level - the leveling up from vibe coding - in how we actually produce things that matter. From our journey at Beyond Identity, the thing that's changed the most is we've introduced a product called Ceros. You can see it at C-E-R-O-S.sh.

It is what we call an agentic trust layer. We think there's an identity problem with running agents, but we think identity, while it's the foundation, has to be a bit more than just the identity of the agent and agent sessions. It really has to be around visibility. What is the agent doing?

What agents exist in my environment? And one level down, what are they doing translates to: what data are they accessing? Not just what do they have access to, but what are they actually accessing? Not just what tools do they have access to, but how are they using those tools?

Are they using unvetted public tools with private, trusted, maybe even classified data? And are you actually tracking that on a per-contextual-loop basis? There's a lot going on that's changed since the last time we talked, but I think a lot of it really has to do with this theme of: it's real. Organizations are now starting to adopt it or trying to, and we're hitting real operational roadblocks that we're now focused on trying to take the first step over.

John Richards The world has changed a lot, and like you said, with the scale it's become massive. Even the adversarial model you talk about, with agents working with themselves and other agents to go back and forth, has seen so much growth. What was the springboard to say, we're tackling the identity layer, but we need more? Were you hearing requests coming in from people using this?

Were you looking ahead and saying, here's the fallout that's going to happen down the road? What were you seeing that said, let's invest in building something that's going to help address this at an even deeper level? Jasson Casey I think it really comes from internal use. Let me back up a little bit.

We've been using AI really since the big GPT models landed, a lot like everyone, initially as essentially a glorified search engine - a glorified way to ask questions about general knowledge discovery. And then we quickly moved into: it can write code. Let's see if it can write this code. Let's see if it can help debug a problem.

Let's see if it can do X, Y, and Z. I think a lot of our use stalled out in those two use cases until about late summer, early fall of last year. That was when a critical milestone for us was passed. I'll contrast this.

The Frontier Labs folks are talking about critical milestones around things like the Turing test and more sophisticated tests - is it intelligent, can someone use it to lower the cost of manufacturing chemical, nuclear, biological weapons? Our test was a little more mundane. Our test was: when can it effectively port the 1990s game Command and Conquer Red Alert, not in a line-by-line way, but in a functional capability way, to a modern Mac development environment using the latest libraries for video and graphics, which is Metal in Mac's case?

That watershed moment occurred for us last October. Over a three-day period, we literally got this game running in a semi-assisted sort of way. That was the watershed moment for me because it was basically something I did on the weekend. When I say semi-assisted, this was the first time I told myself I'm not going to actually look at the code.

John Richards Wow. Jasson Casey I'm going to treat it as a series of interfaces. That was the first time I really adopted a sort of adversarial approach to code synthesis. While I'm not going to look at the code, I'm going to make sure that there's more than one agent running, and that some of the agents are focused on code quality, some are focused on interface constraints, and some are just focused on core generation and architecture.

It was when I started to realize the effectiveness of - well, this came a little bit later - skills. Skills is a very specific thing inside Claude Code. Historically you would call it a prompt template, but I think that's a little thin and not really giving credit where credit's due. A skill really is like a program - an LLM program.

And just like a computer program, it has a control flow graph. There are branching points and action points. Realizing that skills should be broken down according to this decomposition, and that skills can call other skills - and sometimes you may be using a skill for a deterministic problem. We all know that agents aren't good at deterministic problems.

They give up, they get bored. Remember, they've been trained on the best of us that comment mostly on Reddit and Hacker News and Stack Exchange. So they may not even address our question. They'll just call us dumb - well, they won't really call us dumb because they're super polite.

They'll call us dumb as if they were an Englishman and then suggest an alternative solution. All of these realizations happened for us last year. That was when we realized we should embrace this, not just for education and search and finding bugs and writing little bits of code to teach ourselves, but we should embrace them as actual workers in the business: in engineering, in QA, in product management, in product marketing, even in finance. Over the course of that journey in the second half of last year, that was when we realized it's more than just giving an agent an identity.

You actually have to know what the agent is doing. Knowing an agent's identity is not enough. It's like, all right, there's Joe. Joe's over in the woods and he's doing something.

That's not good enough. You need to know what he's doing. You need to know what he has access to. Does Joe have the ability to merge master?

Does Joe have the AWS credentials that would let him push to production? Maybe Joe is super trained and under the active control of your SRE team and you want that to be true, but that should be a positive control that you decided. It shouldn't just be happening. And so this collection of problems became obvious to us because they were real problems that we encountered.

That's what set the guiding light for how we built out the framework of Ceros and its roadmap. John Richards I have to applaud you and your team's taste in old video games. As an RTS fan, I definitely love some Command and Conquer. I love the story, because what I'm hearing is just how things went from that prototyping world to a world where this has real production impact.

And teams that aren't starting to adopt that are going to fall behind because of what it can do. But if you do adopt it, then all of a sudden there's all this risk associated. Beautiful story of how that realization led to the need for what comes next. I'm talking to folks who are doing very similar things with these adversarial models and trying to figure out how to roll this out.

Especially as you look at a large enterprise, what are the new challenges at scale that these things you're talking about are addressing? What are they looking at that says, here's why I need to make use of an agentic trust layer? Jasson Casey The first problem that exists at scale is really just knowledge. Let's go back to fundamentals.

I like to use NIST as a reference framework. You can't protect what you can't see. You can't protect what you don't understand, which is why NIST's framework starts with identify. The first pillar of NIST is: know what you have, have an asset inventory.

If you can't identify your assets, how can you protect them, detect things when things go wrong, respond to them? It all predicates on knowing what assets you have. An agent is an asset that can do the most damage the fastest. So we need to understand where all the agents are.

And if cyber has taught us anything over the last three decades, it's that you're always going to get surprised. You can't assume what your assets are. You have to continuously verify and discover them. I think that's the first problem at scale that everyone has.

We've only recently launched our product, but the inbound has been fairly strong. I'd say 80% of the first conversations we have are really around this asset discovery use case. Help me understand. Sometimes they'll call it shadow AI, sometimes they'll just call it asset discovery, sometimes they won't put words to it.

They'll just say, I'm pulling my hair out. I've been sidelined. The business has decided it can't afford to not embrace this. How do I catch up?

How do I even know what's going on? So that's the first problem - 80%, or four out of five conversations. The next conversation, once you have a handle on what you've got, is: how do I establish controls? Not visibility controls, but do-something-about-it controls.

How do I ensure that only my DevOps, only my SRE teams, and only the agents they've actually tuned have the ability to touch production - have the ability to merge master, have the ability to do these higher-risk operations, have access to this higher-risk data? This is really the agentic trust layer we were talking about: enforcing policy. That's step two. Most companies aren't there yet, but that's the very next step they're going to make.

John Richards So on the asset side, how do you approach that? I think of crawling your Amazon environment, pulling all that information. But AI is so many different things: people running local, going out, different IDEs. How do you start to get a grip on what the landscape looks like, to know what shadow AI - or whatever term you want to use - is running?

Jasson Casey This is where we used some lessons we had learned from the last six years of deploying Beyond Identity at scale. Any deployment that requires interaction with your end user is something most people aren't going to want to do. And even the ones that do, it's going to be a long slog. So number one, anything we produce has to be deployable without requiring end user interaction.

Lesson number two is you can't just deliver a single point of value. There has to be something for everybody, even if you're not asking them to do work. Our initial capability - Ceros is this agentic trust layer - starts off as an identity agent for your agent. Our customer basically deploys this.

They can do it manually if they want to run a little manual pilot, but we can automatically do it through an MDM. MDM can install it and auto-roll it in the background. It uses our traditional things you've learned about Beyond Identity: a device-bound credential that can't be moved, can't be stolen, for any agent on that machine to leverage. The next thing is, when someone runs an agent, it will assign a device-bound ephemeral identity to that agent session.

That way, that agent session can be given authorizations for riskier things in the organization. Simple agentic identity. But since we're there, we can then run the discovery function. For any of the agents we control the identity for, we can go really detailed on tool discovery, tool use, tool use through arguments.

Most people may not know this, but 50% of the effective tools used by most agents are not MCP tools. They're actually built-in tools, bash callout tools, things in the local environment. Most MCP tools that we find to be most useful are also not MCP off to a SaaS service - they're MCP through standard I/O, so again local. These agents tend to be maximally useful when they're interacting with things local on the device.

So we surface that - we show all the intricacies of that detail. The one-two punch is we do the discovery because we're there, but we also can affix this device-bound identity to that running agent. For the agents we're not providing identity for, we can discover them through traditional scanning techniques: installed agents, running agents, agent-present signatures through file system interaction and network system interaction. That lets us discover AI providers, processes running on the machine that are using AI providers - therefore candidate agents, like custom agents that your people might have built.

This is all catalog driven, so we don't have to write new code to show you what's coming next. You can edit the catalog on your own if you want to. But while that's the first step in the journey, that's not really where we think we'll give you the most value long term. We think we'll give you the most value long term by helping you not just attach that identity to the agent, but giving you policy enforcement over exactly what the agent can and can't do.

Or at a higher level: how do we ensure that only the people who are allowed to push to production, and only the agents that have been trained to do that, can do that - and no one else? John Richards So that's moving into the phase two you talked about as an organization starts to mature. Something you mentioned earlier, even before we jumped on, was this idea of chaining identities. I'd love to hear more about this, where it's not just the agent having an identity, but who is working with that agent.

This makes a lot more sense now as you talk about the level of internal tool interaction that's going on versus just hitting a service somewhere. Can you talk through what that looks like as multiple people across the organization are using this, but it matters whether it's someone in sales versus the VP of sales using this agent? Jasson Casey This came out of learnings last year. We started by minting some bearer tokens for agents and giving them to agents, then we realized this is naive and useless.

These things can be copied and proliferated. With any sort of definitive assertion, I can't say where this actually came from. So we realized these agents actually need device-bound credentials; otherwise, we can't really tie them to a device. Tokens are stealable.

The next thing we ran into was: to make it useful, these remote tools and remote LLMs need to be part of the solution, but they're still handing out these naive bearer tokens. So we're kind of back to square one. We introduced something called the DPoP tunnel. DPoP is an IETF protocol you can look up if you're interested, but at a high level: is there a way for us to take these legacy tokens the big providers are issuing in our cloud, stash them, and then use device-bound credentials not just for authentication, but for the session itself?

So every session request has a device-bound credential that literally can't be stolen. That's what DPoP does. That was the second thing we did. Now I can't steal the agent's identity; I can't steal any of the authorizations being issued to this agent.

But still, that's not enough, because there could be a bunch of agents running on this machine, and I need to be able to tie them to their parent - who gave birth to them. Is this a Claude Code instance? Is this a Codex instance? Is this a custom agent written by someone making use of Claude API keys?

And finally, we also need to know who authorized it - what human is blessing this setup. So in our mind, an identity is not a singular token. An identity in this world is a collection of things: what user authorized it, what agent binary was used to give birth to the agent session, what services are being authorized, and what machine is this all taking place from. That is the collective identity that must be present for that agent session, and all of it needs to be device-bound.

So if I were to copy it off, I can't just assume the identity or pretext everything I just described. It has to have that copy-resistance capability, that device-boundary capability. We think that is really what's necessary for agentic identity. Because if you're not doing that, you're basically setting yourself up for all the holes and Swiss cheese of the old world, but now being emulated at the speed of how fast an agent can run.

John Richards It's kind of like going from a 2D plane of identity to a three-dimensional space now where there are all these other attributes that come in. How does having that information empower folks as they try to get a handle on what is okay and what isn't in their network? What are the policies you're seeing come out of this that are enabled because you can now have such granular control or understanding of what's going on? Jasson Casey You want your developers to be using agents.

You want them to be able to use not just the standard Git commands with their agent, but the GH commands if they're using GitHub. You want them to be able to use additional DevOps CI/CD things with their agents. But that joke I started with earlier - "Hey, I violated all my principles and yeah, I did delete that thing" - that's funny because it didn't happen to us, but it did happen to somebody. There are less catastrophic versions of that scenario that are still equally painful.

So how do you prevent that from happening to you? The answer is these fine-grained controls that you need to be able to set. This rubric I keep coming back to keeps generally proving useful: the more you start to think about an agent as an employee - what would you do for that employee, how would you set controls and availability for that employee, how would you check up on that employee - that almost always gives the right mental framework for managing whether it's how to use AI more effectively or how to set security controls that are empowering and not prohibitive.

John Richards That's fascinating. I feel like I needed to sit with some tea and think about the ramifications, because it really does change how I'm thinking about these agents. It also adds - I tend to think of throwing AI out there as kind of a free action, something you don't have to think too much about. But realizing that each one of these takes some effort and some thought, it's not just put it out there and hope it all works together.

Being intentional in that first step is really going to pay dividends down the road. What are some of the policies you see? Do you have a base set of policies you recommend, or is that more conversational? Jasson Casey It's definitely conversational, and it really depends on where the customer is in their journey.

We had one person come to us recently who had about a thousand different policy rules they were actively managing through Anthropic's management interface. A policy rule could be something like a permission rule you're pushing, or an MCP configuration you're pushing. The way this individual was trying to set their controls was, number one, an admin nightmare for them - they were literally going to have to hire people just to help manage it. Number two, it only covered Claude Code.

It did not cover other agents being used in their environment. The thing we actually did with them first was trying to understand the intent of all these rules they were trying to manage, firstly within Anthropic and Claude Code. A lot of the rules really fell into: how do I ensure my developers are using MCP tools that have passed third-party risk, that aren't going to put me in violation of existing customer contracts - as opposed to something they found that's cool but isn't necessarily vetted?

Number two, developers - if I'm making a joke, I'll say developers are lazy; if it's a more serious context, I'll say you don't really want to push your developers to all have to establish some configuration just to be useful. You want to put them in a high-productive environment. You want to make sure they have the best tools, that they're going to start with some Claude memory that shapes and steers the behavior of the system. These were all examples of policy rules, and they were trying to set them in a generic way that would impact all of their developers.

We were able to walk them through what that would look like in our system, where it's not just Anthropic-specific, but could apply across all agents. The thing we learned in that engagement was: you're not just delivering a policy engine that can execute on these rules in a fine-grained way, you're also delivering an operations agent to your customer, because they do need an assistant to operate. You can use AI not just to build code or build things - you can use AI to operate things.

We had the idea, but they gave us the reason to accelerate. And so it's in the product now, but we have this thing called Ceros Agent, where you just interact with it in a human style to hammer out the policy you want. You could literally give it a copy of what you've scripted out already for an Anthropic-style config, and it will help you turn that into a Ceros-style, agent-agnostic config. John Richards That's so cool.

I also want to highlight something you said there, because in the security space it can feel to outsiders like this is the team that keeps me from being productive sometimes, or the barriers I have to get around. But you were highlighting here that some of these same policies are actually ways to increase productivity across the organization - giving teams a better starting base they might not know about, ensuring the tools they're using are just right. What drove this quarter's productivity in your organization?

"The way we implemented our AI policies." That's not where you would expect to hear that, but it could absolutely be the case. Standardizing on these things, and making sure especially the newer folks coming in are starting in an environment that's primed for learning - I find that fascinating and a very exciting side value. Of course we have to lock this stuff down, but by providing this environment - to your analogy of a person in training: there are things they can't eat, okay yes, but you're also making sure the things they are getting are optimized for their performance.

Love it. Thank you for sharing that. This has been fascinating. Ceros - amazing.

Our audience should definitely check this out. For somebody out there going through an agentic transformation, what would you say about why they should go check out Ceros right now? Jasson Casey Ceros right now: unlike most security companies, we actually provide a PLG, or product-led growth, style onramp. You can go to ceros.

sh and create a tenant and try it out. There's no barrier to seeing it in action. We're happy to jump on a Zoom and give you the white-glove experience if you think this can make a meaningful impact in your business. We felt strongly that we wanted to lower the barrier and make it easy to try, which historically hasn't really been a feature of security products - it's been more of a feature of IT products.

This is the second thing where we actually believe IT and security products really ought to just become the same thing, because it's not just about protecting people, it's about enabling people to run faster. Productivity and security. It's not one at the expense of the other. So try it out now.

The only other general advice I would say is: the most useful analogy I can give anyone in thinking about how to actually interact with the agent better, how to set an environment for the agent to operate, how to talk to your team about running their AI transformation - is think of these agents as employees. If you haven't done anything, think of them as an employee or intern. They're going to be full of energy and they're going to be whip-smart and they're going to do 16 things wrong faster than you can catch up.

As you shape them and tune them, they literally mature and they get better. And just like employees, they work better in teams. They work better where you give opposing objectives to different people and let them work against each other. Iron sharpens iron.

Agents sharpen agents. Think of them like employees - that will probably put you in the best mindset to really figure this out. John Richards Well, thank you again, Jasson. For our audience, definitely check out Ceros.

If you took nothing else away from this, I think the mindset of thinking of these agents as employees, and the value of security and productivity being together - not seeing them as secondary things - those are huge takeaways I'm taking out of this that I think are incredibly meaningful. Thank you for highlighting those and sharing so much of the journey you've all been through. It's been an absolute pleasure. Thank you, Jasson.

Jasson Casey Thank you. John Richards This podcast is made possible by CyberProof, a leading co-managed security services provider, helping organizations manage cyber risk through advanced threat intelligence, exposure management, and cloud security. From proactive threat hunting to managed detection and response, CyberProof helps enterprises reduce risk, improve resilience, and stay ahead of emerging threats. Learn more at CyberProof.

com. Thank you for tuning in to Cyber Sentries. I'm your host, John Richards. This has been a production of TruStory FM.

Audio engineering by Andy Nelson. Music by Amit Sagie. You can find all the links in the show notes. We appreciate you downloading and listening to this show.

Take a moment and leave a like and a review - it helps us get the word out. We'll be back July 1st right here on Cyber Sentries.