So, this is a historical question, right? It's not actually hard, but historically, the systems that we have in place generally ask the question, did you present the right key to have permissions? And it's not designed to ask, was this performed by a human? Because it's basically the same thing, right? If you log in and you do an action, it's obvious you logged in and did the action. And there wasn't such a delegation problem.
And so, what we've got right now is these enterprise systems that are usually using SPIFFY for workloads and OAuth for human authorization. Those are two different layers. They're not necessarily connected systems.
So, let's say I log in as the customer support agent, customer support person, right? I'm in the person, I'm not the agent, and I want to command the agent to give responses to customer support tickets. When I log in, I log in with my particular identity, and I might be using Okta or some other type of human identity system. After I log in, then I'm given the permissions of everybody in my department.
So, I might be given the permissions for the support department. And then with those permissions, I make a command to the agent. Maybe I say, can you improve people's happiness when they receive an answer from customer support? That's kind of a funny prompt, but I might just not be trained in how to prompt AI.
And so, I might type in, please improve the customer satisfaction, okay? Now, what happens is the service is actually now making the request of the agent, not me as an individual, because that agent is a workload.
And so, now my personality or personhood is in a different system than the command that was given to the AI agent. And then later, when you look at the audit logs, it doesn't show the actual individual, it shows somebody with these permissions.
So, let me give the same example. So, the example is, I'm from the customer service department, and I tell my agent, you should make people happier when you respond to their responses.
Okay, now what did I just give permission for, right? Now, one of the things that I might not even be aware I gave permission for, that the agent is going to do now, is the agent is going to go back and look at all of the records of customer satisfaction, and all of the responses, and see, and assess them, and now decide based on some aggregate data.
Now, when I said, just make your responses better, a normal human wouldn't do that, but an agent wouldn't do that. So, now I just granted the agent all of this permission to look at these back records, and I'm not even aware I did it, right?
So, that's the first thing that it breaks down, is my intent. The way people phrase what they're doing has so much assumption in it, that when I make an intent, and I say, do this, a whole bunch of permissions come into happening in the background. That's the first break.
So, then the second break is that my login isn't the same as the authorization for the workload. The authorization for the workload is for my whole department, and so let's say that in this case, the agent goes along, and it finds out that when there's emojis in the responses, that people are happier. They give a better rating later, and it's like, does this statistical analysis, and now everybody's getting emojis all the time in every response from customer service, and obviously, that's gonna, I mean, this is kind of a silly mistake.
I'm choosing something that's a little light, because there's all kinds of mistakes that we've seen that are a little more tragic, so I wanted to choose something a little light-hearted, so all of a sudden, every customer is getting emojis in every response from the AI agents, and eventually, people kind of feel this is patronizing and annoying, so even just this innocent thing turned into, I didn't realize I was giving it permission to use emojis. I mean, should it use emojis? Should there be a maximum number of emojis per response?
I mean, these are kind of, again, light questions, but if you're talking about database access or you're talking about financial access or anything else, you know that you're gonna have certain parameters that you wanna guard. You don't just wanna say, go ahead and do whatever you want, so again, from this prompt, there's a cutoff, and it doesn't know that it's me. It knows it's my department, and then the third thing is that with the actions, so what you get is you can trace the fact that the agent is giving emojis, but you can't figure out why it's giving emojis.
Nobody gave the prompt to put in more emojis. I mean, maybe somebody did, but you can't tell. What was the prompt that made the agent behave this? All you can see is agent put in emojis. You can't say agent trying to make people happy. You can only see agent put in emojis, so you can't even see the agent's reasonings, so basically those are three breaks, the intent, the anonymous token, which isn't linked back to the person, and the log, which isn't attributed, and so all of those are breaks in the chain of custody when it comes to agentic AI.
Right, so if you're an auditor or a CISO and an incident happens, even if it's as trivial as the emojis, you want all the information, right?
You want to know who logged in, who was, what prompt did they give, what services did they access, what permissions did they give, how long did they give the permissions from, did they just give an indefinite thing or did they say try this for a week, who authorized it, which services authorized it based on what, and then at the end, you know, whether this agent is continuing to do this activity, whether they still have this credential, where is the credential, where's the token, and of course all of the damage that was caused by this thing, so it might be that they sent emojis to one person or 100 people or everybody, so basically everything.
You'd want to know as much as possible, and that's the protocol that we've been working on, that we've been creating, what's called CHAOS, or Know Your Agent Operating System, K-Y-A-O-S, CHAOS. Anyway, it sounds cute, and we're hoping to reduce the chaos with our CHAOS implementation, so basically that's what you want to see. You want to know everything. You want to know what the person approved and why that department had those permissions and where it went.
Now, even if you're using this protocol that we're designing or tool set, you could call it a tool set, it's also, it's also open source, just so you know, like I'm not selling a product. I work for DIFF. We are an open source organization, and people develop these things together, so we have multiple people from the industry coming in and trying to prototype this, work with this, and really prove that it works with the existing legacy systems. It's also not a replacement for your legacy system. It'll work together with this OAuth system that we've talked about.
It's, it's very, the design is so that we can use it within the industry with what we have, and the design is so that your CISO or your auditor will have all the information. Because it's just a tool set, it really depends on how you implement it, so you might implement it in a way that when I give a prompt, it actually translates that into a little table, and it says, okay, are you granting permission to this agent to access all of the past data, and then I'm like, oh, I didn't intend to do that, but it might, if, again, if it's programmed properly, it would just show me a table.
Okay, you, it's going to be able to access this. It's going to be able to read, write this. It's going to be able to use emojis or not use emojis. It's going to be able to do this for the next hundred responses, and then you get to audit it first.
As the CISO, you could actually implement those kinds of defaults there, and then the person would see a little table, and then they'd approve it, and so at the moment of that approval, they would actually see what permissions they've granted, and there would be a time stamp and a certified signature that the person saw that table of what they were approving and sent it in, and this also provides a guard at the area of the intent. You have much more structured kind of things, so this structure, it boxes you in at least a little bit.
It boxes the agent in, and it's a little bit more accurate because what it does is it shows you the permissions exactly as they're going to be written when the agent gets them, so this gives the person more agency, and it also creates a lock, like a certification that this person approved this at this moment, so that's one of the ways that we do that, and it provides that end-to-end from the beginning when the command was given all the way to the end when the action was taken by the agent. Okay, so it's a number of things, right? One of the things is that it helps you form a better prompt.
Again, that could be done in different ways in software, so it does depend on the implementation, so first of all, if it's better scoped, better designed, then you've got a change to the authorization, and you know what you've approved, and by the way, this word scoped, right? In the OAuth world, there is a word for scope, but they're very blunt, you know, read, write. This can be much more specifically scoped. It could be for a specific amount of time. It could be for a specific number of messages. It could be you can only answer support tickets of this kind.
You're not allowed to issue refunds. You're not allowed to access someone's data, so the scope is much more specific for what the agent can and can't do, and there are studies that show that most of the time, even these agents do obey their scopes. It really does help you prevent that.
The other thing is the cryptographic proof means the person knows they're taking responsibility, and this is maybe psychological, but the person knows what they signed, and they know they signed it, and they know it can come back to them, and this means that anybody who's working with these prompts knows they're going to be accountable, and they know what they're going to be accountable for, and so maybe people will be a little bit more careful, or maybe people will get the proper training.
When you're dealing with prompting in AI, it could just be a question of, oh, I needed to go back and teach that person to write good prompts, so now you've got a system which can reinforce better and better behavior as people learn, and you know how to train them, and you know who to train, so it's a lot. The system becomes much more precise, and so it becomes also precise in terms of allowing you to take down a service. It's not even a service because it's a credential. You can take away a credential from an agent. You don't have to stop the agent.
In today's systems, frequently you might need to take down the entire service or at least reboot the service if it's holding a token that is giving it too much permission. In this system, you can just revoke that permission. It's a credential. It's a credential held by the individual agent or each of the agents of that instance, and you can revoke the credential, so you're actually allowed to do much more surgical changes if anything goes wrong.
Okay, so it's going to be a quick demo, so the first thing they'll notice is it's quick. I mean, when you do a forensic investigation, it might take you weeks to figure out who did what and what the agent authorized. This will take a few seconds, so when I do my presentation at the event, it'll be fast, so that's the first thing to notice.
The other thing to notice is there's two other things, so one is we're going to show what happens when you try to tamper with the permissions because a lot of the breaches we've seen lately have been AI agents trying to tamper with or reuse some credentials, so the first thing we'll do is we'll tamper with the credentials, and we'll see what happens there. It'll just fail because they won't be valid, and then we'll show what happens when an AI tries to revive expired credentials, so we're really going to show something that is unique, and it's not exactly forensics. It's actually prevention.
You'll see how these systems can prevent behavior, which, I mean, I don't need to tell you preventing the wrong behavior is a lot better than finding out later and being able to do the forensics, so that's really what the focus will be. So, there's two things I want to emphasize. First of all, it's compatible with the existing Enterprise IAM systems. You're not going to have to replace this. It's compatible with whatever you're using today. The second thing is it's a public standard. It's an open source standard, and we'd really love you to join.
We're a nonprofit organization under the Linux Foundation, and any enterprise or nonprofit or individual is welcome to join and prototype these standards and help us make sure that this code fits in with your existing systems, so it's all open to the public, and we would invite people to come and join DIFF and help design these standards.
