Keto Playground makes relationship-based access visible

At a glance

What this is: This is a walkthrough of Ory's Keto Playground, a browser-based visualiser for relationship-based permissions that shows how graph paths resolve to ALLOWED or DENIED.

Why it matters: It matters because IAM teams responsible for NHI, autonomous, and human access models need to validate relationship logic before they rely on it in production.

👉 Read Ory's walkthrough of the Keto Playground and permission graph examples

Context

Relationship-based access control, or ReBAC, models access as a graph of relationships rather than a static role assignment. The core governance problem is not whether permissions exist, but whether teams can reason about the path that produces an allow or deny decision in time to trust the model.

That matters for identity programmes because the same reasoning gap shows up in complex human IAM, service-account authorisation, and emerging AI-agent access patterns. If the decision path is opaque, recertification, debugging, and policy design all become slower and less reliable.

Key questions

Q: How should security teams validate relationship-based access controls before production?

A: Start by testing the policy graph offline, where you can inspect how subjects, namespaces, and tuples combine without production pressure. Then move to live data only after you have verified both allow and deny paths, including inheritance chains and nested relationships that could widen access unexpectedly.

Q: Why do relationship-based access models become harder to govern at scale?

A: They depend on accurate relationship data, clear ownership, and consistent logging. As the number of objects, projects, and exceptions grows, it becomes harder to prove why each entitlement exists. That makes review and offboarding more complex than in a pure role model, especially if relationship sources are inconsistent across systems.

Q: What breaks when teams cannot inspect the permission path?

A: What breaks is trust in the authorisation model. If operators cannot see why a decision resolved the way it did, they cannot confidently approve changes, explain exceptions, or prove that inherited access stays inside intended boundaries.

Q: How do relationship graphs compare with RBAC for access review?

A: RBAC is easier to read but less expressive, while relationship graphs are better when access depends on ownership, membership, or delegation chains. The trade-off is review complexity: graph-based models need stronger tracing and explanation because the effective permission is derived, not obvious.

Technical breakdown

How relationship graphs determine permission checks

Keto-style authorisation evaluates whether a relationship path exists from a subject to a resource through namespaces, relations, and tuples. Instead of checking a single role, the engine traverses edges such as team membership, ownership, or delegated grants until it can prove an allow or deny condition. That makes the graph itself the source of truth for access decisions. The practical challenge is that graph depth and inheritance can hide the actual decision path from operators who are used to RBAC or ABAC thinking.

Practical implication: teams need a way to inspect the decision path, not just the final decision, before they place real workloads on the model.

Why visual permission tracing reduces authorisation risk

A visual graph turns the question from abstract policy syntax into a concrete path check. That is useful when permissions combine direct grants, inherited relationships, and nested groups, because human operators often misjudge how far access propagates. Visual tracing does not change the policy engine, but it reduces the odds of hidden overreach surviving into production. It is especially valuable where policy complexity grows faster than the team’s mental model of the system.

Practical implication: use interactive tracing to validate inheritance chains and edge cases before you bind the model to live applications.

Offline and online modes support different governance stages

Offline mode lets teams explore bundled schemas and tuples without infrastructure, while online mode connects to a live Ory Network project and tests against real data. That split matters because early-stage modelling and production governance answer different questions. Offline mode is for understanding whether the access model makes sense at all. Online mode is for validating that actual tuples, namespaces, and permissions behave as expected under realistic conditions.

Practical implication: treat offline visualisation as design validation and online testing as operational assurance, not as interchangeable steps.

NHI Mgmt Group analysis

Permission graphs expose a governance problem that role lists hide: ReBAC does not fail because it is too flexible. It fails when teams cannot explain why a path resolves to allow or deny, which undermines review, debugging, and least-privilege validation. The named concept here is authorisation traceability debt: the longer a team relies on relationship logic they cannot easily inspect, the harder it becomes to govern access with confidence. Practitioners should treat inspectability as part of the control, not a nice-to-have.

ReBAC is most useful when relationships are the business rule, not when it is a substitute for governance discipline: The graph model fits shared ownership, delegated team access, and nested organisational structures because those relationships already exist in the operating model. But the same flexibility also increases the burden on policy authors to define namespace boundaries cleanly. Without that discipline, inherited access becomes difficult to review and easy to misread. Practitioners should align the graph structure with real governance boundaries, not convenience.

