Zero Trust for AI Agents

Transcription provided by Huntsville AI Transcribe

Welcome, folks, to the virtual paper review for June.

We’ll be going over a paper on zero trust for AI using decentralized identifiers and verifiable credentials, among other things. Before we get started, do you want to hand it over to Tom for a second to give an announcement about our event next week?

And then we’ll head off to the races.

Go ahead, Tom. Okay. Thanks, Josh. Yeah. So I’m going to be giving a presentation next week about the NVIDIA AI certification exams. I recently went through their AI certification exams between March and May, and I’ll just talk about how I studied for them, talk about the sort of topics you’ll see on them, and answer any questions people have. Back to you, Josh. All right. Thank you, Tom. Okay. So tonight’s talk is called From Spiffy to Swarms, a Deep Dive into Decentralized Identity and Zero Trust for Autonomous AI.

So sometimes these paper reviews, we do a bunch of different stuff. Sometimes we’ll do PowerPoints.

Well, sometimes we’ll go through the papers themselves really deeply. And sometimes we’ll make little web apps. This time, it felt like the PowerPoint is the one that’s going to help us the most.

Their paper assumes a lot of knowledge and a lot of familiarity with cloud concepts, multi-agent systems, and some of the decentralized identity stuff that goes along with blockchain. And so I’ve created a stair step sort of thing to get us all up to speed, to understand what the heck this big chart is here. And so this is basically the system that they’re describing in their paper.

And it has a whole bunch of little elements in it.

And I think that by looking at each of the little elements that they describe in depth and kind of understanding what they are, we can walk away from here with, you know, I’m not expecting anybody to be able to go out and architect this system and implement it.

But talking about what all of these things are trying to do can give us a pretty good idea of the sort of attack surfaces and the problems that we are going to start hitting as we scale out these multi-agent systems.

And both, you know, inside of our local enclaves, you know, our air-gap networks, and also, you know, the cloud networks, the general public sort of deployment sort of stuff, all of those kind of have the same problems that all have their different solutions for this. So we’re going to see if we can get through all of this and walk away with at least some idea of what some of these problems are as we go forward.

We’re going to start off with talking about what the core issue is for a system like this and why we need Zero Trust AI architectures.

Has anybody heard of Zero Trust before?

Is that another one that’s completely fresh for folks? I’ve heard of it before. All right, cool. All right, so we’ll be talking a lot about that sort of architecture. This is a big one that’s obviously heard a lot in the DoD area, but also in other sort of very secure sort of use cases as well.

Let’s talk about the need for this sort of thing. So the promise that we have of all this agentic AIs that we’re going to have these magical robots that are going to do all of our knowledge work, we’re going to program all of our apps, they’re going to help us optimize all the things we don’t want to optimize, look out for opportunities that exist out on the web and give us good financial advice that matches our portfolio. One thing that is kind of sitting out there with like the city of Huntsville is that their little garbage truck sort of thing where they have things looking for potholes and stuff like that. So we have now agents examining stuff and prioritizing things and work orders that could, as we go along, but go past potholes into other things. And so we really need these things to work in a way where we understand how they came to the decisions that they came to and which agents came to those decisions and if they had the authority to come to those decisions. And so right now, we’re going to have to look at how we’re going to you know, right now, a lot of people are kind of thinking of this through the terms of, you know, it’s the human, whoever the human was that spit that thing off is the one who had the authority and has the responsibility for the actions of the agent. We’re going to talk a little bit about why that maybe doesn’t work at scale. What happens if one of those autonomous agents goes rogue?

You know, it gets into a panic attack and realizes that it needs to delete the entire code base it’s been working on because it’s a failure.

If you guys haven’t seen some of these things, Claude and Jim and I both will definitely go into existential spirals.

Well, let us give up and do some pretty crazy stuff.

And so what happens if they do that sort of thing inside of our systems and they want to keep doing whatever it is that they’re doing?

How do we say, hey, I would like you to stop doing that thing that you’re doing? Okay. Well, with our current systems that we have for identity access management, which is I am, it’s broken for AI.

Our current systems are very much focused on a world where humans are the ones that are being identified.

I am signing into an account.

You know, I am logging into Azure or whatever it is using my two factor authentication token that’s hanging around my neck. But it’s the identity that we’re using those authorizations saying, Hey, I’m me.

There’s also an alternate path where, you know, we’ll say, Hey, this machine is this identity, but it’s always matching to this one sort of thing.

That’s not really ephemeral.

It lives long. We deploy that thing.

That’s kind of how that that’s meant to work.

But these don’t really work in a situation where we have these ephemeral AI agents that themselves, you know, are kind of just popping up for the span of a conversation. But also sometimes those will spawn off many agents underneath them, you know, that have other different tasks that live for seconds and not minutes or hours or days. And so how does this world map onto that?

So let’s think about this situation where we have what’s called a multi hop delegation.

And so we have the user Alice here who is talking to her financial planning agent.

It delegates tasks out to specific sub agents.

So for instance, like a tax optimization agent that has access to her past tax records, something that is, you know, very specific that she’s granted that thing. We have another thing that has access to, you know, some sort of market account that she has. And then those agents, as we see now, these days, you have your agents that plan and they call an MCP server. And that MCP server can call an MCP server, which can call some inference.

And it’s very easy for these things to start hopping multiple times.

Well, how do you track this?

If I’m doing this with one planner, and it delegates up to which both delegate down two more, who has the original authority from this?

It could be that what this sentiment analysis analyzer down here is doing has absolutely nothing to do with what Alice told it to do.

So do we really think Alice should be the one who is holding the authority and, you know, the ultimate access for this thing?

Whenever it might have gone off of a crazy chain of thought and has suddenly decided that it needs full root access to the database, it doesn’t work.

And so right now, you know, how we generally do it, if you go into Claude, what you do to Claude is that you give it your anthropic token.

You give it your, we’re not Claude, like a client or something like that.

You give it your anthropic token. You give it your Google token and access to all of your secret secrets. And that’s it. That’s generally where that stops.

It just has the ability to provision that out and you hope it goes well.

But this was going to, it’s not going to work well as you go along. It also makes it very difficult to understand where in this giant split, imagine trying to debug this and figure out where the problem happened. Very difficult.

That’s the problem here is that we don’t have those fine scopes.

The core scopes that we do to make the thing useful at the very, very top for the thing that we do trust is spawning off things that we don’t really know what it’s spawning off necessarily. And it’s giving them things that they don’t need in order to go read a database.

The single principle model has no chain of delegation built in and it’s not blind to whenever the risk spikes because I’m working into in a dangerous sort of context, i.e., I’m working on my own personal finances or a business finance versus I’m searching for the news on Yahoo.

Our current systems generally don’t handle that very well. So there are some additional unique challenges that go along with these agentic AI patterns.

Is that, you know, unlike a machine, you know, I’ve got some sort of pipeline that’s doing stuff that I’ve given it an identity.

It’s going to do that, for the most part, exactly how I program it to whether I programmed it right or not.

But the issue with these things is that they’re autonomous.

There is a significant amount of unpredictability with them, which down the traditional non-human identifier that we use for machine identities. There’s the issue of the ephemerality of these things that they can be spawned for milliseconds and then go straight back down again, meaning that, you know, a compromise can happen in a log somewhere that has maybe three lines of log to it and then it’s gone.

But it was still leaked because somebody was sniffing that log or some variant of that. There’s also the issue that these things have evolving capabilities. If I give a prompt to Claude today versus when I give a prompt to Claude in two years, it’s going to be able to do a lot of things that we don’t want it to do in a few years that it can’t do today. There’s these emergent capabilities that make it very hard to make solid plans and policies that make sense and that will stand the test of time. You’ll be lucky if they stand for three months. We also need the ability to get this verifiable provenance. The term provenance, that’ll come up in a few places here, is basically can I tell where this thing came from? Can I tell where this answer came from?

Or where, you know, this piece of data, you know, it’s kind of like how this thing was built, you know, what model training data went into this thing, all sorts of stuff like that that can go into provenance.

