Relationship Authorization (ReBAC)

Overview

Agentic Security authorizes what an agent may do - its delegation chain, risk level, autonomy budget, tool integrity, and the four-verdict policy. Relationship Authorization adds the missing half: whether the principal has the right relationship to the specific object a tool call targets - ownership, group or team membership, folder→document inheritance, and sharing.

DeepIntShield does this by integrating OpenFGA

• the CNCF, Zanzibar-inspired relationship-based access-control (ReBAC) engine - as a co-located decision store behind the PDP. The result is a single decision that asserts both “this agent may call get_document” and “this principal is a viewer of document:1234 because it lives in a folder owned by their team.” Pure attribute-based gateways and pure relationship engines each deliver only one side of that; this is both, on the same hot path.

Key benefits

• Per-object least privilege - authorize the record, not just the tool name, with inheritance and nested groups.
• One composable operand - a new relationship condition sits alongside your existing ABAC conditions in the same visual policy builder; no second policy system.
• Zero added latency - the relationship verdict folds into the same in-process decision cache as every other input, so repeated calls make no store calls; cold checks run co-located and in parallel with policy evaluation.
• Tamper-evident by default - relationship changes are written through DeepIntShield onto the same hash-chained, zero-data-retention audit trail as every decision.
• See and prove access - an interactive relationship graph, an access-path inspector, and least-privilege analytics answer “who can reach this?” and “what can this agent touch?”

Plan availability

The relationship operand, Authorization Model Studio, Tuple Workbench, and Access-Path Inspector are available on Business and above. The Relationship Graph Explorer and the least-privilege / over-permission analytics (powered by reverse queries) require Enterprise (Enterprise and Enterprise VPC). The capability is off by default and enabled per deployment.

When to use it

Reach for Relationship Authorization when:

• Your tools act on specific records (documents, accounts, tickets, repos) and access depends on who owns or was granted them, not just the tool name.
• You need inheritance - access to a folder grants access to its documents; team membership grants access to team resources.
• You must enforce least privilege per object and produce evidence of why a principal had access to a given record.
• You want to answer reverse questions - “what can this agent reach?” and “who can reach this sensitive object?”

How a decision works

1. Map the tool to an object. For each tool, declare how the target object is read from the call arguments - e.g. get_document → document:{args.id}.

2. Author a policy. In the Agentic Security rule builder, add a relationship condition - for example, subject must be viewer of the resolved object. It renders to Rego beside the visual builder, exactly like every other operand.

3. Decide. On each tool call, after the standard cheapest-deny checks, the PDP resolves the object from the arguments and issues an OpenFGA Check (user × relation × object). The boolean result combines into the verdict - Allow / Deny / Require approval / Mask - alongside your ABAC conditions.

4. Serve from cache next time. The verdict (including the pinned authorization-model version) folds into the in-process decision cache, so an identical repeat call is a pure cache hit with no store round-trip.

Fail posture

If the relationship store is briefly unavailable or a check exceeds its deadline, the decision follows the tool’s fail posture: high-sensitivity tools fail closed (deny or require approval); low-sensitivity tools fall through to the attribute-based verdict. Nothing silently proceeds on a sensitive object.

Workspace surfaces

All of this lives under Workspace → Agentic Security → Authorization:

Surface	What it does
Authorization Model	Visual editor for the relationship model (types + relations) with a live DSL preview and version diff.
Relationships	Tuple Workbench - create, inspect, and revoke relationships, with CSV import/export. Every change is audited.
Relationship Graph	Interactive resource graph with access-path highlighting (“why does this principal have access?”) and a blast-radius overlay.
Access Inspector	Check Playground - enter user × relation × object and see allow/deny plus the contributing relationship path and tuples.
Authorization (Analytics)	Decision mix over time, a relationship-check latency budget, and a least-privilege / over-permission heatmap.

ReBAC Studio