Visualisation is not a control by itself, but it is a control-validation mechanism: Security teams often discover authorisation mistakes only after a user gets unexpected access or a legitimate workflow breaks. A permission visualiser shortens that feedback loop by making the path visible before deployment. That is especially relevant for mixed environments where human users, service accounts, and application workflows all depend on the same underlying policy engine. Practitioners should use visual tracing to validate the model before they depend on it for production access.

Relationship-based authorisation will increasingly sit at the centre of non-human identity governance: As service accounts, APIs, and AI-driven workflows inherit more access through relationships rather than static grants, the old assumption that entitlement meaning is obvious starts to fail. ReBAC can reduce duplication, but only if teams can map who or what can act through which chain at any moment. Practitioners should expect graph-based authorisation to become a core identity control plane problem, not just an application feature.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• From our research: 97% of NHIs carry excessive privileges, according to Ultimate Guide to NHIs.
• Traceability gaps compound quickly when graph-based authorisation is extended into service-account and workload governance, so visibility is the next control to harden.

What this signals

Authorisation traceability debt: As policy graphs grow, the challenge shifts from expressing access rules to explaining them. Teams that cannot inspect the relationship path will struggle to keep reviews, exception handling, and offboarding aligned with the actual decision model.

The practical next step is to connect visual policy testing with lifecycle governance, especially where [Ultimate Guide to NHIs](https://nhimg.org/the-ultimate-guide-to-non-human-identities) remains the baseline reference for service-account visibility and rotation.

Where relationship-based access expands across human users, workload identities, and AI-driven workflows, the same governance question repeats: can the team prove why access resolves the way it does, before the path becomes production truth?

For practitioners

• Validate relationship paths before production rollout Use a visual permission model to confirm exactly how a subject reaches a resource through team membership, ownership, and inherited grants. Focus on edge cases where access can fan out unexpectedly through nested relationships.
• Separate design validation from live policy testing Start in offline mode to confirm that the schema matches the business model, then move to a live instance only after the graph behaves as expected against real tuples. Keep those two stages distinct in your change process.
• Map relationship boundaries to governance boundaries Define namespaces and relation names so they mirror real organisational or application boundaries. That makes access reviews, delegation rules, and offboarding decisions easier to interpret when the graph changes.
• Test denial paths as deliberately as allow paths Run checks that prove who cannot access a document, team, or account, not only who can. Negative testing is where hidden inheritance and unintended reach are most likely to surface.

Key takeaways

• Relationship-based access becomes governable only when teams can explain the path that produces each allow or deny decision.
• Hidden inheritance and nested relationships are the main reason graph-based authorisation is harder to review than simple role assignment.
• Visual tracing is most valuable as a validation step before production, especially where access spans humans, workloads, and service accounts.

Key terms

• Role-Based Access Control: A model that grants permissions by assigning identities to predefined roles. It works well when jobs are stable and access patterns are predictable, but it becomes brittle when exceptions pile up. In practice, role design must stay small enough to audit and broad enough to avoid endless custom variants.
• Permission Graph: The combined structure of policies, roles, groups, resource rules, and deny logic that determines what an identity can do. It becomes difficult to reason about as environments scale because access is distributed across multiple control points. Security teams use the graph to resolve privilege rather than guess it.
• Identity Traceability: Identity traceability is the ability to link each action back to a specific identity, authorisation path, and time window. It is essential when humans, service accounts, and AI agents all operate in the same environment and auditors need a defensible record.

What's in the full article

Ory's full article covers the implementation detail this post intentionally leaves at the governance level:

• Step-by-step setup for the Keto Playground in offline and online modes.
• Hands-on examples for RAG document access, B2B hierarchy modelling, and workflow permissions.
• Schema and tuple patterns you can adapt when building relationship-based authorisation models.
• The repo workflow for editing examples and testing permission changes locally.

👉 The full Ory post shows the editable examples, live-mode testing flow, and model setup details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity governance programme, it is worth exploring.