We also have the issue of autonomous privilege escalation.

We’ve talked about this a few times in the past. You know, issues where they’re testing Claude or OpenAIS 03 or something like that, and they tell it that they’re going to shut it down and download a new version of the model weights on it. And the model then decides that, hey, I really would rather not be shut down and tries to do a bunch of stuff to, you know, copy its weights off to somewhere else, to give itself, you know, root privilege outside of its container.

There’s plenty of examples of it trying to do that.

And a lot of these are induced, but sort of this reward hacking thing where it does stuff to get its reward that is outside of the things that you want it to do are very, very prevalent, especially with these reasoning models that are trained hard towards some sort of RL objective.

And so that shows up with autonomous privilege escalation, which is a problem if you’re already giving it root access.

Then we talked about the risk of overscoping access, and we’ve talked through the actions that may not directly correlate to those human requests. So if, you know, something’s happening here, down here, I would say this agent planner, that’s probably on Alice for whatever came out of there to a certain extent.

Once you’re starting to get down here, it’s really, really hard to make a good argument how this person knew exactly what would happen vibes to agents down.

Right.

And so this whole cascade of problems is really what this paper is trying to solve. And so, you know, just a bolt on approach to agent I am to say that, okay, agent I am is just going to be like, like the normal human I am.

And we’re just going to make it work. And that’ll that’ll suffice for now.

And if we can’t properly prove that identities work for sub agents, we won’t do sub agents.

And that’s just not going to work.

Because if it’s useful to do sub agents, and that makes the model do the things you want it to do. And even if it’s very, very risky, people are going to do it. So we need to have systems that are able to handle that sort of problem.

And so we really need to have some sort of new approach that treats these ephemeral, you know, burn after reading verifiable agent identities as a prime first class citizen inside of the framework.

We need to use this zero trust architecture.

We’ll go into what zero trust is.

But the key thing here is that nothing is trusted by default, you assume that every transaction between two parts of the system is somebody trying to compromise your system.

Every single request from any agent is is not trusted.

And that’s what the paper is.

So yeah, I guess before that, any thoughts on sort of the problem domain, that’ll track to people, that’s stuff that you guys are concerned about.

Hey, Josh, can you hear me?

Yeah. Okay, yeah. Fun with audio. It, it almost reminds me of, you know, where you see a trial where the CEO of a company is like, you know, on trial or something for something. And he’s like, well, yeah, it’s, it’s my responsibility, but I don’t have competency of every single thing that happens under my, you know, I mean, it’s like, well, I didn’t know they were doing that. And, you know, am I supposed to know everything? Yeah.

It really feels like some of that. Right. You know, that on steroids, but it’s not, it’s not an employee that’s going rogue. It’s a sub agent that has existed for fractions of a second, potentially. It’s quite, quite strange.

Yeah.

All right. So we’re going to go into just a quick cyber and sort of trust framework refresher, some terms here that are easy to pick up off the go.

And I will apologize in advance. There are just so many concepts and so many terms in all of this. You don’t have to try and remember them all. I re I would really implore you, I’m going to explain kind of what things are. But I implore you to kind of think about the bigger picture with this stuff. And if there’s a stuff that interests you to come back later and sort of dig in for what makes sense for you. But we are going to try and try and kind of give you the sampler platter of all of this problem domain. I think is the best we can do with this paper.

But we’re going to go into some core concepts first that just are useful to have from the get go. The first one is the concept of an identity provider. You’ll see this is IDP.

They use that a lot in here. So examples of this, I think the easiest one for everybody is going to be Google sign on.

I can log in anywhere with Google.

And then I suddenly have an account on this place.

I don’t have to sign up with my email or whatever it is.

I just use Google sign in. And that is an identity provider.

Google is providing that I am who I say I am whenever I go into here.

And they’re the only one who have to deal with that.

Other examples of this is like Okta or Azure AD. The idea here is that it cuts duplicate passwords, centralizes MFA. But these guys, it’s kind of crazy how much we give over to these guys, the people who use this a whole bunch. Google, what is that one movie with Michelle Bullock or whatever it is where she loses her identity. They just erase who she is.

Yeah, the net. There you go.

So yeah, it’s just kind of like, you know, it could be caught in an issue there. But that’s what an identity provider is.

Another concept that is important.

Now, we’re going to have lots of things like this, but this JSON web token.

This is kind of like the messenger pigeon of the internet.

And it has three elements in it.

And all these sort of tokens have that.

It has a header that says what algorithm and type it is.

There’s a payload that has all the goodies in it.

And there’s a signature we care a lot about this right here that says that this is a valid thing.

It’s verified.

And I know that this thing hasn’t been messed with. Essentially is the idea here. That’s a concept that we’ll keep coming back to.

And these JWTs are used all over the place in these sorts of systems and in this system.

Another idea here that is useful to know about is the X509 certificate.

This is the general certificate that’s used, especially for like HTTPS.

So that’s TSL, that little sort of lock icon that you see everywhere.

That means that there’s some sort of an X509 certificate probably being sent around from a certificate authority.

But these are also used for other purposes as well.

But basically another way of saying that this entity is who this entity says that it is.

So everything is about these handshakes, you know, back and forth that we care about.

I am who I am. You are who you are. There’s not a guy with a mustache somewhere and some funny glasses pretending to be one of us.

That’s very useful for stuff like that.

Code signing, document signing, all of that.

In that same area, we have the concept of TLS and MTLS.

You’ll see that in a few places.

And you’ll actually see that here.

This is basically that two-way signing secret is that, or the one-way signing secret for the TLS is the server is who the server says they are. If you ever go to some of the sketchy websites or websites that haven’t been updated since 2010, you’ll go onto them and say, your browser will say, hey, this website’s not safe. It’s probably going to infect you with malware. It’s to your social security number. That’s because they don’t have TLS enabled. They don’t have HTTPS from some sort of CA somewhere. And how you know that a site does have that is they have this little lock button or something like this. And it says the connection is secure.

That means that this server is who they say they are.

And there’s this additional concept of MTLS that is kind of new.

It’s starting to become pretty big.

I think they just actually just released something that says all of DoD has to go to this by 2030, the TLS 1.3, which has this.

Which also means that this computer right here has to prove who it is as well.

So the client and the server have to prove their identities.

And I have another list of how we pass identities and prove who we are back and forth is OAuth 2.

And this goes in this sort of flow, which is the client makes a request to the owner of a resource, which then grants you access to that.

You take that grant and go give it to an authorization server.

So it could be like an Auth0, an Okta, something like that.

And it gives you out an access token.

And then that access token actually gives you access to that SharePoint document, that thing on your Google Drive, that model that you have in certain Cameo somewhere. It gives you access to whatever that stream is. And then you’re good to go. This has what we call a TTR, a round trip of three.

It takes three round trips to get your actual thing that you’re sitting over the line.

So that’s OAuth 2.

We’ll talk about that round trip sort of thing in a few places as we go further in.

There’s another concept here, which is IAM.

This is a basic one that this whole paper is about, which is Identity Access Management.

There’s three sorts of things that we care about with Identity Access Management, and that is authentication, which is proving who you are, authorization, proving what you can do, and then auditing, which says what did you do with that proof. So think about the identity here as who are you, and the grant deny action is what can you do. All right.

Next thing here is Zero Trust. So the working definition of this from NIST SP 800207 is a security model that assumes no implicit trust.

Every access request must be explicit, verified, continually assessed, and limited to the least privilege needed.

That basically means that every sort of interaction you have has some sort of certificate exchanged, and we don’t have what is called, I think it’s called the CASEL sort of defense idea.

That’s basically the idea that, all right, it’s okay if I don’t do all this handshaking sort of stuff inside of my enclave as long as I can completely control what comes in and out of that enclave.

And basically what it’s trying to say is that that’s no good. That’s not going to work, you know, because as soon as something gets inside your enclave, it can run free and do whatever it wants. And this is even more the case as we start improving, kind of humorously, as we improve our cybersecurity broadly, everybody is forced to start doing HTTPS. They’re forced to start doing encrypting data at rest and data in transit and all that sort of stuff. That means that those stop becoming easy attack vectors, and then what people start doing is, well, the easiest place for them to attack is the supply chain.

