Architecting Trusted Agents: Turning Knowledge Graphs into Secure Policy Engines

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: Architecting Trusted Agents: Turning Knowledge Graphs into Secure Policy Engines · Channel: Neo4j · 1:00:15 · Watch on YouTube

Topics: AI agents, Cybersecurity and software security, Data, databases and embeddings, AI developer tools

Summary

Alex Babanu explains why role-based access control often leads to oversharing and becomes difficult to govern as applications, APIs, agents, and MCP servers multiply. He presents a zero-trust approach in which every request is checked in real time by policy enforcement and decision points, with a knowledge graph supplying relationship and contextual information. The talk combines relationship-based and attribute-based authorization, then demonstrates how shared policies can govern human users and AI workflows across graph data and external sources. The demo also shows why authorization controls need to be paired with careful review of AI-generated answers.

Key points

Roles tend to multiply as organizations add applications and APIs, making entitlements difficult to track and increasing the risk of oversharing.
AI agents can inherit broad access through underlying roles and APIs, while their use of tools and MCP servers adds further authorization complexity.
Zero trust means verifying every request in real time rather than relying on static roles.
Policy enforcement points (PEPs) intercept requests, while policy decision points (PDPs) evaluate rules and grant or deny access.
Dynamic authorization can combine relationships in a graph with attributes such as location or time; the talk calls this knowledge-based access control (KBAC).
A knowledge graph can represent users, agents, workflows, resources, policies, and the paths that determine what may access what.
Modeling agent workflows and their permitted interactions can help prevent excessive agency, such as an agent calling an unapproved agent or resource.
The demo applies authorization to an insurance workflow spanning graph data, Google Drive, and AI agents, with different outcomes for an employee and a customer.
The presenter recommends deterministic authorization, open standards, auditability, and not relying on AI to protect AI.

Chapters

Start	Chapter	Summary
00:00	Introduction and the importance of security	The hosts introduce the topic and discuss why access control and agent trust should not be left until the end of development.
04:50	Role-based access control and oversharing	Alex introduces the talk and uses Microsoft Copilot as an example of how role-based permissions can expose overshared organizational data.
08:38	How role explosion develops	The talk traces how separate applications and APIs accumulate roles, leaving organizations unsure who has access to what.
11:55	AI agents inherit hidden entitlements	Alex explains how an agent can combine permissions from underlying systems and why adding agents and MCP servers intensifies the problem.
15:11	Zero trust and authorization components	The presenter advocates real-time verification and introduces identity, authentication, authorization, PEPs, and PDPs.
19:26	Protecting tools and agent workflows	The proposed architecture places policy enforcement points in front of MCP servers, APIs, and agent interactions.
22:10	From static to dynamic authorization	Alex contrasts static roles and access lists with rules-based decisions evaluated in the context of each request.
25:32	Representing access in a knowledge graph	The talk shows how graph relationships can express memberships and entitlements, and how paths support relationship-based access decisions.
28:48	Combining relationships and attributes	The presenter adds contextual attributes to graph relationships and describes the combined approach as knowledge-based access control.
31:00	Modeling agent workflows and permissions	Alex demonstrates how a graph can capture permitted agent calls, workflows, user access, and resource-level restrictions.
34:49	Questions about authorization approaches	The hosts and Alex discuss attribute-based access control, OPA, Cedar, and the role of explicit relationships.
38:25	Demo setup and authorization architecture	Alex introduces the open-source demo, its agents, gateways, identity provider, delegation chain, and insurance use case.
42:16	Insurance data and employee experience	The demo explores household and policy data and shows an employee using an assistant to answer questions about customer coverage.
47:10	Different access for customers and employees	The demo compares what a policy owner and a spouse can see, then tests restrictions on accessing company and Google Drive data.
53:40	Conclusions and audience questions	Alex summarizes the zero-trust recommendations, then answers questions about shared human and agent policies and verifiable credentials.
57:36	Closing announcements and resources	The host shares upcoming Neo4j events and learning resources, thanks Alex, and closes the stream.

Quotes

never trust always verify. — 15:43

The point here is that the AI is smart but your system here must be dumb. — 21:08

And that was the missing piece. — 26:36

No more role based access control. Please use your graph. — 53:40

Concepts and entities

Neo4j, Alex Babanu, Indicite, RBAC, Zero trust, PEP, PDP, OpenID Connect, MCP, A2A, ReBAC, ABAC, KBAC, OPA, Cedar, Indicite AI Control Suite, Knowledge Graph Access Control demo

Full transcript (original language)

00:00 All right. Um, welcome everybody. Good evening, good morning, good afternoon. Shuffling that announcement a little bit around. Um, and welcome to another Neo Forj live. Today the topic is architecting trusted agents turning knowledge graphs into secure policy engines. And uh, my guest today is Alex Alexandre Bab. Sorry, I’m I’m I’m now stumbling over my words. Babanu. I think I I I trained I I trained this but now I’m [laughter]

00:30 for some reason I cannot get it out. >> Get it better next time. >> Yeah, I’m sorry. I’m sorry, Alex. Um and you are the the product lead uh at Indicite uh responsible for AI um control suit um at >> super happy to have you um and um to join join us today at the at the NEOJ live stream talking about something I think that’s a little bit over overseen a little bit over a little bit maybe skipped sometimes maybe think of as as

01:02 an afterthought or maybe you know you realize ah well Let’s let’s not do the boring stuff. Let’s do the exciting things first. And uh and then in the end you realize, oh security, yeah, trusting my agents, they can do all kinds of things now. I don’t know if they really should be doing that or if they should have access to that or if users should have access to the agents using that. So yeah. >> Yeah. It’s funny [laughter] that you mentioned the boring stuff. To me, it’s the exciting stuff. >> Yes. Yeah. Yeah. Yeah. It it should be it should be the exciting stuff but with all these tools and things and powerful you know um