ReBAC Studio is the interactive console for relationship-based access control, at Workspace → Agentic Security → ReBAC Studio (also on the sidebar, at /workspace/agentic-security/rebac-studio). It is pure UI on the already-shipped OpenFGA/ReBAC backend - no new endpoints and no change to the decision path - so it is the fastest way to grant a per-tool permission, inspect tuples, and check an access path without writing tuples by hand.

Tab	What it does
Builder	A drag-and-drop canvas: subjects (user / agent / team, typed per the published FGA model - an Entra idtyp=application maps to an agent: subject) sit in a rail on the left; tools / objects (e.g. mcp_tool:<name>) are drop-zone cards on the right, each with its permission/relation picked live from the model. Drag a subject onto a tool to write that one relationship tuple; revoke from the grant chip’s ✕. Add new subjects or tools inline.
Relationships	The Tuple Workbench - filter, list, and revoke tuples.
Check	The Access-Path Inspector - subject × relation × object → Allow / Deny, plus a reverse blast-radius (“what objects can this subject reach”, via list-objects).
Overview	Least-privilege and relationship analytics, rendered as graphs.
Model	A read-only view of the published FGA types and relations (direct vs inherited).

Every grant goes through the mediated POST /agentic-security/authorization/relationships (never OpenFGA directly), so the write is tenant-scoped and audited automatically, and the per-tenant relationship epoch bumps. That epoch is folded into the decision cache key, so the L1 decision cache invalidates instantly - the next /decide reflects the grant at zero added latency (see Consistency & accuracy below).

ReBAC Studio is gated Business and above (FeatureGate agentic.integrity), with RBAC inherited from the workspace. It activates when OPENFGA_API_URL is set for the deployment; otherwise it shows a graceful “not enabled” card.

The Analytics → Authorization page renders the same recharts least-privilege and relationship graphs (shared with the Overview tab) and links to Edit in ReBAC Studio.

Not yet in the UI

The interactive Relationship Graph Explorer force-graph (node-link) and the model DSL editor (an editing surface for the authorization model - the Model tab is read-only; publishing the model still uses the existing admin endpoint) are not yet rendered. The FGA client also still lacks Expand / ListUsers, so the forward “who can access this object” query is not yet available.

MCP Gateway authorization

When your agents reach tools through DeepIntShield’s MCP gateway, an MCP interaction raises three authorization questions - and each is answered by the same relationship operand at a different stage of the call:

Stage	Question	Example check
Connect	May this principal use this MCP server at all?	can_connect on mcp_server:filesystem
Invoke	May this principal call this specific tool?	can_invoke on mcp_tool:filesystem/read_file
Resource	May this principal touch the object the tool acts on?	viewer on document:{args.path}

Because MCP is inherently relational - servers own tools, tools belong to tool-sets, tools act on resources - ReBAC models it naturally, with inheritance an allow-list can’t express:

• Grant an agent access to a server and it cascades to that server’s tools.
• Grant a team viewer on a folder and it cascades to every document inside.

You bind servers, tools, and tool-sets to agents and teams from the MCP Registry → Authorization tab (these become relationship tuples); resource relationships come from your application data (synced via the API, CSV import, the SDK, or auto-seeded from a server’s resources/list).

Relationship-aware tool discovery

When a relationship policy is active, the gateway can filter a tools/list response to only the tools the calling principal is allowed to invoke - so an agent never even sees tools it has no relationship to (a reverse ListObjects query, off the hot path).

Consistency & accuracy

• OpenFGA is the source of truth for relationships; tuple writes are transactional.
• DeepIntShield keeps an eventually-consistent read cache bounded by the revocation SLA. A relationship change invalidates affected cached verdicts immediately by bumping a per-tenant epoch folded into the cache key.
• The relationship operand is a typed check, not a heuristic - verdicts are exact, and the pinned model version guarantees a model change can never serve a stale result.

Additive by design

Relationship Authorization changes nothing about your existing policies or the decision hot path. Tenants without a relationship policy never pay any cost, and the capability can be rolled out with the existing Shadow → Canary → Enforce modes - measure exactly what it would change before you enforce it.