Architecting Trusted Agents: Turning Knowledge Graphs into Secure Policy Engines

  • Length: 1 hr 0 min
  • 2,330 views
Play video on YouTube: Architecting Trusted Agents: Turning Knowledge Graphs into Secure Policy Engines
Presented by Alex Babeanu: more videos Presenter
Watch on YouTube (opens in a new tab)

Chapters 10

  1. Play from Introduction Welcome
  2. Play from The Problem with Copilot's Role-Based Access Control
  3. Play from The Role Explosion Problem
  4. Play from Zero Trust & the PEP/PDP Architecture
  5. Play from From Static to Dynamic Authorization (ReBAC + ABAC = KBAC)
  6. Play from Modeling Agentic Workflows to Detect Excessive Agency
  7. Play from Demo Setup: Architecture & Insurance Use Case
  8. Play from Testing as an Employee: Household Queries & Google Drive Access
  9. Play from Testing as a Customer: Restricted Views & AI Hallucination
  10. Play from Wrap-up & Q&A

Your agent can now answer any question about your data. But should it answer every question for every user? Ask it to summarize confidential HR files or to show the CEO’s salary, and the answer depends on one thing: who is asking, and what they are allowed to see.

In this Neo4j Live session, Alex Babeanu, Lead Product Manager for the AI Control Suite at IndyKite, shows why role-based access control (RBAC) alone is insufficient for agentic systems, and how to use your own knowledge graph as the policy engine instead. Alex started in identity and access management and came to graphs about ten years ago, when he found identity problems that only a graph database could model.

The problem: AI makes oversharing visible

Microsoft Copilot is a useful example. It does not invent its own permissions. It only shows what the user’s existing roles and groups already allow. That is correct behavior, but it exposes every permission mistake your organization has made over the years.

Alex cited Concentric AI’s latest Data Risk Report to show the scale of the problem. On average, Microsoft Copilot accessed almost three million sensitive data records per organization. Organizations also shared more than three million sensitive records with external domains, while 57% of the records shared organization-wide contained sensitive information. The agent did not create those permission gaps. It made them easier to find. 

Why roles explode

Every new app or API brings its own roles, because the existing ones rarely fit. Over the years the people who created them leave, nobody knows what each role really grants, and many organizations end up with more roles than employees. Then an agent arrives. A user with a harmless role in one system and an admin role in another now has combined reach through the agent; unlike an API, the agent decides how to use it. Each new MCP server and agent further multiplies the number of combinations.

The roles are not really the problem. The relationships behind them were hidden in directories such as LDAP and in application code. Alex pointed out that the original 1992 RBAC paper described users, roles, and permissions as a graph. We moved to directories and lost the picture.

The architecture: never trust, always verify

The answer is zero trust with dynamic authorization: every single request is checked at the moment it is made, not once at login. Two components do this work:

  • Policy Enforcement Point (PEP): a gateway in front of each resource, such as an MCP gateway, an API gateway, or an agent-to-agent gateway. It intercepts each request and enforces the PDP’s allow/deny decision. 
  • Policy Decision Point (PDP): the rules engine that answers “allow” or “deny” and the PDP evaluates policies using graph context.

PEP and PDP talk through AuthZEN, a new open standard from the OpenID Foundation (Alex is one of its co-chairs). It standardizes communication between enforcement points and decision engines, supporting interoperability. The same pattern applies to agents calling MCP servers, REST or GraphQL APIs, and other agents through A2A. One design rule stands out: the agent is smart, so the guard must be simple. Use deterministic rules. If another AI guards the first AI, you cannot trust either one.

ReBAC + ABAC = KBAC

Two models matter here:

  • Relationship-based access control (ReBAC): access follows a path in the graph. Jay belongs to a team; the team holds an entitlement; and the entitlement grants access to a resource. A Cypher traversal answers “what can Jay reach?” directly.
  • Attribute-based access control (ABAC): access depends on conditions at request time, such as time of day, location, or claims in the access token.

Neither is enough alone. ABAC without relationships lacks context. ReBAC without conditions lacks precision. Combine them and you get what Alex calls knowledge-based access control (KBAC): the policy is a graph pattern plus conditions on it. The path must exist, and the conditions must hold.

Because nodes can be anything (people, teams, organizations, agents, documents, workflows), you can make policies as coarse or as fine as you need, down to a single node property.

Modeling agent workflows to stop excessive agency

The same graph can describe your agents. Model which agent may call which agent or tool, and which user may start which workflow. Then a violation becomes visible immediately. In Alex’s example, agent two is only allowed to use an MCP server, but it tries to call agent four. No path exists in the graph, so the gateway blocks the call.

The graph also records the full delegation chain. What gets authorized is not just “the user” or “the agent” but “this user, working through this agent, through that agent.” AI agents are first-class subjects in the same graph as humans, with no separate permission framework. That gives you an audit trail that answers the question after an incident: why did the agent do that?

The demo: an insurance company

The demo shows an insurance graph that includes customers, households, vehicles, and policies, with an AI assistant and a gateway in front of every agent and tool. Four things stand out:

One graph serves humans and agents. The normal web app and the AI assistant use the same graph and the same policies. Only the context differs, so the same question can get different answers depending on who asks and through which agent.

Access questions become graph questions. A support employee investigates why a customer cannot see the premium on his home policy. The agent follows the path in the graph and finds that the policy belongs to his spouse. No one has to read application code or dig through role lists.

Policies can depend on the actor. A list visible to a human in the app is blocked to the AI. A customer sees only his own household, and the company’s Google Drive is off limits to him.

Authorization does not stop made-up answers. The block on the Drive worked, but the agent then tried other routes and produced an answer that exists in no database. Alex’s advice is blunt: always verify what an agent tells you.

Key takeaways for developers

  • Do not use RBAC alone for agents. Roles multiply with every app, API, and MCP server, and they hide who can reach what. Agents turn that hidden access into real risk.
  • Check every request, every time. Put a gateway (PEP) in front of each tool, API, and agent, and let it ask a decision engine (PDP). Use AuthZEN so the parts stay replaceable.
  • Store entitlements as a graph. Users, teams, resources, and agents become nodes, and access becomes a path you can query with Cypher. You can finally answer “who can access what?”
  • Combine relationships with conditions. A path says who is connected to what; attributes such as time, location, and token claims say under which conditions. You need both.
  • Keep the guard simple and deterministic, and verify the output. Do not protect an AI with another AI. Authorization limits what the agent can read, but you still need to check what it says.

Additional resources

Related videos

Browse all videos