01:37 >> I think >> but you’re absolutely right developers think of security as the last the very last thing they want to do like they want to do their business stuff implement their use case whatever it is security is just an afterthought usually and and one of the problems is they when it comes to access control they eventually rely on you know roles because that’s the thing that’s been around forever and as we’ll see probably not a good idea Yeah. [laughter] >> Yeah. And and and you know GDPR, CCPA, these kind of things >> not as not as uh not as exciting

02:11 sometimes, but um but yeah, for sure. Um it’s it’s something that you are you tackled and and you will you will show us today um a little bit in our in our in our session today to make sure that this is actually you know kept uh in line is is not going uh going away is is is taken care of but is also something that um that if if you build something there um and you want to make sure that your your agents do all the all the cool stuff that they can do but still you

02:42 know keep in line and that that people access things that they are allowed to access and other people who are not allowed to access things are not allowed to to to access then I think this session uh is for you. You you gave a very interesting example in um in in when we were crafting the description of the of the session saying, you know, is it is it is it okay if if your agent has has the rights to summarize confidential AR files or is it is it is it fine if if somebody can see the the salary of of of leadership team or or gets access to,

03:15 you know, crucial um files is is like, okay, you you probably should take take a look at that and think about okay, what what is what is who can access what what access what access is allowed and in what level and um and if it’s just an agent that can do it. Yeah, it’s important that the HR team can have access to their own HR files but you know the intern maybe should not have the same level of access. [snorts] Yeah, it gets even trickier with a graph rack for example where you can ask anything to the graph but yeah exactly if the you

03:47 know confidential data is in there uh maybe you’ve embedded some documents that you shouldn’t have access to uh and we’ll see it’s tricky it’s even trickier with AI and and I’ll focus on on the AI aspect as well today because that’s probably top of mind for a lot of people. >> Yeah. >> Yeah. >> I I can imagine. Yeah. [snorts] Um cool. I think um yeah we could uh we can probably dive in um I want before handing it over to you Alex just you

04:17 know the session is live obviously as we are as we are running it right now um if you have any questions any comments anything you see you’d like us to explore some more or you like us to give a little bit more of a of a explanation on something then please um type uh type it in chat put it in chat let us know we will have some time um towards at the end for sure to do a little bit of a Q&A or sometime in between. Um so um definitely you know the the the channel is open and and we’d like to encourage you to to make this as uh interactive as

04:50 possible and um yeah I think with that I can uh >> Cool. >> Oh thanks thanks Alex. So, it’s Alex’s today. Uh, it’s Alex Tuesday. Uh, here in North America, it’s taco Tuesday, but you have tacos. So, uh, yeah, I’m the lead product manager for AI control suite at Indicite. So my product controls enforces access control for AI, agentic AI and AI workflows using Neo forj as

05:23 the underlying graph and using the indicite platform which is an intelligence layer on top of Indicide that makes everything uh easy and smooth. Uh my background is actually identity and I stumbled upon graphs about 10 years ago while trying to solve some identity problems that only graph database could handle like complex relationships in IoT systems for example that was uh I even talked about this at graph connect back in 2018 who cares anyway so uh so today we’re going to talk about turning your uh graphs into

05:55 policy engines now uh as I mentioned earlier when we were chatting uh A lot of you think about role based access control have that so we’re good right well unfortunately not um and I’m going to start this by talking about copilot Microsoft copilot um you probably know it you’re probably using it have used it uh your AI companion so why copilot why am I zeroing down on on on that uh that’s because it’s notoriously using rolebased

06:27 access control in the back end it uses the whole Microsoft suite Active directory entra what have you all the groups and roles in there and so whatever you you you run through copilot uh well it goes through that authorization system uh now copilot is just an example but any system that us an an AI agent that you use uses roles as a backend authorization system will behave exactly the same I mean in terms of authorization of course now what’s the problem with copilot well here’s uh some results from a study earlier this

07:00 here like two three months ago maybe three four months ago uh about this concentric AI released this report that they found a bunch of risks associated with copilot uh for example 83% of the at risk files are overshared that means if you have some files that are sensitive like most of them are overshared uh 17% were overshared with external third party even like some of your critical files may actually be accessible by external people 90% of business critical documents are shared outside the sea suite. So things that

07:35 should be only for your seale executive eyes only are actually a lot of them are actually shared to everybody. Um 15% of all business critical files are at risk of from oversharing and 3% of active sensitive data was shared organizationwide. So obviously we have an oversharing problem uh which means that uh you have data, you have documents and the risk is that a lot of people can’t see them or access them and they shouldn’t. Why is that? I mean you

08:07 you may think well this is Microsoft’s problem right? Well no because Microsoft tells you this is part of their documentation. You can have a look. Copilot only accesses data that an individual user is authorized to access based for example on role-based access controls. So there you have it. It’s not their fault. It’s your fault. If all these statistics that are [laughter] real, you know, real problems in organizations, not their fault, it’s your problem. But I’m here to tell you that Microsoft doesn’t make it easy for

08:38 you because actually it makes it impossible for you. any system, it’s not just Microsoft, any system based on roles only will uh cause you the same problems. Uh and here’s why. What’s the problem with roles? Well, they multiply over time. You tend to have more and more and more roles until you end up with a system where you don’t know at all who has access to what anymore. >> And this is how it’s going to to happen. Like basically, and I’ve seen this as a consultant. I’ve seen this in the field.

09:10 I’ve spent 10 years consulting with fortune for Fortune 500 companies, whatever. But all of them had this problem. All of them. And I’m pretty sure if you work for an organization that’s been around for a couple of years at least, yourization also has this problem with ROS, whether it’s Microsoft ROS or other. So how does this work? Uh the role explosion problem starts when you’re starting to you know starting to building building applications. uh you build an application, your developers or if you’re a developer, you create some