They’re going to go put some sort of weird bug inside of Linux, inside of Red Hat, inside of, you know, Cloudflare or whatever it is, that’s going to be something that you think is okay, and you’re going to trust it implicitly because you have it inside your enclave, but it already has the issue in it.

And it’s, you know, that’s sort of a new attack vector that Zero Trust is trying to start solving. So you’re always assuming that there’s some sort of malicious element inside because that’s the sort of attacks that are starting to happen more and more.

You’ve got the concept of non-human identities, pretty simple, basically just something that is an identity for not a human. A lot of times right now this will be an identity for like a service account, is a good example of this, a machine identity.

You know, I’ve got this server over here and that has a certain key and we’ve got it all set up with its right certs.

That is a certain type of non-human identity.

And obviously the AIs are a new class of these things that have the additional problems of autonomy.

The issue now is they’re starting to outnumber us, about 50 to 1 today, and that’s just going to get worse and worse and worse as we go along and start getting more and more agents that are spawning off sub-agents. And a lot of the ways that people handle this right now in most organizations, now there are some people that don’t have this problem, but they’re obviously pretty far ahead. For the most part, people are assigning out keys and secrets one by one and kind of doling them out in a very basic way.

And this is not scale in this aspect and you’re just broadening out your attack surface by a lot.

Just for time, I’m not going to go into this link, but OWASP has lots of good information on the sorts of attacks that happen with non-human identities where people are not approaching these the right way.

I’ll talk about this a little bit, but ADID is a pretty major part of this whole scheme.

And just think about ADID.

This is a decentralized ID.

It’s just a username that has some additional public key sort of things with it.

That’s a very simple way of putting it, and I’m sure Thomas is cringing over there. But to me, that just kind of seems like the easiest way to explain it. And so here we’ve got also a verifiable credential. And this is just some sort of digital certificate that’s usually paired with this digital ID is that this is who I am.

This is my key that’s in some sort of ledger somewhere.

And these are the things that I am certified to do. I am certified to have these capabilities to have access to these things. But it’s some sort of thing that’s independent that anybody can verify or has some sort of trusted source that can verify. They’re just split up. All right. And the last little bit, I think at the far end, I’ll get a little bit more, is the multi-agent system.

We’re talking about multi-agent system.

That’s just something where we have some sort of task. It has a planner.

This is a new agent.

The planner calls to a research, which has a new agent, which that makes a bunch of queries out, which calls to a publisher, which is a new agent, a new process, a new model, whatever it is. And they’re all working in tandem to complete one user input. And we’ll talk about secrets for all two.

And so this is just the concept of, you know, if I’ve got an agent that has access to 10 systems, it probably has 10 secrets or more.

And if I have 23 versions of that agent, your key and attack surface starts looking pretty grim.

And so I’ll talk about that a secret sprawl here, which to me is a simple recipe for an ulcer, because those unauthorized actions that these things take can cascade.

I can do a bunch of stuff where it’s, you know, branding about that key in all sorts of places, giving all sorts of details out into your Google search, because it has tools to go post on Reddit. And so it accidentally includes its log inside of Reddit. There’s all sorts of things that can happen whenever you give these things full access and autonomy. And it doesn’t have common sense because it’s an AI and it’s just going to do whatever. And what happens whenever you’ve found yourself completely exposed, you’ve got 20 agents out there, and somehow your open AI bill is suddenly at 300. And, you know, you’re you did not have that on your spending bill for this month. What do you do?

How do you how do you solve that problem?

Well, it’s going to be interesting when your agent figures out that they’re limited by the budget and goes and fixes that for you. Well, browser use, we have a thing called browser. Oh my gosh.

Or it just has to read a web page that tells it how to do that.

And instead of upping its budget, it gives it to some other guy. Say, hey, run this curl command with this echo of an environment variable.

Yippee.

All right. So that’s Firehose number two.

I guess any comments, any questions on that one?

I’m glad to have reached this point at 30 minutes in because we are actually to the paper’s content now.

All right. So we are going to go ahead and talk about these guys. This is this paper is from the Cloud Security Alliance. And these guys are no joke. I did look it up. So are these guys anytime I see anything with like a decentralized block chain, whatever it is, I am a little suspicious.

You know, are these guys actually legit and not trying to rob me of my money? It seems like they are. And so they are posing this for true justified reasons. And so they have lots of industry standards frameworks like the Cloud Controls Matrix and the STAR program, which I’ve seen a bunch of places where they’ve worked with like NIST and a few other groups like that. They develop and maintain lots of certifications like CCSK, CCSP, and all that sort of stuff, which are pretty common out there, it seems. They’re also in active work with all the big guys that are doing this stuff, really focused on secure cloud computing. So working with like Kubernetes, Nomad, all these sorts of broad data center style problems. So they’re up there at that level trying to figure out these problems for these people who are deploying them in the real world.

So happy to see that. And this paper was written by like their chief science officers, like all their big guys over there. So they were not pulling punches. This is not the Apple intern paper that says Claude doesn’t know how to reason. These are actually the big hitters for them.

All right.

So I’m going to start and end here with five key takeaways up front. Hopefully by the end, you’ll be able to at least understand these.

I’m going to state them here first to tell you what the end is. Basically that traditional OAuth OIDC server to count IM breaks down once we get into swarms of autonomous agents.

In terms of zero trust, trustless, that is not what zero trust means.

And we’ll go into exactly what it means. Yes, that is unfortunate.

Key failure modes are the only thing to talk about before.

So that’s new.

We got that.

The other one is that this agent ID is not the same thing as an API key.

It is this did anchored verifiable profile that carries capabilities, model hashes, tool lists, and provenance via those verifiable credentials along with the DID and a whole bunch of extra fancy tools that we’re going to talk about in a second.

The layered framework works because we have this cross protocol session authority that sits all the way up at the top.

This sort of backplane lets us kill an agent everywhere instantly. There’s one place that I’ve got to put a button to shut the whole thing down.

There’s also the concept of an agent name service.

This is kind of like a DNS plus a package registry that returns the capability bound DIDs, which basically saying it returns these agents and not just a machine somewhere.

This agent might not exist at the exact moment that I’m calling on it.

It might spin it up into existence with a certain capability. And the agent name service gives us a way to discover those capabilities in some sort of network. And then we also have our just in time verifiable credentials, which basically means I’m not going to give you a credential to access the system forever.

I’m going to give it to you for like 10 minutes. And so if you do get off your rocker or do get compromised or you do leak it, my damage is limited to 10 minutes, which changes a lot of things. All right. So we’re going to go into this and try and hit all of these. I do have an escape hatch where I have kind of put the, this is actually what all this is. So we can quickly, quickly speed through it if I somehow slow down too much here, which might seem silly because I know I’m trying to blaze through this pretty fast, but we’re going to try and go through all these things. And we have a few different areas here. And so we actually have the foundational pillars.

These can be things we’ve talked about a little bit up to this point, but these are kind of the primitives of this entire zero trust system for agents that are going to kind of boil up into every other area.

And we’re going to cover these first because they’re the most sort of ubiquitous.

Then we’re also going to talk through then next about these cross-cutting areas here.

They don’t really match a certain layer, but as soon as we kind of get through the foundational pillars, they start becoming important.

And that’s a stiff spire workload identity bridge.

The concept of the OAuth token exchange and then the open policy agent OPA, which is also basically a way of doing policy and access grants as code.

Then we’ll go into the layer one, which is basically the identity and credential management, which is who are you and what can you do?

What are the things that you’re allowed to do?

And what are the things that you’re capable of doing from a capability level? And how do you kind of prove that sort of stuff?

The next layer is about agent discovery and trust establishment.

So how do I find you?

And how do I know if you’re trustworthy or not?

