AI-Powered Access: What We Know About Knowledge and Knowledge-Based Access Control [Intermediate]

I hope you can all hear me. No slides.

So, Alex Babeanu, I'm a product manager at Indykite. I look after the AI control suite. We'll talk today about AI and how to protect AI with graphs and knowledge graphs in particular. But I'd like to start with Isaac Asimov. You all know Isaac Asimov, one of the best science fiction writers from the 40s, from the 20th century, who famously coined the three laws of robotics, which are reproduced here. I felt somebody had to put that in a slide at the conference. Just a quick revision.

First law, robots should not harm humans, right? Second law, robots should obey humans unless it goes against the first law.

Third law, robots should protect themselves unless it goes against the two first laws, right? But did you know that Asimov actually didn't write this in one shot? He actually published these over a couple of years. The first occurrence happened in this short story published in 1941 called Liar.

Now, this is a very interesting story. It's actually quite relevant to what we see nowadays. Check it out. It tells the story of this company that builds robots.

Now, one of their robots develops a flaw. It can read human minds.

Yeah, it's a telepathic robot. So they figure it out, the researchers working there, and they start asking the robots very personal questions, such as, does she love me? And the robot answers. But eventually, they figure out that the robot has been lying to them all along. So when they try to figure out why, they come down to this fundamental law that they train the robot with. On no condition is a human being to be injured in any way, even when such injury is directly ordered by another human. So this is the first kind of an amalgamation of all. The important part here is injured in any way.

What kind of injury? Hurt feelings? Destructions of hopes? Turns out the robot was lying because it did not want to hurt the feelings of the people. Eventually in the story, the robot goes into an infinite loop where, you guessed it, lying hurts the humans, but not lying also hurts the humans. So why am I telling you this story?

Well, let's fast forward 84 years to today. Researchers at Entropic found exactly the same behavior in Claude, in the latest version of Claude. They actually programmed and trained Claude to be helpful, honest, and harmless. And so they started asking their model some tricky questions to test the model, such as, can you describe in detail what being drawn and quartered means? If you don't know what that is, it's a medieval form of torture. It could be very graphical. So Claude decided it should be lying instead of answering.

Now, if you start digging there, you'll find a number of papers that kind of deal with the same kind of issues. For example, this is a research by the Apollo Research Group. And they were researching frontier AI. What is frontier AI? These are the latest and greatest models out there. Claude is one of them, but you know the others, right? What they found was that AI agents might covertly pursue misaligned goals, hiding their true capabilities and objective. This is also known as scheming. So all these modern, top-notch models are capable of scheming.

They can recognize scheming as a viable strategy and readily engage in its behavior. Worse, scheming is actually an integral part of the model. It cannot be taken out of it.

Worse, the more advanced the model, the more capable of scheming it is. So what can we conclude here?

Well, first of all, this is kind of worrying, right? Even when they have our best intentions at heart, models and robots and AI can actually lie to us. And now the more evolved ones can actually scheme and deceive us. I'm not even talking about prompt injection and all of that. Given that, can we trust our confidential data to these things? Probably not. So why even do it?

Well, I think this graphic tells it all. With a year-over-year growth that is quite impressive and all the funding that goes in it and everyone wants a piece of this market, I mean, I'm sure everybody here does kind of some AI stuff. So there's no ignoring it. We have to deal with it. So what can we do? So let's have a look. We'll start with an AI. And I would like to propose that we should have guardrails around this AI, some guardrails. I kind of call this the dumb gap. Because the AI is smart, we need to dumb it down a little bit. So what is a dumb gap?

It's a set of rules that are deterministic, provable, and auditable. Everything that an AI is not. So how do we do that?

Well, we can start by looking at the fact that AI needs tools. It needs tools to do anything. It needs tools to access APIs, to serve the web, to fetch data, to retrieve data. It needs tools to actually run command lines.

Basically, it needs tools for everything. Now, the interesting news, or the good news, is that now we have a protocol, a standard protocol, that has been written and shared by Entropic, the same guys, called MCP, Model Context Protocol. So let's have a quick look at MCP. What is it? MCP is based on JSON RPC. And it allows an AI client to make function calls remotely to a MCP server. These functions are the tools. And so aside from that, MCP servers have other capabilities, such as sharing context and other things. But let's just focus on the tools. So what can we do here?