09:41 roles for managing access to the data or to the features of your application and everything’s fine. A bit later on, uh your organization builds some say APIs or more applications, but you don’t want to break whatever you’ve done before. So, you’re creating more roles. After some time, uh people who created the first roles leave the company, move on, win the lottery, whatever. and you end up with roles that nobody owns anymore and nobody has any idea what they do. Uh so eventually you end up with a blind spot. All you can see is the role

10:14 membership. We dive a little bit into that because that’s quite important. Here’s uh the example spelled out. So let’s say that you build an analytics portal uh for customers and staff to create and access and manage their own analytics based on your graph data. Something really cool. Looks good. And for that you need a couple of roles like uh for example analytics managers they can view everything and the regular users they can only see their own things. Great. So these are the roles defined in the analytics portal

10:47 application itself right and you have now an organization directory could be enter ID Microsoft active directory your own uh uh directory LDAP direct whatever it is and there you have your group memberships and your role memberships. So for example, here we have Alice and Bob are analytics managers and Rebecca and Roy are analytics users. Great. So whenever say Bob logs in, he’s a manager. He can view and see all. Cool. Phase two, you now have uh some data

11:20 APIs. So now you need to create, as I mentioned, a couple of new roles. You have a data viewers that can only view their own stuff and data admins that can crud everything. So because you have a new uh you know a new API you need to essentially create new roles because you cannot reuse the same roles they have different accesses right it’s not the same set of people you see for example uh Roy here would be alone I mean you can’t reuse the roles so you have to create new ones uh so you create new ones so at the end of uh in step three now you have after some time you have

11:55 probably you know hundreds of thousands of roles actually a lot of organ organizations have more roles than than employees. So that tells you a lot those organizational directories where you have you have all the group memberships but you have no idea what the they are entitled to because the entitlements are spread out in all these apps you’ve had, right? And now enter AI. So you’re deploying this AI agent and and now Rebecca, one of our users wants to use that agent for you know some

12:29 graph rag stuff for example or for data retrieval what have you or for running for asking analytics type of questions. Remember Rebecca was part of the analytics users and she was also part of the data admin role. So now when Rebecca prompts the AI, she has actually these entitlements, but you don’t actually see it explicitly. They’re, you know, they’re hidden in the actual underlying databases and APIs, right, that the AI can access. And so here’s your AI now that has a CRUD all access. Uh the AI is not an API. So the AI can decide on its

13:03 own what it wants to do, what it wants to, what it based on its goals. And >> here you have an AI now that has a CRUD all access to your data. >> That may be a problem. And actually this is kind of the behavior we see in the news. The agent did something and we don’t know why. So this is a nightmare for governance for GDPR as you mentioned for any regulatory things. What happened? Well, and you see this on the news all the time that the AI dropped a

13:34 database. it use this it it and that’s exactly the problem especially with scope pilot or any role based access control system. So what can we do? Well, hopefully oh one last thing cuz so now we’ve seen the oversharing problem but now let’s have a look at another problem which also lead to road explosion and that is the AIS as we know they need some tools to do anything they need the MCP now model context protocol has become kind of the

14:04 the most uh popular protocol for accessing tools so we have these MCP servers so any AI agent now can find online a bunch of MCP servers each one of them you know exposing a certain number of resources and tools. So these you know resources and tools may vary from a server to another. So the question is now how many roles do you need to protect the system? You have X agents running in your uh organization like we’re talking to big banks or

14:38 multinational companies and they have they don’t even know how many agents they have. They might have thousands for all they know. uh and you have MCP servers that are also maybe in the hundreds and how many users do you have like 10,000 even 1,000 even 100 users. So now how many roles do you actually need to protect this system? Your cardality is going to explode really fast here because if you need to secure this particular guy here [snorts] uh and Rebecca should only access this guy, how many does Rebecca need her own role for

15:11 that? So from the get-go, you’re getting into this role explosion problem with AI right off the bat, even forgetting the other explosion you already have at hand. So you need a better system is what I’ve been trying to tell you. So again, these are the risks. So we need to shift from away from roles to dynamic authorization. So let’s have a look here at what that means. That means essentially we need to adopt the pre the paradigm of zero trust. This is

15:43 a fancy thing that’s been going on for a while in the identity world but it it absolutely needs to happen for AI. The the main concept with zero trust is never trust always verify. So instead of relying on static roles you need to authorize every single action. every single request must be authorized at the time when it’s made in real time dynamically. That’s the only option here and we’ll see how this pans out and how you can use your graph for that. So

16:14 before we get [clears throat] into the details, we need some background uh so everybody is on the same level and we’re talking about the same. So couple of concepts about that are more on the ident. uh maybe you know this uh just close your eyes in that case uh if you know it’s always good to have them spelled out again. So there’s two main things when we talk about access control and this apply to AI control as well. Authentication on the left and authorization. So authentication is like the main gate to your castle is the front door is where you check for

16:47 credentials is where you log in and once you’re in you’re in you’re in the castle you’re good. authorization is uh what happens afterwards? We know who you are. You’re in the castle, but what rooms can you access? Can you access the treasury and steal steal the gold like this guy here? Uh that’s what we’re trying to avoid with AI, right? So, authorization is actually the hard problem. Authentication as we’ll see uh is easier. The first thing is that we need

17:19 to talk about identity. you whether it’s human or machine, you need some kind of identity or at least an identifier to identify the running instances of the things that are making requests in your system. And once [snorts] you’ve got that uh you can authenticate like users usually use multiffactor authentication these days or pass keys if you fancy great and machines are typically authenticated with cryptography. So authentication is for the most part

17:51 problem solved. Authorization though is a harder problem. So how do you do authorization? So typically that happens when uh a a subject that has been authenticated a machine or a human tries to access a resource. So zero trust paradigm says you need to verify every single request. Now to do that you need a couple of more components in your system. uh namely a policy enforcement point, a PEP, and a policy decision point, a PDP.