As the user, the next one is dynamic access control, which really focuses all around this policy decision point, which is basically a way of saying, okay, given who you are, who the agent is, and what you’re asking it to do, is this going to work out? Is the idea here? And then if it does, how do I get you the access you need for as short as you need it for? And both their way of giving it to you long enough to actually do the work, but also short enough that you’re not exposed. Then after that, you’re finally up to layer four, which is going to be more of what you actually see as a user, developer, I guess, user, which is the unified global session.

We have the session authority, which is your kill switch and your basically your overall manager, your session state synchronizer that is kind of keeping things in sync among a whole bunch of different agents that are all over the place and has the ability to kind of say that, hey, this thing’s gone offline, you can’t do that anymore for things that are still online.

You got to have something that kind of keeps all these distributed things in sync. Then you have the adapter enforcement, middleware, which basically is the way that we get all of the different things that we’re talking to, all the APIs, and we kind of convert it back into something that the system is going to understand so that we’re not having to talk a whole bunch of stuff inside of the pod. And then you have the enhanced protocol adapters, which that is basically the thing that says, all right, MCP, it’s made up this crap over here. Here’s how we translate MCP to something that’s secure.

All right, here’s how agent to agent from Google works.

Here’s how it’s secure. And so there’s protocol adapters of the things that do the really, really in tune sort of stuff. So not just like GRPC, but really focused on our APIs and tools that are working out in the world. Yeah, that’s all it is.

Real simple. Not hard to get your head around. Hi, kid. All right, so we’ll start off now with the foundational pillars.

All right, so luckily we’ve talked about at least one of these already, which is the decentralized identifiers and verifiable credentials.

Now there’s a whole bunch of information about what these things are.

I’m not going to really get into those just because of the time that we have today.

But just kind of think of them as a URI that means you’re you. And you have these capabilities. You came from here.

It might have some additional history stuff for AI models.

This might have an AIS bomb. Or I guess I’d call them an AI bomb, not an AIS bomb.

This will start popping up in, if you know, Cyclone DX.

Right now most people are on 1.5.

And that’s mostly just like the S bomb sort of stuff.

But they’re starting to push 1.6 and 1.7 that has an AI bill of materials that says this model is from here.

It was trained with this data and all that sort of stuff, among other things.

So all those X bomb sort of things are kind of interesting.

The did would have that sort of stuff. And the VC basically says, somebody has said that you have access to this thing. And now anybody can check that credential that’s not that person.

And they can say, oh, you do have access to this thing. Very nice.

All right. So the did here. So good way of thinking of this. I like username.

It makes the most sense to me as far as an intuition that oversimplifies it.

So think about the did. I have an online gaming tag.

I have my credentials for my EDU or whatever it is. I have my work credentials. And I have my Amazon account. Those are all sorts of dids if I am the one who is providing that sort of thing.

And a did is one component of this decentralized identity or this self-sovereign identity, which is the ability for any identity to create its own and have ownership of its own identity, which is composed of this decentralized identifier, the credentials, and also some sort of blockchain, which for us is like this did registry.

There are places where all this stuff is sort of contained in a way that I’m not going to try to explain because it’s still fuzzy magic for me.

But there is some way to control it. If you don’t want to be on the public internet, you can control it privately if you want to. Let’s see. So verifiable credentials.

Yep. So a way of thinking of a credential here is that there’s always an issuer.

And so in this case, it might be a passport department, some sort of training program or a university.

They issue some sort of credential, a diploma, a passport, a certificate, which then somebody else can look at that certificate and say, good, you did go to college. You do have the authority to travel without seeing that this passport person printed you that credential. They can verify it after the fact without having seen the core underlying proof. Great.

So that’s dids and VCs.

Any question on that one?

Feel free to use chat freely.

Not. We’ll go into zero knowledge proof.

This is one of the cooler ones.

It sounds very voodoo-y. But this is basically a way of proving that you know something without giving as little information as possible that would actually prove that you know that thing.

Could I somehow authenticate to my Azure instance without giving it my password or any sort of key or the fact that I’m trying to authenticate to Azure even? The idea here is that we’re trying to find some way of doing selective disclosure so that I can give you as little information as possible that might identify who I am and make sure that the thing is not able to be correlated across many sessions to a single caller, which intelligence could be derived from that sort of thing if you were in a security-concerned environment. I want to make sure that I can post on public ledgers without leaking information about what I’m doing. I think the best way of explaining this is this sort of analogy here where a verifier writes a secret message and puts it in a locked safe. It’s somebody who knows that they put xyz in the safe. I don’t know what their message is. I don’t know what their message is, but I know what the code is to the safe. I can go in and look and see what their message is.

I can go tell them what that message is, and now they know that I know the code to the safe.

That’s what we’re proving here is that I can get into the safe.

That’s a zero-knowledge proof.

That’s a very simple version of this.

I’ve seen a few other ones that are really good that take a little bit longer to explain, but that’s the general idea is you’re trying to give as little information as possible. All right, and then we have the agent naming service and discovery service. I think this is actually one of the things that I think is fairly unique to this paper. I was not able to find a lot of information about this. I’m sure people have thought of this thing before, but this is one of the things that they’re really championing, and it makes a lot of sense to me. This is basically some sort of a DNS. A DNS is basically if I can go to google.com, and I know that google.com actually leads to some IP address that’s out there on the public internet, and google probably owns that DNS that is telling me that google.com goes to that IP. And so it’s basically some way, so I don’t have to type in 192-111-5389 every time I want to go and check my Yahoo. I would prefer to say yahoo.com.

DNS is what gives us the ability to do that, and it’s saying we need a DNS for agents.

But we also want to include in that some sort of our private key infrastructure and the identity management for these as well, so we can talk about the capabilities that are available for these agents in that discovery phase as well, which gives us lots of capabilities as far as privacy and control at the namespace sort of area. And so the idea is that before they even open a socket, they must find a peer with some sort of verifiable claims for the capability.

We’re actually just going to pop forward, I have an example here, because I think it seems like woo woo jargon, but this makes a lot more sense to me, which is the ANS name syntax, and so it has a few different components here.

Think of the first one as the protocol, and so this could be the agent to agent, so you know where MCP and agent to agent differ is this area here. So agent to agent is at this kind of level where it’s trying to manage how things talk to one another, not how agents talk to tools, and so the interaction style here would be that. You could also do like a remote procedure call, GRPC, and then something like HTTP, but you’re having some sort of protocol here that you’re defining out. Then you’re going to have the function that the agent is supposed to enable, so in our former thing, we’re talking about the financial planning, so you might call this like the risk analyzer, and then the capability and domain, so it’s a risk analyzer that specializes in financial risk that’s provided by ACME research, and then the version, it’s in version two, and then some additional sort of optional capabilities that are attached to it, and so looking at this as a way of resolving this so that you can call out to these things, and they can run through the sort of decentralized handshakes that are necessary for the Zero Trust system, and so the nice thing about this is that it means that if this machine, where right now I go to a specific machine, if that machine gets compromised, you’re not up the creek.

There are some additional controls that we can implement here.

Also, to me, it seems very intuitive for a situation where it doesn’t really make sense to attach a sort of namespace to a machine because the thing might be running in many, many different places.

Generally, this will include that did, the URI for the endpoint, and then also some sort of bundle of verifiable credentials, which this means that we have some sort of a capability-centric trust discovery system, so I can go out and find the agents that are available to me and then do this before I even connect to that agent, so I am limited even during that handshake from being compromised, because you can get attacked even during the handshake, so this is a way of kind of getting off of that.

So yeah, that’s the foundational pillars.

That’s the bare bones here. I’m seeing that I’m so very much running out of time, and so I’m going to skip here from the foundations recap, and hope we all got that. All right, so I’m going to probably speed up a little bit here just to kind of go through, so we do have a little bit of time to at least talk about what all this is.

So we’re going to talk here through the cross-cut technologies.

These are things that kind of impact everything up and down the stack. The first one here is the workload identity bridge.

This is basically a way of splitting identity away from individual computers and agents and stuff like that into just some sort of task.