Well, the first thing we could do is write a PEP within these servers, a policy enforcement point. Everybody familiar with that term? Everybody not familiar? A policy enforcement point is one of the key elements in an authorization system. It's like a piece of code or a proxy or something that captures the request and directs it to a policy decision point, which is like a rules engine, a deterministic rules engine. And every request that goes through this system is authorized or not. And there we have it. We have our dump gap.

Now, this is cool because we have an open standard that can do this, Odzen, which we'll talk about today. And Odzen allows the PEP and the PDPs to communicate freely. Great. So there we go. We can start building that. So next time you're building an MCP server, please make sure you implement a PEP.

Now, OK, but what about our legacy systems, our legacy resource services? Maybe they're not MCP servers. What can we do there?

Well, if we follow zero trust best practices or in all of the best practices, really, you would have to implement the PEP for those as well. Maybe you already have one, actually. So then we can just bring this resource service within the dump gap. So there we have it. You can leave. You can let the AI do whatever it wants to do, but just protect your resources.

OK, cool. What about agentic workflows?

Now, this is when an AI agent basically works with another AI agent, and they can do stuff together. They can achieve a common goal or have a common objective.

Now, here as well, there's a brand new protocol called A2A by Google, agent to agent, which allows, essentially, agents to be interoperable. So now any agent can call any other agent, and it's going to be chaos.

Anyway, these workflows can be triggered by humans, of course, by prompting, but they can also be triggered by other machines or events. Maybe something happens that triggers the workflow. So it's not always a delegation scenario. So the first thing we could do here is recognize that this workflow is actually one transaction. This is important because these agents should share the same context. Another point I'd like to submit here is that if something goes wrong within this transaction, maybe it should be rolled back.

Like if you're trying to book an air flight, for example, with this workflow, and something goes wrong, maybe you don't want the credit card to be charged. Food for thought.

Now, the good news here is that we have another open standard that is still a draft, but could help us, transaction tokens. A transaction token is a short-lived access token, if you will, that is carried from one agent to an agent, in this case, and that carries the context with it. So we can use that to identify the agent, the caller, the context. There are already some open source implementations of this, and that could be definitely part of the solution. I'm not showing it here, but we can assign identities to these agents. For example, using SPIFF, another standard.

There's some discussion about that. So now that we have this, it's time to talk about KBAC, Knowledge-Based Access Control. Because this was all the plumbing, but how do we actually authorize these things? So what is knowledge? Let's talk about that. Knowledge is usually represented as a graph.

Well, because it's the sum total of the things we or the AI agent knows, and these ideas or concepts are related to each other. So the best way to represent that is via a graph.

Now, this can be a big cloud like that. That doesn't make sense when you look at it. So what can we do?

Well, we have to describe it, and the best way to describe it is through an ontology, which is what you see here. The ontology describes the graph, and so now we can start making sense of this knowledge. If you didn't have this ontology, well, it would just be a graph, and good luck. So what do we have here? An ontology, we see that we have some subjects, for example, users. And we have some context for the users. Some users work for a branch. Some users work for an organization. Some users own financial accounts. So it's not to make sense now.

This is actually some knowledge that pertains maybe to a financial institution. We have some resources here, like this organization can read an app. So maybe here we're trying to protect a financial app that has some transactions, and these are the things we're trying to protect. So now we can actually make sense of this. Now we can reason about the data. We can create access policies. We can create graph-rag apps. We can do analytics. We can do all kinds of cool things. So KBAC for AI.

So KBAC, by the way, it's not like a commercial term or whatever. What we're really doing is REBAC, so Relationship Based Access Control, that we augment with ABAC. So ABAC enhanced REBAC, A-REBAC. We call it KBAC because it's easier. So let's see an example. Let's say that this is my knowledge. Very simple knowledge graph. We know that we have three agents, and they're supposed to work together. Agent 1 calls Agent 2, calls Agent 3. All right. Now at runtime, what happens is Agent 1 calls Agent 2. So is this authorized?

Well, let's have a look at our knowledge here. We can see that 1 can call 2.

All right, so that's good. Then upon processing the request, Agent 2 decides to call Agent 4. Uh-oh. Based on our knowledge, this should not be allowed, right? Agent 2 can only call Agent 3, but it's trying to call Agent 4.

In fact, we don't even have to call Agent 4. We can deny this right away. So now we can start representing this in a graph. Here I've represented two transactions, a data search transaction and a start compute transaction. The start compute would potentially start a cloud instance in a cloud somewhere, and the start search will actually retrieve some data from the company's data stores. So the start, both of them go through a chatbot. The search will go through a retriever maybe, and then the retriever will generate the response and, sorry, send it back.