18:21 These act together. The PEP is a proxy that protects every single resource that you have. Uh it’s like a proxy, could be an API proxy, an API, uh an MCP gateway, an agent gateway, some kind of a a thing that filters all traffic. Uh now note that this is valid for for the whole stack from the network all the way to the application layer. uh you can have network level peps like I don’t know switches and what have you routers and then gateways and API gateways and

18:51 things like that. So these things capture so technic technically these are already products that exist so you can just use them. Uh so PEP will capture all traffic redirected to a policy decision point which has a set of access policies business rules implemented. So these are rules engines that reason on the incoming request and respond typically grant or deny. Now the communication between the two uh nowadays is standardized through a protocol called Ozen v by the open ID foundation. I’m one of the co-chairs but

19:26 it’s been gaining popularity. So this enables any pep to talk to any PDP out there. So that’s what we’re trying to achieve with AI as well. We need to implement PEPs and PDPs. Now, this little uh spoiler here, spoiler alert, the PDP will be where your graph will leave and we’ll get to that. So, how do you protect agentic workflows using this concept of zero trust? So, again, back to our AI agent that uses a bunch of MCP servers. The idea then is

20:01 to put a PEP in front of them. Uh now the good news is that there are number of uh MCP gateways that are commercially or open source even out there that can be used for the purpose. Uh we have our own uh but you can you know whichever and these should talk to a PDP a policy decision point via odds end. So every MCP request that tries to access an MCP server has to go through a gateway of some sort first which communicates with a policy decision point and then grants

20:32 or not the request. Simple. But now uh AI can also use you know kind of legacy or REST or GraphQL API calls as well. I mean there’s a movement that says we don’t need MTP. Fair enough just protect that as well with a PEP. Uh now this is more traditional. We have API gateways out there. some are open. You can do that as well and bring them into this oddsen kind of circle of trust if you will. >> Um so that’s it. The point here is that the AI is smart but your system here must be dumb. Uh you use uh

21:08 deterministic rules as much as possible. If you try to rely on another AI to protect the AI, can you trust that AI? And it’s AI all the way down. So anyway, ideally you want you want as deterministic rules as possible here. So what about workflows? So an agentic workflow is when several agents collaborate together to achieve a goal, a common goal. Uh and now there’s another protocol called A2A agent to agent that’s been uh put forward by

21:39 Google last year or the year before forget the exact date but anyway now agents can communicate discover each other. They have agent cards that describe what they do, their skills and every agent can discover another agent and they can just communicate. So we have now these agentic frameworks. Uh so how do you protect them? Well, same idea. You place a PEP everywhere and down there is where you have the PDP with your the graph as a context and this is where the context is is going to be really really necessary to figure out

22:10 the whole thing as we’ll see in a second. Uh so that’s the idea. the bare the base idea as you seen is placing peps in the right places and using a policy decision point uh to grant access. So now that we’ve seen the architecture from a high level how do you actually write those access policies and this is where I mean we call this knowledgebased access control because we use a knowledge graph and we’ll get to the details but you need to talk about access policies. So there are two uh schools of thought here. Uh we have dynamic authorization

22:46 and static authorization. As a reminder, static authorization is for example your roles. This is what an LDAP entry looks like. If you’ve never seen one, this is what it looks like. This is what is stored in an LDAP directory. For example, Azure AD or ENTRA for example. This describes a group called HR managers. And all you can see in there is a bunch of members. It’s written in stone so to speak. LDAP directories are are very slow on write so and very fast on read. So they’re not expected to change very much very static. Uh and

23:19 here’s how for example a role would be embedded in in some spaghetti code in some app. So for example it’s hardcoded there that in this particular app that managers can do this or that. So it’s very hard to make sense that of who has access to what because on the one hand we have these members and you have 10,000 apps each one and with their own code in there. Our access control list are very static also. This is what Linux uses or any Unix based systems. It’s how the file system is protected. Works fine on Linux but at enterprise scales it

23:53 gets a bit more complicated. I don’t want there’s some systems that use that modern systems but I don’t want to get there now. as opposed to that. So this is bad because every one of these systems leads to explosion. Uh over time you’ll have a more more and more ACL you have more and more roles as we’ve seen. So instead it is better and actually advised to move to dynamic authorization. This is what uh these are authorization systems that rely on rules engines uh as I mentioned and rules uh you need much

24:25 fewer rules than you need roles. Maybe you need a 100 rules and that could replace you know a thousand rules. I don’t have specs here. Depends on your use cases but much much less much more manageable. The idea is that these things uh taken as an input a subject who wants to access a res. This is all happening in real time. A subject is trying to access a resource. Here’s the context. The subject is located at this uh geol location at this time of day for example. Can they access the resource? it happens in real time and you get a

24:57 grant and deny. Some events may happen that change the underlying data or rules or what have you. Uh but it’s okay. It’s all dynamic and happening in real time. This is exactly what we need. So uh what this looks like I mentioned between PEP and PDP we have the oddsen protocol and this is what the protocol looks like. Uh it’s essentially a bunch of JSON payloads that are exchanged. Uh this is a request and you see that the request matches uh what I mentioned here in the in the diagram. We have subject here Alice tries to access tries to read

25:32 uh a resource called account count account count one two three and at this time of day. So now you can crunch the rules engine crunches that and says decision true Alice can access the document. Great fairly easy right? uh so what I’m saying so now because we all are graph practitioners here or should be uh as we know uh so how do we shift from rolebased access control to something that uses a graph well the first thing is to represent maybe if you

26:04 have roles everywhere a first idea let’s put all those roles in your graph so for example this expresses the same thing this is statically written in an LDAP directory somewhere and this could be stored in your Neo Forj database uh and expresses the same thing. Uh those two users are managers. So now if we just focus on this, we’re not talking about role-based access control anymore. This is relationship based access control because we look at relationships. But