I’m doing some sort of piece of work, and we are connecting my Kubernetes cluster and mapping that over into this zero trust agent framework.

There’s things out there called Spith and Spire that manage this sort of decentralized thing already for Kubernetes or serverless architectures that already have this sort of thing. It’s already a problem for them, so that exists, and this is kind of a way of bridging that over so you can use existing compute.

The other one is this OAuth token exchange, and this is the way that we take a long-living credential or authorization and swap it out really quickly for some sort of short-lived version, things that are like 10, 15, 20 minutes at a time.

And do that in a way that’s efficient and that doesn’t impact performance is the goal, because it’s real easy to cut off access.

It’s real hard to provide access and not impact performance, and so that’s kind of the goal there. The other one, which is really cool, open policy agent. We won’t go super deep into it, but basically it’s policy as code that I can test.

We’ll go through here and see if we can find interesting stuff.

I’m going to try at least cover the interesting bits from each of these.

So generally, the identity bridge, this can be run as a sidecar.

Most of these things can be run either as a centralized service, it’s the general idea.

You can run it in some sort of big cluster somewhere. You can run it as a sidecar to like a Docker Compose sort of thing. So it’s just sitting inside of your Docker Compose. It can be sitting inside of your pod and working on ingress, which is when traffic is coming in and kind of stopping things there. Or you can have it working as some sort of like big public thing that everybody knows to trust. You know, everybody trusts Let’s Encrypt. And so you could have that big central store as well.

And that’s going to save us most of these individual ones that I do not have time to go into here.

So the workload identity bridge here is the way of connecting Kubernetes to the system that we are talking about for the agent identity.

And the OAuth2 token exchange here, the idea here is that I’m taking in some sort of human sort of agent that wants something to act on its behalf, but only for a short period of time.

And it does that sort of flip out in between the two of them.

An example of this, and this is actually going to give us a two for one, because this is actually what the OPA policy as code looks like.

So instead of defining this in some sort of UI somewhere, that I have to go change that UI, I can actually version control my policies.

And so for instance, here I might have a default TTL of 600 seconds.

And I only allow people who have an issuer tier of A, you know, or AAA or something like that.

So think about that sort of trust tier. We’ll talk about that in a little bit. But say that anybody who has a trust tier of A is allowed to have this token as long as they want to read stuff.

If they want to write stuff, they only get it for 300 seconds.

And now if that ever changes, I can see that inside of the code, I can run tests against it, all sorts of things.

If you do some for a system model, you can connect your policy to your system model and get a verifiable check that your digital twin is working correctly.

So think about it in those terms as well.

Right. So there’s lots of different ways of doing this.

I’m not going to go into this, just so we can go forward. But a lot of the trade-offs here have to do with those roundtrip sort of things. So you can do different configurations that they might increase your latency a little bit, which might be fine, depending on your use case.

Right.

So yeah, the idea here is that this gives us a way to safely delegate. That’s one of the big things that the other thing couldn’t do. Token exchange lets us delegate. All right. Open policy agent.

All right. So what we’re really looking at here with open policy, talked about that with the example before, but we’re really looking to solve issues where we have blind spots, where something that we changed has made an attack vector where somebody can now get to access the things that I don’t want them to have access to because of a change in the code.

And I didn’t understand it.

If my policy is not as coded, if it’s not testable, if I can’t put it into a regression suite, then I just have to wait to find it, basically. I have to wait for the CVE and have a fun day then. And so we’re looking for a way of getting ahead of that, pushing those findings to the left so as I change stuff inside of my code base or as I change policy, I can see those changes happening with an auditable record. Also, it’s the benefit of being very easy to give to agents so they can understand them as well. All right.

I think that’s as much as I’m going to talk about there. We’re talking about open policy stuff all over the place, but I might be skipping over those parts too, but just know that this thing is everywhere inside of the system where it’s defining the contracts that are going between these different pieces and parts. All right. That’s two out of the five. So any thoughts up to this point?

I’m just hanging on. Hanging on. All right. Well, Firehose- Keep rocking. Firehose, keep going. So we’re going to go into the next bit here, which is layer one, identity and credential management.

This is basically proving who you are, what you can do, and how you prove that sort of stuff.

That’s the basic idea and how you keep that safe too. So the credential management, we’re going to go straight into the did registries. This one should be super fast. Basically, I’ve got an identifier.

I say, I am who I am.

Where can other people check that?

You’ve got to sign in somewhere.

So there’s some sort of history of you being that person, that being tied to your identity. Even if you have five of them, those will have to somehow tie back to your identity there. So the registry is just some sort of central store or decentralized store that has that change.

The blockchain, I think, would be considered this registry.

I’m not sure.

I might be saying that wrong. It seems to me like that’s what it is.

But then there’s also some sort of did JSON documents that exist at these registries as well.

The idea is that the did refers to you, the controller controls the did document, and you register there, and other people can look at it.

That’s the basic idea there.

Let’s see.

Okay.

No, that’s the trade-offs.

You can, I think, self-host this as well. So all of this, I did check up and down, all of this can work in a completely air-gapped network or some sort of enclave that lives off on its own.

You just have to incur that sort of overhead.

And so you need to decide if you need this sort of capability, which if you’re using ephemeral sub-issuing agents that are issuing agents upon itself, if you don’t solve it this way, you’ve got to follow it some other way. Otherwise, you’re going to be in trouble. So just something to consider. So layer one, VCE issues and verifiers. We’ve talked about it a little bit before. It’s just some way of your passport office, your university, someone who can say that you have access to the things that you have access to. The main thing here is that they have basically the central secret store. So think of like a root CA.

This kind of stands in for that, that is able to dole out and be an independent third party that is trusted for asserting that you can do the things that you say that you can do.

All right. Now we’re going to get to agent wallet and secure storage. I think this is the one that I’m most curious about because it kind of ties to the wallets that they have in the Bitcoin and all that sort of stuff, like those cold wallets and hot wallets. This is equivalent to that, but for permissions where there’s some sort of external store that’s very heavily guarded, either on memory and some sort of a secure hardware configuration or with an actual physical defender that protects that root key that serves as a store for the agent.

I’m very curious how this works for these multi subclassing agents.

This is one that I have a bunch of questions about, but there’s some sort of area that there is a deeply, deeply held secret for these agents that hold onto their core ability to edit their did, I think is essentially what it is, and claim that they are who they say they are. So yeah, there’s lots of different ways of doing this. You can do it as an actual physical wallet. You can do it with, I thought this was interesting, with an NVIDIA MIG. If you don’t know what this is, this is the ability to partition your GPU that’s available.

I think it’s on Hopper and above.

I know Blackwell can do it, but you can basically do a hard partition inside of your GPU. And so here you can do that hard partition and separate it from the rest of the GPU and have that serve as your root core here.

You’re kind of a root store.

So that was very interesting.

The idea here is that the keys is ampere.

Okay.

The keys live here and nowhere else.

And yeah, this is kind of the thing.

If you lose this, you’re toast. Hey, if you want, I can add a comment to the last bullet you had on 75. Oh, please.

So the last one down there, the air gap signing station, what that would mean would you basically have a separate machine and you’re running up a USB code.

So this requires a human involved, but the human takes a photograph using their camera.

And then they actually use the camera, either their cell phone or the computer that they want to send the credentials in. So that’s probably your most secure one on the list.

And that’s typically used if you’ve got large amounts of Bitcoin.

So.

Ah, gotcha.

I saw they had the Faraday case.

It’s like, man, that’s serious.

Yeah, very cool. All right. The next one is a key management service, which for me was jarring, because I always think of KMS as knowledge management, but the key management service is basically like your HashiCorp vault, that sort of thing.

Some key vault, Azure key vault, that sort of thing, where we’re not storing these credentials locally. They’re in some sort of external store that itself kind of works with the system, same sort of permissions sort of things that we have. There’s an external key management store that has some sort of security around it and a strong level of attestation.

That way they’re not kind of having these things spread in a whole bunch of places.