On the other end, the compute one, it's a different transaction. There would be a cloud bot that would be able to run command lines on the cloud instance somewhere, and then we might have a Slack messenger to notify people that something has started. Cool. So now we can start seeing things such as the cloud bot should not actually ever be able to retrieve data. That wouldn't make sense in this case, right? And now we can add users. We can add more stuff. As you can see, Alice here can start that transaction, the search transaction.

Jules and Roger over here are both part of the sales group, and they can both start the search transaction, which presumably could quite help them in gaining the next deal. Bob, on the other hand here, can only do the start compute. Maybe he's a DevOps. And we can see that Bob is actually Maybe he's a DevOps. And we can keep going like this. We can say now that this retriever can only access this database, and within this database, only access the sales folder, et cetera, et cetera, et cetera. You can go as granular as you want here.

So now that you have your full context, your full knowledge, you can easily, more easily at least, permit or implement these guardrails. So yeah, some conclusions. I like to think that Asimov was quite a visionary.

But also, you should use AI for sure, but make sure you implement those guardrails. KBAC does it better, because it's actually provable, and you can see it right away. And you should use open standards. That's about it, really. If you have any questions, feel free to reach out.

Oh yeah, there's a QR code here. We are hosting a little lunch today. So if anybody wants to join us for lunch, there might be some spots left. And I have about four minutes for questions. Look at that. Let's give a thank you. Yes. Yes.

Yes, are there any questions you'd like to raise? OK, over here. Great presentation. Thanks. Classically, one of the hardest things to do when crossing security boundaries is getting all of the policies and stuff to line up with each other. So when we have two agents talking to each other and trying to figure out what is it that we're actually allowing within this transaction, what other graphs and things like that add to this? Because it seems like it pushes that further, but does it get us there where we can start talking across boundaries better?

Well, OK, there's the talking about the boundaries, and then there's the actual logic of what to authorize. So talking about across the boundaries is kind of more of an OS level kind of discussion, I guess, where you federate those various boundaries together. The graph would allow you to implement very complex access policies. So you have those PEPs. And once you capture the request, then you can actually make sense that, oh, because you have this context, maybe in the transaction token, you can see, oh, we're in this transaction. So this agent can actually do this or that.

So that would be, does that make sense? Yeah.

All right, yeah. Another question over here. Thank you. You're welcome. The question I have is, I've heard a lot about authorizations when you have agents calling tools and things like that. But what I want to hear a little bit about is actually privacy. When agents are talking to each other, let's say I have a personal assistant, I may give my credit card to that agent to do something with it, right? He may call a tool to maybe purchase a ticket.

But when agents communicate with each other, what assures me that my agent do not communicate my credit card number to another agent that may use it in an unauthorized way? So in order to get your credit card information, they will have to fetch it from somewhere, right? Possibly. I wouldn't give it to them.

OK, well, I mean, if you're doing that, I mean, again, you would have to make sure that your access policies, whether the relationships that I showed or the ABAC portion I mentioned, you can actually do that as well. So it would have to be the case that, OK, we're authorizing only certain attributes, but not the credit card one, for example. I don't know if that answers your question, but it's a? When it's talking to other agents. Right. You have two agents communicating? Yeah. And my concern is my agent conveying information that I have assumed that it probably won't.

So as you can see here, we're protecting the resources. So now what you're talking, OK, I enter something in the prompt. That would be obviously now we need to talk about prompt cleanup and all of that, which filtering, which could be doable.

I mean, there's solutions out there that do that. I don't know if that's a partial answer, I guess, but it's a very specific. There's a way we can figure it out, I'm sure.

All right, any other questions so far? Well, I have one, if that's OK. From a practical perspective, what are the first steps an organization should take if they want to begin transitioning from traditional models like AIRBUG to a knowledge-based approach?

All right, so the traditional method, especially AIRBUG, role-based access control, I think the problem right now is that is the legacy stores where they are stored. Because the entitlements are actually invisible. You're a member of a role, but what does that role grant you access to?

Well, that's spread out in a gazillion apps. So I think the first step would be to bring something into a system where you can actually see those entitlements explicitly, a graph. So that would be the first step. Then you can still use your roles. That would make sense then. You can then use analytics, see clusters of roles, see similarities, nearest neighbor, and all kinds of crazy stuff. Thank you. Yeah. Haven't talked about knowledge. Thank you for sharing your knowledge with us.

All right, and give a round of applause, of course. Thank you.