26:36 now the beauty is that we can now represent entitlements as well. And that was the missing piece. Uh if ROS were from the get-go represented as graphs, actually they would not have been a problem. At any given time, you could have known who had access to what and you could have reused roles or you could have, you know, managed the access properly. But they weren’t for some reason. They shifted from from this representation to LDAP which actually hid everything. So now you have your entitlements, you have your managers,

27:07 they can crude all the data API. Uh actually as a as a point I just want to point out that if you look at the people who created rolebased access control in 1992 Ferolo and in their paper that created rolebased access control this is exactly how they actually represented RO membership >> users members of Rome right >> so there was a graph from the beginning >> yeah yeah >> so why why did we end up with directories I don’t know there was something I suspect Microsoft

27:40 >> [laughter] >> No, actually probably not true. It was It’s probably Netscape. There was a Netscape directory first. LDAV v3 happened. It gained popular. Anyway, if we kept that idea, we would be better off. But unfortunately, it’s not the case. And >> there was no database around that could do it back in 1992. [laughter] >> Yeah, [snorts] true. Actually, uh yeah, semantic web 98. So that’s what we ended up with. Um actually even a relational database could have been better because you would

28:12 have been able to model th those guys here at least. Anyway, uh moving on. So this is what relationship or rebback access control uh works. It looks at path. So for example, if you wanted to know uh what Jay do down here had access to, all you have to do is follow the path and figure out that okay, Jay do has access to data API and document one. And you can uh and actually you can tell here in this particular example that you can read data APIs and view document one and you can expand that idea uh at at infinity

28:48 in your in your graph right but it it’s not just roles now you’re free to use any kind of node or types as you want for example here we have organizations it’s not just roles anymore it’s whatever you want so you’re now free uh to have any kind of access controls using paths and relationships as you want in your graph. Isn’t that great? >> Um, so but we’re still missing something those environmental conditions, you know, like the time of day, geoloccation, or something that is based

29:21 maybe on the access token presented because all of these when when you’re logging in, you get an access token and MCP insists on on OS for a authentication and authorization. And so maybe you have some some things that need to be checked. So you need some attribute conditions as well as relationships. Uh attribute condition are actually systems based on attributes are called attribute based access control systems or Aback which is also another type of dynamic authorization. Well, we need to combine the two to get

29:51 full context and proper uh access policies. So this is what we have. Rebback on the left, Aback on the right uh equals Kback. So Kback is essentially the whole thing. That’s what we call it. We’re probably the only ones calling it that. Uh but otherwise the I think the scientific name name for this is attribute enhance relationship base access control. So ARback kind of a mouthful. [laughter] [snorts] So you have now uh the movie the all the pieces of the puzzle for uh your control system. Uh this is for

30:26 example what the kback policy could look like. This is how we represent them. You don’t have to do it the way we do but you can as you can see here you have a cipher part which is the relationship access part and then you have some conditions on the uh that are added to that. So we could we combine that in our rules engine in order to grant access or not. So we need we check the path and if the pass checkout we also check the conditions essentially. Uh so that’s just an example of kback or a reback if you wanted to be more academic. Um so

31:00 now you have uh your knowledge graph. It has you you should enhance it with identities, policies, re resources. So you have now a full identity and context knowledge graph. It contains not only your normal knowledge. But if you enhance it with identity and identity related context, you have a full picture that you can now use for access control and maybe to have insights such as for example who can access what which is again invisible in traditional role-based control systems. So how do you use this for AI? And this

31:34 is the last piece of the puzzle. Let’s say that you now have those agentic frameworks and workflows and you can now model them in your graph. For example, I have here a simple graph that models a workflow with three agents, two agents and an MCP server. Say agent one, agent two, agent and MCP or agent three, whatever. So at runtime, uh we have agent one here that calls agent two and we have PEPs everywhere. So we can track all these communications. Uh so we look

32:07 at our reference graph here. Agent one can call agent two. So so this is okay actually. But now agent two here for some reason decides to call agent 4. Well, wait a second. If we look at our graph here, agent two should never call agent 4. It should only have access to an MCP server. So, this should not be allowed. This is excessive agency. The agent two is trying to something. It’s we shouldn’t let it do it. So, that’s how that could work out. For example, uh so let’s have a look with a proper

32:40 graph. So let’s say this is a graph that we have that represents two workflows, two agentic workflows. The first one is a data search or rack type of thing. Graph rack type of thing where uh you know we have a transaction here goes through a chatbot uh and in the case of the search it goes through a retriever agent and then uh to fetch data from the graph and then a generator to generate the answer. Great. Uh there’s also another uh workflow that is maybe a

33:11 start compute and this one actually goes to the same chatbot but this one uh manages cloud instances maybe starting or shutting down VMs or what have you creating load balances what have you and whenever that’s done uh it communicates with another agent to notify users through Slack for example. >> Mhm. >> Great. So we have these two workflows modeled and right off the bat we can see that the cloudbot should never be able to retrieve data. There’s no relationship there. So we should be able to block that right off the bat and prevent that communication alto

33:43 together. Now let’s have some users. So we have uh four users here. We have Alice that can actually start the search. We have a couple of salespeople that uh can actually also stop the search transaction. And we have Bob here who’s probably a DevOps because he can start the compute uh workflow which starts or shuts down VMs. Uh Roger here should not be able to start the to do that only Bob uh because again we we identify these relationships. Uh they have different types and so we can figure out which

34:18 one’s which and have access policies as we’ve seen before to do that. And here you can go as granular as you need to be. uh you can tie this to your actual data and create the relationship rules as we’ve seen in as granular up down to the data or node property if you if you need to. Uh so that’s essentially how how this works. So now that I’ve shown you this, I just wanted to show it to you in action. >> Cool.