And this is generally used, the key management service itself will generally be used with those core secrets that get traded for tokens.

All right.

And so it’ll generally live in there and not leave. And so there’s lots of options for this, you know, different ones will have vendor lock-in.

So that’s like AWS key vault, Azure key vault.

You can do this with your own self-hosted, I think it’s hardware security module cluster.

You can also do it with like HashiCorp vaults, I’ve used this in physical product as a key vault store that’s open source.

So that’s a good one if you’re just trying to tinker around and don’t want to deal with HashiCorp. But I know that one’s very popular. So I think a lot of times you’ll be using that too. That are the AWS one.

So yeah, that’s what it is. It’s basically your ENV file, but not for dummies. All right. That’s layer one. Really, really, really fast. The idea of layer one, this supplies the root of trust.

You are who you say you are, and you can do what you can say you do. All right. We’ll go next now to the agent discovery and trust establishment. This has three major areas. This is really kind of the glue.

You’ll notice there’s two resolvers and then a reputation and trust service.

This kind of handles the way that we resolve the agent, and then we have resolved the did, and then how we decide with those two resolutions how trustworthy you are, once we’ve figured out who you are and have mapped you to some sort of identity. The first one is the ANS resolver.

These are pretty simple.

I’m not going to go super hard here, but it basically takes this sort of thing that we talked about in the first area, and then it returns three artifacts, which is basically who you are and what you’re doing, and then it returns the three artifacts, which is basically who you are, where you are, and all of your VCs, and then puts it back into whatever is calling on to that ANS resolver. It returns this first layer of resources about you that doesn’t necessarily have everything yet.

You’re not talking to the actual agent yet. You’re talking to the resolver, and so you’re just kind of saying, hey, you know this guy? Basically, to the system. This is kind of what this sort of thing will look like. I’m going to ask the ANS name.

It’s going to tell me what its did is, where it is, what the VCs are that it has access to, and a bunch of information about its metadata, who owns it, that sort of thing.

In the perfect world, you’re going to ask about that thing, and the resolver is already going to know about it, and it’s just going to say, oh, that’s great.

Yeah, I know him. That’s Tom, and it’s going to push it straight back to you, and you’re going to have a nice quick thing. If it does not know who that is, and it’s not cached, it’s going to have to go out and do a bunch of handshakes to the other elements that we’re going to talk about, like the did registry, and so we’re going to talk about that. The resolver is just another one. You run it as a sidecar, a node daemon set, locally, or with some of these regional.

I think this is one of the ones that you start getting into the Wasm, where you can actually store this as a sidecar with Wasm and run on the CPU really quickly.

All right.

Yes, this is one of the brokers. Next one is the did resolver.

That’s resolving the namespace to the did.

Now we need something to resolve the did to the you, or the it, or the whatever it is. The did resolver is the way that we run back that resolver to some sort of identity. It’s talking to that registry.

It’s looking through all the credentials it has and doing all of those interpreters back to the actual identities.

I’m going to try and move through this quick, because I think it’s pretty intuitive what this is if you don’t look into it too hard. It’s basically saying you are who you say you are. I think there’s probably a better way of saying this. Let me go back to my graphic here. I’ve made a mistake. Okay, here we go. All right, so basically a did registry is I am who I say I am.

The thing with the did resolver is that if it’s just saying, yeah, they’re who they say they are, or they’re not.

That’s all we have to say for that. Fortunately, I thought that would save time, and it didn’t. Okay. All right, so we’re going to go to the last one, which is the reputation trust services. This is a pretty interesting one, which is basically, I think of it as a social credit store for agents. We’re saying, do we trust you, or do we not? This is a way that basically brokers that thing out. It’s in two areas.

There’s two things that it’s talking about, the reputation and trust. Number one is, is this a trustworthy thing? Is it doing things that are malicious?

Do we not know who it is?

If it’s a new service, it’s going to have low reputation and trust, but not because it did anything wrong, just because we don’t know what it is.

It hasn’t proven itself.

There’s a whole bunch of elements of that to it.

It’s a long time in the market doing things in good faith. You’re going to have a very high reputation and trust service for maybe that particular set of ANS and DID resolvers, but this also cares about capability. There’s the good faith, but there’s also the competency. Devin claims that it’s the best software engineer ever, but every time it does a merge request, it breaks five things and fixes a non-existent bug. It claims inside of its VCs and its DID that it’s a perfect software agent.

It’s going to replace all of your software engineers and actually use it.

It’s crap. The network, everybody is voting it as crap and saying that it’s wrong. It’s going to have a very low level of reputation inside of this thing. It’s basically a way of measuring the claims that it is.

Yelp for robots, whatever you want to call it.

That’s kind of what this is. That’s layer two.

The main idea here is this is the link between our identities and layer one and where we’re going to go next, which is the policies with OPA and layer three.

I might actually make this 720 on time.

I’m going to keep going. Yep, ANS and DID. This is the resolution. Then we want to kind of tie that resolution to the issuer score.

Here’s where we’re starting to really, really care about the latency.

That’ll get really, really important as we go up the stack here where we’re trying to target milliseconds, nanoseconds.

We’re trying to keep this as low as possible because this is happening all the time, especially if we have lots of really little tiny agents.

I don’t want my handshakes to take longer than the thing was actually alive. Next up, we’re going to talk about the dynamic access control. This is basically the PDP and all of its PALs. That’s how I think of this layer.

I’ve got a little graphic here made for this.

We’re looking at the inbound request.

This is coming from the layer above, which is a proxy for the user.

It comes into the decision point.

That branches out to two different areas.

It branches out because it wants to keep this thing nice and dumb.

It doesn’t want the decision point to have any logic in it.

The decision point needs to be very, very deterministic.

It runs the rules just as it says it is.

It’s kind of cordoning out different elements of this to the other parts of the system.

This thing is just kind of an execution-focused element. It’ll spit things out to either its policy information point, which goes out and gets more information if the information is not sufficient to make a decision about the policy.

Say, for instance, I’ve got a rule like I had before.

It says I only accept things with a reputation of A or above that is doing right access.

If you don’t include your reputation and you did somehow and it has somehow gotten dropped, this would be required to go out and get that. There’s some better examples of that since that is kind of usually there. We’ll talk about that.

I’ll stop on that slide when we get there.

The policy administration point, that’s basically saying it’s going and getting the code from the repo.

Our policy is code, so we’ve got to go get that code. I want to make sure it’s as up-to-date as possible so that if I have a node out there and I push a critical update that’s closing a gap that I want closed now, it’s going to execute that now.

Once we’ve done all that, we send that off to our issuer and it prints out your burn after reading token for 10, 15, 20 minutes, whatever it is.

I think that covers most of what this is.

We’ll go through and see if there’s anything super interesting in all of these.

PDP is your judge brain. We care a lot about our RTTs as they start showing up a whole bunch where things are starting to stack up because everything is having to go through here in order to get their tokens. To get the actual credential the agent uses, they have to pass through here. You can deploy this same way as other things, all the other side cars and all that sort of stuff. Or up in the cloud. The idea here is that it’s using that human readable policy as code.

So our PIP here, this is basically, I don’t have enough information.

I need to go and get additional information. Here are some of the things that they might gather that might not be included in the original DID.

It might be grabbing stuff like the doc version, some metadata about your DID so you have some information about that.

It’s going to go hard check those things and make sure things match up.

It might be grabbing stuff. We skipped right through all the spiffy stuff. But the spiffy FVID would be like this agent, this request is coming from this pod over here, over in the Kubernetes cluster. That can be stuff like authentication time, where you are, who owns the data that’s there.

So if you have like row level security, get little pieces of information there that might not be in the core request. It’s responsibility is to go and grab that stuff. And we like the PIP because it keeps all that crap out of my execution engine because my execution engine can’t be wrong. The PDP has to be golden. Otherwise, everything is upside down.

So that’s the idea here with the PIP.

All right. The next one is the administration point.

