Notifications
Clear all
Topic starter
19/08/2026 3:39 pm
TL;DR: Relationship-based permissions are easier to operationalise when teams can see permission graphs resolve to ALLOWED or DENIED, according to Ory, and the Keto Playground provides seven editable examples in browser-based offline mode before any live instance is involved. That matters because graph-based authorisation fails when teams cannot reason about relationship chains quickly enough to trust the model.
NHIMG editorial — based on content published by Ory: Keto Playground makes relationship-based access visible
Questions worth separating out
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.
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.
Q: What breaks when teams cannot inspect the permission path?
A: What breaks is trust in the authorisation model.
Practitioner guidance
- 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.
- 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.
- Map relationship boundaries to governance boundaries Define namespaces and relation names so they mirror real organisational or application boundaries.
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.
👉 Read Ory's walkthrough of the Keto Playground and permission graph examples →
Keto permission graphs: can your IAM team trace decisions fast?
Explore further
19/08/2026 4:18 pm
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.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, according to Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Keto Playground makes relationship-based access visible