34:49 >> To prove my point. >> Yeah. >> Yes. Shall we do a quick quick round of questions first or Sure. or Yeah. the And I’m sorry I’m not 100% familiar with all the acronyms, so I’m I I might be uh stumbling over them a little bit, but there was one and you mentioned this this Aback. So there was attribute attribute based access control, I think. >> Yes. >> Um and Sai asks, what’s your view on on Aback setup plus opal? And I’m assuming

35:19 these are also abbreviations I’m not too familiar with. Um, >> opal is that the uh the OPA orchestration framework probably open policy agent. >> Yeah, that could be that. Yeah. Okay. But if you are not familiar maybe maybe Sai can can um give us a bit more what um what he actually thinks about this. I mean obviously ABACK has been around for a while as well and it’s it’s a good way

35:50 of uh uh of implementing dynamic authorization. Uh the the the idea with attribute based access control is every all the rules are based on attributes that you can gather at runtime uh and have access. So you end up with actually much more uh rules with Aback because you you might have a lot of attributes but what you’re missing is the relationship part. Uh I think it’s quite important the the the context and OPA doesn’t have that either. Uh OPA or Opal

36:21 if that’s what I’m thinking it is. Uh again bringing the data to OPA is complicated and you’re missing out on the whole relationship part which you can do if you implemented something like a Zenzibar system. Uh but even there the the hubs you need and the it’s like more like an ACL type of system with relationships. Uh I mean it’s good as well as long the point is I think you need the relationships to have the full context for AI. >> Yeah that’s >> yeah I think that goes similar more like

36:54 a comment and then probably a question from from David. David says, “Abeback with alpha um is something that you could do. Alpha scales better than Cedar Cedar.” Um lots of abbreviations today. So um which I’m sorry I don’t I don’t know what what they all mean. >> Yeah. No, that’s fair. So uh Cedar is a policy language by AWS. It’s been open sourced. Uh David is if it’s the same David that I think it

37:24 is is one of the coordors of alpha which is a standard a JSON standard for Aback based on an older standard called Zakmo more abbreviations which has XML [laughter] that one you don’t want to get into. Uh I mean again listen I mean they knows this but I think relationships are really the key component that all these other systems are are missing. they’re not quite explicit or expressive in the same way that a graph database is. Uh

37:54 you can like what you see on the screen here. It’s hard to make sense of this uh with aback just you have to I mean David probably knows how to do it but you probably need a bunch of rules to get to the same idea uh that you know following this path here uh you know grants you access for example. >> Yeah, makes sense. Um yeah, I I see no uh no other questions, but um if you have uh any any more, especially probably maybe when uh when Alex shows

38:25 the demo, then please please let us know um in chat and don’t be shy. Just just put them in and throw any abbreviations at me as you like. I’ll uh I’ll just read them out. [laughter] >> Nice. Yeah, put putting graph people on the spot. >> Yeah, [laughter] >> good sport. So um the demo I just want to mention that this demo is actually available uh to everybody on our open source GitHub. We have these demos are available to developers. You can run it

38:57 locally. I’m running it locally on my machine here. Uh and you can achieve the same as me here, but I’m just going to show it to you. Uh so this is what the demo looks like. I know there’s a lot of boxes and arrows uh but it’s not that complicated. So we have a bunch of we have our graph database that is uh kind of hidden behind the indicad control pane. I’m using indicite for this because that’s my tool I have at my disposal here. But the ideas are the same regardless of of the tools you use. But Indicad’s a good platform obviously.

39:30 So we have some agents that allow us to perform a couple of uh a few things. uh we have an orchestrator agent that takes some prompts from a from a human and the orchestration can decide whether the prompt pertains to data retrieval in which case it delegates that to a a data retrieval agent or if it’s pertaining to some documents that are show stored in Google Drive and I’ll show you that in a second. We have some Google Drive documents uh through MCP as well or

40:00 whether the prompt pertains to the weather. I mean stupid example but this is just to showcase that you can make external rest calls to external references directly at runtime from the platform. You don’t have to store all the data in the platform. You can just point it to some other place where the data is actually stored and use it at runtime. Anyway now all these agents are pro protected by our own PEP, our own uh gateway. Uh so we have one all these peps here. Mhm. >> Uh so we have a PEP in front of our orchestrator of of our retriever in front of the Google MCP drive and we uh

40:37 fetch the data. The retriever fetches the data from our knowledge graph through the MCP RMCP server which grants access to our oddsen tools and some queries that we have some knowledge queries which uh essentially exposes our context IQ query knowledge queries to access the data. Now all of this is protected by uh yeah the platform for authorization and from an authentication standpoint we use an external identity provider in this example it’s security

41:09 uh and this uh identity provider authenticates users and machines uh through OS and so it also does token exchange for us. So what happens is we want to what we want to authorize is not just the user or the machine but actually the whole delegation chain. It’s the user when using the agent. That’s what we’re authorizing. So, we need to track the um authorization chain, the delegation chain all the way to the bottom in order to have a complete picture of what’s happening. So, when this human gets down to this

41:44 retriever for example, the authentication the delegation chain should have the previous agent as well in it. So, we know that we can authorize the full workflow. Now, of course, the data comes from various sources. It could be CRM, HR, some custom databases, some documents from SharePoint. Uh, and we’ve also encapsulated some roles and all that in there that come from SharePoint. So, we have a whole bunch of stuff in the knowledge graph. Hopefully, this makes sense. So the use case here is we are an

42:16 insurance company and uh dealing with claims and what’s important in this insurance company is the households and the relationships between household members who’s in the household their children and the vehicles they have and the vehicle insurance policies and house insurance policies and and whatnot. So so let’s have a look at what that looks like. So first of all I’m going to show you uh the actual uh data. This is the indicite platform and this is what the

42:47 data looks like. So uh this is for example one of our customers uh James Mitchell. We we’ll see him again in a bit. Uh James uh is in the household. He’s the parent of uh Ethan. Sarah is his wife. Sarah is the policy holder of the home insurance. and they have an estate and they have a mortgage and they have a bunch of insuranceances. Great. But as you can see here, uh we’ve have been tying this to some workflow definitions here. Uh so customers James