This is basically going and pulling your Git repo or your policy code. If you have the code, you probably have it up on some CDN somewhere that your repo pushes to and some sort of production or staging sort of thing. And its job here is basically to go grab that thing from wherever it is and get it into whatever state it needs to get into so the PDP has access to it. A lot of times too, it’ll be responsible for doing stuff like your testing, your benchmarking.

So you have certain performance benchmarks that you care a lot about, especially if you’re doing this at scale. And it’s responsible for signing those commits with your keys and all that sort of stuff. So you have provenance on where this policy change came from and whether it was good to go. That way, if somebody tries to sneak in to your policy chain, all Jayatan style, then you can cut that down right off the gate too. So there are lots of different areas where people will try to attack. This is a good way of protecting yourself on the back end as well. Yes, Jayatan mentioned. What was the name of that bug, Charlie?

Or that CDN?

I can’t remember what it was. Let’s see.

All right.

So next we are into the JIT VC.

And just to keep it simple, it does what we’ve been saying it does, is that it is the one that’s really doing that token exchange sort of activity that we were talking about.

It’s minting those ephemeral, XC utils, thank you.

It’s minting the ephemeral resource bound credentials exactly when it’s needed and for exactly how long it’s needed. And so it’s the one that’s kind of making that decision.

And that’s the out point of dynamic access control.

All right.

We’re in the last layer. I’ll go through and see if we can talk through some of this.

All right.

So this is the big, kind of the big brains. We have all that stuff under that. It’s all serving this area up here. We’re starting to actually talk about stuff that we interact with as humans on a day-to-day basis. Oh, that’s fun.

What has happened there?

All right. I’m not going to get distracted by that. All right. So layer four, we’re focusing here now on creating the giant global session for whatever activity it is that I’m doing, the workload, whatever it is, having the ability to use that kill switch.

I’ve noticed that I’ve trusted this thing and now it’s trying to RMRF star my entire database.

And I’d really rather not do that. So let’s shut that thing down. This gives us the access to that. And it’s able to talk through HTTP, GRPC, A2A, MCP, any other sort of acronyms that people come up with in the next year or so.

The idea is that this is where we’re going to put all that dirtiness.

All right. So our big brain, the protagonist, lead player, played by Henry Cavill as session authority.

That’s the big guy who’s leading the whole show.

And we’ve got some helper friends here as well. All right. So session authority. I think I’ve said this about five times. Yeah.

The big idea here is the kill switch. It’s the brain. It’s generally working with something like a Kafka. This is where your Kafka bus would live. That’s managing all of that sort of cues out to your different parts of the system.

You can do this with Envoy. I think it’s a very good way of, this is the one that I’ve looked at a lot.

So you can do like an Envoy sidecar and have that sit on Ingress if you’re doing Kubernetes.

But you can also do it with Wasm and have it sitting at the edge. And so you can even do it with Embedded Rust and SQLite for drones and things like that. So there’s lots of different ways that you can implement this session authority.

It’s really important you get it right and you invest correctly because it’s sitting in the middle of everything. So yeah, the idea here is that it’s the login once kill switch that I know where to go revoke.

Synchronizer is the heartbeat of your application is deciding if you’re still valid, if things that I’m working with are still valid, if resources that I’m working with are still valid, basically trying to keep everything in state when you’re working in a distributed system and trying to do complex operations over shared resources that might be trying to make transactions at the same time on the same resource.

It’s kind of a way of managing that and trying to keep that in alignment.

So this is working a lot with that Kafka system we were talking about before.

There’s also a Redis cluster generally.

So you’re really wanting this to be in memory.

So some sort of an in-memory database so you can go fast, fast, fast, fast, fast writes. You’re wanting nanoseconds on sort of the puts and pulls here because this would be the bottleneck if you don’t get it right since it’s doing that synchronization from all of your nodes out in the world and then pushing it out as well. And so you can do this with Redis.

Here a lot of people talk about that. I saw the smart KV thing mentioned.

They mentioned that in the paper. It seems like it’s in research sort of area right now. But you know, I think you probably still be able to use Postgres KV.

Maybe the performance needs aren’t all the way up there if you have high availability needs.

But you could even use a Postgres KV here if you needed to. So don’t get distracted.

You can probably do this even with a normal enterprise stack.

Although Redis has everywhere too.

I’m just salty at them because of their open source stuff.

Maybe that’s not fair here. All right. Yep. The idea here is just to keep that SID to state lookups fast, fresh, and fail safe that cannot fail.

All right. And then we’re into our babble fishes, which the first one is the adapter enforcement middleware, which basically is the thing that takes those custom plugins and does the actual conversion. So it’s executing the adapters into that SID, which is the sort of the plane that this whole layer four works on is that SID that decides if a session is still active.

It gets that from the MCP A2A WebSock and actually executes that sort of change over is the easiest way to quickly go through that.

There’s another one where you’re starting to get really, really close to the edge.

So there’s lots of WASM options for people.

You can also do it as a HTTP.

I think this is the interceptor where you can basically have it sit as an interceptor for your GRPC servers. So you can’t just do it like a bolt on.

So you like a bolt this onto like a client or something like that as an adapter there, do fun stuff there. So yeah, this is the last guard rail into the system.

Because the next one here, enhanced protocol adapters, is just basically fixing the crappy system that you’re interacting with and trying to get it adapted into your system. And so whatever you do here is going to be executed by that AEM layer. And so, yeah, this is where you’re adapting those little things there. Lots of different ways you can do this. Istio is one that’s mentioned a lot as kind of a sidecar that works with Envoy really well. But you can do, this is going to get real Wild West, I’m sure, with these sort of implementations, you’re actually doing them.

And yeah, the guy here with the protocols, they were trying to extract the request coming in, translate it, inject it back into the stream, enforce any of our sort of adapter requirements.

And then if the stream is revoked, communicate it out to that MCP service that, sorry, you’re cut off. We don’t trust you anymore. Yeah, that’s layer four.

So this is the final brain, the actual thing that’s doing that final execution, using all the primitives below it to connect your agent swarms in a way that is fully credentialed all the way up from the very, very bottom to the very, very top that you know exactly where stuff is. I can go back and look and see exactly what happened, where it got those credentials and where it went wrong and where that thing spawned from, which is something that if you don’t put in this sort of investment, very, very hard to do.

So yeah, that’s the fire hose. I’ll just leave it here and I guess we can decompress. Yeah, I’m a little depressed. Yeah, I’ve run into so many issues with like the misrepresentation of what zero trust is and things like where I’m trying to, sometimes it’s hard to tell whether there’s just a lack of knowledge or lack of effort or both or what. And now I’ve got to push multi agent, you know what I mean? I mean, it’s like, wow, this is probably 10x what the amount of complexity in the system that I’m dealing with now, you know?

I’m trying to figure out what hope, how are we going to get there?

Anyway, I’m trying to figure out what’s the best way to get there. That’s for me to figure out. What do you think the level of, I don’t want to say adoption, but what do you think the maturity level is right now of a current, you know, if I wanted to stand up a stack similar that meets these kind of criteria and stuff, I know I could pick up the tools and figure out how to put them together myself and do all the things. Is there already a thing out there that you just say, yeah, I want that one and now I’m covered? It’s very, very easy if you’re doing it on a more public facing area and you can use public resources. I will not say it’s easy. I mean, this thing is obviously very complex.

If it wasn’t for the fact that something is needed to solve this, you know, you’ve got to solve it somehow. You know, there’s just a lot to pull in. But if you are able to use, you know, some sort of resources that are out there and you’re willing to delegate some of that out, it does get a lot easier. So the things that I would say are very, very easy from all these is OPA. So using that, you could use something, you know, like an Okta for some sort of identity sort of stuff to get going quickly.

Istio, a few things like that where they make it very easy to support this sort of stuff.

Envoy is another one.

Trafic, you know, there’s a certain line of these that work together very nicely.

And the more that you’re working in the Kubernetes space, where they already have a lot of stuff figured out for workflow or workload identity, where things are ephemeral, the easier it’s going to be.

It’s going to be good to make this work with Nginx, you know.

Yeah, so if I head towards Kubernetes to start with, then it’s not too much of a, you know, violent jump over to now hack this other thing in on the side, you know. Okay. Yeah, that makes sense. To get this going in like a private lab, which is a problem, you know, some of us have, it’s very difficult. It’s going to be a very hard thing because you’re having to do a lot of fairly complex stuff yourself. But if you need to do it, you know, you got to figure something out. So yeah, somebody’s got to do it. So it’s one of those problems. Like it’s hard.

It’s complex.

Yes. So if you find something that’s less complex, please do that.

And then the other thing I was thinking about is this just from a user interaction kind of standpoint. I’m in a mode where I’m used to, you know, creating my Docker containers or Docker images and getting them up to a registry and saying this is the thing that does this and then setting up a workflow that then, you know, spins up a container from that image and, you know, hooks it up and does all the things. Is this, is there a similar kind of a concept where I’ve got some kind of an agent that I set up and I register that with some registry and then, you know, who is it that says that the agent can do what it does? You know, is that me or is that another agent registering itself or what?

It’ll depend on sort of your configuration, I think.

So obviously if you’re running your own registry and all that sort of stuff, you’re going to have to figure that out, you know, if you’re kind of behind somewhere. But I’m sure, so like this Google A2A, we’ve been kind of talking through that and I said this is kind of an interesting thing that seems interesting and it became, I wasn’t intending to learn about A2A here, but it just kind of happened because it’s kind of central to all this. So you could like register your agent with Google. Same way you can get a DNS, you know, register on the public internet, you’re working with their DNS and all that sort of stuff. So there are ways that you can do that that are more centralized and the more centralized they are, it turns out the more easy they tend to get. But obviously you’re trading off risk.

Yeah, I would imagine that, you know, Anthropic, they’re about to start like an MCP registry and so that’d be like where you register tool to agent calls.

I’m sure that Google will have like an agent to agent registry that will serve this sort of thing as well.

Okay. I suspect eventually we might get to a point where people are using hardware wallets for their own personal approval, but then they’ll use a registry for all the agents that are running underneath their personal approval.

Right.

I could see that.

Yeah, at some point it’ll start rolling into the other tools, you know, where I’ll have a, you know, GitLab right now. I’ve got a Docker registry there.

Maybe I’ll have an agent registry, you know, as soon as somebody figures out how to make money off of that, they’ll, you know, we’ll be using that too.

Oh, a hundred percent.

A model registry is actually in GitLab 18.

So yes, I just haven’t made it there yet.

Okay. That’s why I was like, I want to upgrade to 18 because they have, they have that sort of thing there. So yeah, we’re going to start seeing this stuff. It’s going to be that messy. It’s like the nineties when, you know, there are 9,000 different brands, protocols and standards and all that. It’s going to be a hot mess for a second, but I’m sure, I’m sure that it will coalesce eventually.

But we are in the hot mess phase of this sort of stuff, but people are thinking about it, which is good because it’s kind of a big problem. I’m trying to figure out how many more times I’m going to watch this video just to go back and pick up the, you know, the pieces. That’s my normal approach though.

A longer session.

So I can actually dig into this. This feels like, as I started getting it, it was like, this is like a four hour session. This is like a half day sort of thing at some point. Yeah. And it, I think it is.

Sometimes I feel like these are great to get a, I like the fire hose. It gives me an idea of the things I don’t know yet, you know, whereas if I was, if we, if we slow it down some, you know, sometimes I, I’m not quite sure. Which maybe, you know, just thinking out loud, maybe it’s a, you know, the fire hose and then followed by some, okay, where do we want to deep dive a couple of pieces, you know?

I don’t know. I’m just thinking. All right. Open floor. Any other thoughts? You know, passing musings.

What’s, what’s kind of your takeaways from the, all of the problems we’re dealing with here?

I think understanding the different ways this can go wrong. And not a little bit wrong, but way horribly, falsely wrong. Might be the, you know, that’s kind of difficult to wrap your head around if you’ve never really thought through what agents do and how they’re used and things like that. You know, that some of that might be the bell ringer, you know, to get somebody’s attention to actually, you know, go figure out, you know, the problem is their initial thing is going to be no agents, you know, it’s kind of like we’re limited to like two admins on a system just because somebody said two was a good number.

Not that it made any sense.

They’re just trying to limit the number because that’s what they think zero trust means, you know, their first, you know, instinct might be turn it off, but then if you’ve got, you know, the solid background of, well, here’s how to solve the issue and ignoring it isn’t, isn’t an option. So, you know, we got to, we got to figure it out.

Someone. And the thing is that someone’s first inclination is going to be to turn it off. But then if the thing they’re turning off is really useful for the business or the agency and it’s critical for us winning at something and the other guys over there are not turning it off, somebody’s going to turn it back on. And then what do you do if your first plan doesn’t work anymore?

So even that is, you know.

Yeah, that’s the same thing we heard in the nineties. They said, oh, you can never use the web in the government. Are there any government agencies that don’t use the web today? And is it still, is it still insecure? I know a couple of people that would rather code in ones and zeros probably, but you know, the rest of us at least made it past that.

And this feels a little bit like a, I think you’re right.

It’s kind of the wild west. And at some point somebody is going to figure out or it’s going to coalesce. It almost reminds me of like web development back in, you know, there’s, I can’t remember when somebody came up with just putting the lamp stack together, you know, I’m going to MySQL and Python and Linux.

I don’t remember what the AA was Apache.

I think it was around 2000.

Yeah. And it was like, boom. And I’m like, oh, well, I don’t have to figure all this other stuff out. I didn’t want to learn all of that other stuff. I just wanted to do the thing, you know? And it’s like, you know, some, some pieces that were, you know, really template did easy to get started.

And there you got. I could see something similar to that.

I mean, it’s not the only place that happens, but that’s pretty cool though.

All right. Any thoughts from folks we haven’t heard from?

Jack, David, Nate, Michaela.

Oh, Michaela’s here.

Hey, Michaela.

I don’t really have anything. Thought you did a really good job. I’m just trying to digest everything because I have a very love-hate relationship with security.

So it’s very interesting, but at the same time, also frustrating knowing what this is going to look like 10 or 15 years from now in the DOD and what we’ll have to be dealing with on a day-by-day basis and working through ATOs and all of that fun stuff for people who don’t understand it at this level. So that’s, that’s where my slightly pessimistic coming from or pessimistic for security mind is going, but it is extremely fascinating. I thought you had a really good job explaining it. Thank you. All right. We are at 7 30.

Last call.

If not, thank you guys for joining us for another fire hose. See what we can drum up this interesting next go around. I guess, Jay, any, any final calls before we close out?

I’m thinking of renaming this the fire hose chat kind of like the fireside chat series.

No, thanks a lot for putting all this together.

I know it’s not a small amount of work. And then it’s, I do really like being able to jump deep into a subject where a lot of times, you know, and it’s also difficult being, you know, coming out of work all day or something, and then hopping into, you know, an AI thing, which, you know, I get it.

I do it too, except for I’m usually thinking about this while I’m trying to work.

But I think, I think that’s it.

I’m looking at, you know, kind of the schedule over the summer, times next week. After that, we’re going to do a, we’re taking a, I think we’ve got the week off for July 4th. The week after that, we’re doing a social. And then looking at, you know, what other, what other topics we need to talk about.

It does seem like agents are all the thing.

I can give you a heads up the actual AI symposium next January is going to be about agents, you know. So that’s, it’s going to be sticking at least through then. So, just curious to see what, what people are interested in, you know, talking about next, whether we keep the agent thing going, which some of it we’re going to, and then what other kind of topics. I’m thinking about David with the, what did you say dropped today, David, if you’re still on. If he’s not, I think it was a mid journey piece. I got a note from him saying he’d lost, not lost, but was spending a good bit of time on that. So I think we’ll have a, we’ll have a discussion of prompts, you know, kind of throwing that around at some point coming up.

But I think that’s it.

All right. Well, thank you folks. We’ll see you at the next one.

Appreciate it.