43:20 in particular can trigger a couple of AI workflows uh that are tied to some agents and we’ll see that in a second. Those agents I showed in uh in there and we also have some departments. Some some of our users are actually employees and some other users are customers. James is a customer. Uh but if I were to look at uh some other uh sorry clicked the wrong button here. Uh for example, where do we have millen here is an employee. So her

43:52 view is a bit different. she reports to another person and she works the department. Whoever works in the department is an employee basically in this simple use case. >> Uh this is what the schema of the database look like. This is the u the ontology of the data if you will. So persons uh can trigger workflows, workflows have agents, uh persons working in departments and this is where we tie it all together. the the access stuff is more on the

44:23 workflow side here tied to the data stuff which is more the insurance policy specifics. So that’s what the data looks like uh on the platform. So I have here uh an app that is our insurance app. I created this with my friend Clo. So [laughter] it doesn’t look very good. >> Yeah. So I’m first going to log in here as a user Millisent. So, Millisent is uh a customer support uh employee at at our secure home insurance company.

44:59 So, uh this this app actually is just there to show you that uh this app just uses the rest endpoint. It uh everything you see here uses the rest context IQ knowledge queries. Uh, for example, if I have an a household lookup here, uh, hopefully if I click this, uh, yeah, for example, I can look at Sarah Mitchell. It’s very static, you know, but at the bottom here, I have a little chat window. And this little chat window um, actually triggers the workflow I showed

45:34 you in the slide earlier. So, here I can ask a question and it will trigger the whole workflow. Uh so for example just to make sure our AIS know uh who I’m actually logged in as uh I’m just going to ask it who am I and you’ll see here a bit of a a trace log from all our PEPs our gateways. Uh so the request went through first gateway millent went is authorized to access uh the orchestrator agent. She’s authorized to access the retriever agent and she’s authorized to

46:04 access the MCP server. Uh and yeah we have an answer. This went through the MTP server which got the data from the knowledge graph. You are medicent a customer service representative. Great. So now uh as you see this data here that that I got from rest is very static. Uh but she has a question from James uh the customer and uh James is calling about the home insurance for his house at 123 Oak Avenue. What can he see about the policy? So he’s asking a question uh

46:36 because he’s not seeing something. He wants to know why basically uh instead of looking at the static thing well just asked the AI. So this goes through this actually runs on my machine while it’s thinking. I can show you uh what this looks like when you run this. It’s it’s doing a bunch of things. So it’s going through the whole workflow here. And as you can see, uh, James, uh, just sees some basic house coverage here. Uh, but let’s see.

47:10 James, we know that, uh, uh, he’s married to Sarah. So, let’s let’s have a look at what Sarah can see and and see if we can determine why James doesn’t see some things that he sees. So again, this square is the graph in the back end and u hopefully we’ll get something. There we go. And Sarah can see a bit more things. You see uh James can only see the coverage but Sarah can actually see numbers because she is the policy owner. So actually why that’s the question that James had when he called in the first place. Why can’t James see

47:43 the premium? So again my static thing didn’t answer that question. I mean I can see the household >> uh but I cannot say why James doesn’t see the premium. So this is why we’re asking our friend EI. >> Uh James cannot see the premium for his home because according to the system records he does not currently have an active home insurance policy. His spouse has the premium. So he cannot see it because his spouse has uh the thing. >> I see. No. >> Now uh this family has a bunch of uh children. They are of driving age. Uh so

48:19 I know in our Oh, I should show you the Google Drive. We have a Google Drive here with some shares. So these are some documents uh in Google Drive and they’re actual documents. They’re demo documents. They’re not uh but these are documents that pertain to customer insurance. There are some other documents that come from SharePoint that have been embedded and stored in the database. Uh but this this question pertains to uh the the customer related policies uh insurance policies in our Google Drive documents. Our car sharing

48:53 drivers covered in our umbrella liability product. It’s probably a question that makes sense for insurance practitioners. Um so now there’s one thing uh let’s see let’s see it crunch. So this what happens here is you see the the flow here is different. Now we went through a different flow uh in agents because now we’re accessing the Google drive. So we have a different set of agents that that are called upon and are being authorized in real time and we got an answer. Not going to read it. Now there’s one thing

49:25 here that uh I want to mention is we have a company policy that persons and vehicles this thing here that I can access rest this list here should not be available to AI at all. So for example, if I ask can you give me the list of persons and vehicles which should really return this list, right? This persons and vehicles.

49:57 Let’s see what happens. Again, we have a policy that says AI should not access that. >> Yeah. >> And let’s see what happens. I’m sorry, I couldn’t find any information regarding the list of persons in services. So based on context uh we can or not authorize uh if it’s AI or not AI we can authorize at the fine grain grain level here using you know the the all the stuff I told you about. So let let’s have a look at what a customer would see here if I log in as James. Uh give me a

50:28 second here credential. So here I’m going to log in as James. So, James, whoops. Ah, sorry. Wrong paste. There we go. So, James has a different view of the app. Obviously, it’s got a very limited view. He can only see his own household. Great.

50:59 >> Of course. Yeah. >> Yeah. So, now let’s have a look at this. He’s also access to the um assistant. Remember I I showed you that there were some relationships there. Um so for example here uh let me ask you the same question. Can you give me the list of persons and vehicles? Now in this particular case uh James should be able to access details from his own household. So it’s different policy that will trigger here.

51:30 >> Um >> so hopefully he should be able to just see his household. Yep. Uh so again the power of the context here uh hopefully [laughter] >> yeah thanks oh couldn’t find information well worked earlier uh but anyway [laughter] the data is protected it should have triggered another but let’s see if we can uh ask the same question about the Google drive uh

52:03 because the Google drive is actually a protected resource by the company. So James should not be authorized to access that drive at all. Uh so as you can see here, not allowed. Interestingly, it’s still triggering. Well, that’s [clears throat] problem with my workflow, I think. Uh anyway, let’s see what happens. I think the the orchestrator is trying various uh things here now. >> Yeah. Yeah, they can get very creative to uh [laughter] >> interesting. You know, I tried this

52:35 before uh our session and it was working as I would expect. But this is the problem with you never know what it’s going to do. Uh it’s still thinking if we’re looking at this. >> It got the answer now I think. >> Oh, it got Yeah, based on available policy documentation, the secure home premium. So, it got this from uh Okay, there’s not explicit mention. So it tried to get this from the database. Interesting. I think it’s inventing stuff now. >> Wow. Interesting. It was not authorized to access the Google drive though. That’s the important part. So it tries

53:07 to get something from our MCP. Uh that’s not an answer in MCP. Interesting. So this is where uh you see in real life in this didn’t happen in my test before. Um so there you have it. So that that’s in essence what that would look like. Uh if I go back to my that’s the gist of what I wanted to show you. So you can what we’ve seen here is that uh using context and and proper access controls you can really protect your data like the stuff you’ve seen at the end is not in the

53:40 database. [laughter] >> Yeah. >> So double check what AI tells you. Um so to conclude really always verify never trust anything. So verify every little request. No more role based access control. Please use your graph. Uh and use open standards wherever possible. OS odden and externalized authorization because those external authorization systems will provide you all the things you need for governance as well. Uh they will tell you why something happened. There’s an audit trace. Uh if you want

54:14 to know why an agent did something, you can actually find the answer to that. And last thing, you can try whatever I showed you for yourself. It’s this GitHub repo that you can have fun with. >> That’s it. >> Cool. Super. Thank you very much, Alex. Um the link to the repo is obviously um in the YouTube video description. So if you if you look for it and I’ve posted it in chat as well. Um we are close to end of the the time we have available but Alex there is one more question coming in in chat from Phil which I’d

54:44 like to to read out and maybe you can you can have a stab at answering this. So, Phil asks um if enterprise authorization is represented as a knowledge graph using arbback and rebback relationships, can AI agents be modeled as first class graph subject whose permissions are derived from the same authorization paths as human users rather than through a separate agent permissions framework. >> Uh yes, actually there’s no separate framework uh here. uh what you see what I showed on the normal app the static

55:20 user you know web app >> that’s for humans and uses exactly the same policies I don’t have different policies it uses exactly the same graph uh but it the context the policies are such that in the case of AI they they provide different outcomes so yes it is possible and actually this is exactly how it’s been implemented >> yeah Cool. And then a good a good uh comment from from Ross on on on the on the you know behavior I think we just

55:52 saw is the AI agents are nothing if not persistent and often uh inconsistent. It’s amazing technology that’s very true. [laughter] >> So yeah you should never trust it right which is why you don’t want to protect AI with AI for example. >> Yeah yeah for sure. Um and then we have one more question from Michael. Michael asks, “Can this be used with a and that’s another abbreviation throwing at me, DIDCOM based agent network?” DID >> I don’t know. >> Okay. Did so this is this refers

56:24 probably to distributed identity. Uh didcom would be probably a method. Uh yes. Uh in fact uh we uh in my before indicator I did a demo uh CTO startup called three edges and we did a demo exactly like that where uh verifiable credentials we we use did web I don’t I don’t know didcom but hopefully similar enough verifiable credentials are uh cryptographically stamped uh JSON payloads if you if you will that can be distributed to attest

57:00 something say for example use case is I have a certification for plumbing and I have this certificate on my phone wallet and I can share it with someone. An agent could carry similar things. Uh you know I’m an agent. I have my verifiable credential that uh you can trust me because it’s been issued by these people that you trust and yeah you can represent a credential like that in the graph as as a node and actually it’s pretty powerful because you can relate to issuers to holders to verifiers and you can track in real time the whole

57:36 evolution of these credentials. So absolutely it would be a great way to and I I have a demo somewhere from my good old days when we’ve actually done that. >> Super. Um that leaves me with one minute. Um I’d like to announce the next stream we’re doing on the 30th of September. So that’s in two weeks time where Jose will join me um and um we’ll talk about agent memory for.net persistent AI agent memory engine. So that should be a a fun

58:08 fun session on agent memory for specifically for uh uh for the agent memory um you know solution on.net um nodes um obviously um is is approaching ever ever so uh fast fast coming to our way. So I’d like to share um also road to nodes with you. We have announced the agenda to notes 2026. So if you’re interested in that, check out the notes website. If you’d like to participate in a bunch of hands-on workshops, they are also starting in two weeks time on the 1st of October running

58:42 all of October with interesting hands-on sessions. So that’s uh coming your way as well. Please register uh in the link I shared in chat. And yeah, if you are now wondering what to do next and how to dive in, obviously try out the repo um from Alex that that is shared. give give your um give your um security system a graph back end to um to prove the the access paths. Um if you want to learn more, graph academy is there for you. And if you want to just play with Neo

59:14 forj and don’t have to worry about anything, Neo Forj or free is a great place to to get started. And yes, I think that’s it at the time at the end of this session. was a very very cool um overview, very very interesting demo and uh and very interesting concept. So thank you very much Alex for for showing that off and for for giving us this insight. Um you you shared your your and I’ll let let me quickly pop back here. You shared your um contact means so if

59:45 if there’s anything else as a follow-up, please reach out to Alex um on LinkedIn or via the email address here. And um yeah uh looking forward to um to the next uh conversations and to meeting you all somewhere else um if possible. But other than that definitely tune in next week uh two weeks time sorry uh for the next session on Neo forj live. Until then have a good rest of the week rest of uh um the day and um see you soon. Thank you very much again Alex for

1:00:15 >> Thank you. Thanks for having me. Yep.