Comparison

Cordum vs OpenFGA for AI Agents

OpenFGA is the authorization data model and check engine. Cordum is the pre-execution action firewall. They answer different questions and are often used together.

Short answer

OpenFGA is an open-source, Zanzibar-inspired authorization engine and a CNCF Incubating project. You store relationship tuples (this agent may act for this user; this task may call this tool until a set time) and your code calls Check, BatchCheck or ListObjects before it acts.

Cordum is an action firewall for AI-agent actions. It sits in the action path (Claude Code hooks, Cordum's MCP policy gate, job dispatch) and returns ALLOW, DENY, REQUIRE_APPROVAL, THROTTLE or ALLOW_WITH_CONSTRAINTS, with approvals bound to the exact action and redacted evidence.

OpenFGA answers “is this principal permitted on this object?” Cordum answers “should this action run now, and who signs off?” Use OpenFGA for relationship data and RAG filtering; use Cordum to stop or hold risky actions before they execute.

What OpenFGA is

An open-source (Apache-2.0) authorization engine written in Go and inspired by Google Zanzibar. It joined the CNCF Sandbox in 2022 and became a CNCF Incubating project in late 2025; it also underpins Okta's Auth0 FGA service.
You define an authorization model of types and relations and store relationship tuples. Conditions (CEL expressions) add context such as time windows; contextual tuples supply facts at check time.
Your service calls Check, BatchCheck, ListObjects or ListUsers and enforces the answer. OpenFGA is queried by the caller rather than placed in the request path.
Agents as principals: an agent type is allowed wherever users hold relations, so agents inherit access through the same hierarchy.
Delegation: acting for a user is an explicit, revocable relation instead of a copy of the user's permissions.
RAG: pre-filter the vector search with ListObjects, or post-filter retrieved candidates with BatchCheck before they reach the model.
MCP: the MCP server lists only the tools a user may call and checks access when a tool runs; time-boxed grants use a condition.
Task-scoped grants: per-task tool permissions with expiry and call-count conditions, bound to the calling agent and revoked by deleting the task's tuples.
The agent guides do not cover approval workflows or decision audit.

What Cordum is

Edge first: cordumctl edge claude launches Claude Code with a PreToolUse hook registered for every tool. The hook sends a redacted action envelope to a local cordum-agentd, which asks the Cordum Gateway and Safety Kernel for a decision before the tool runs. The wrapper is a developer path; fleet rollout uses managed Claude Code settings and endpoint controls.
Five decisions: ALLOW, DENY, REQUIRE_APPROVAL, THROTTLE and ALLOW_WITH_CONSTRAINTS. An approval is single-use and bound to the tenant, action hash, input hash and policy snapshot.
MCP governance second: tenant policy holds allow and deny lists for MCP servers, tools, resources and actions, with deny taking precedence. On the Gateway HTTP/SSE path, an opt-in per-tool policy gate (mcp.policy_gate_enabled) adds approval holds and argument redaction.
Platform third: the same Safety Kernel evaluates jobs before the scheduler dispatches them. Policy fragments can be scoped to a workflow, a job or an Edge session.
Policy matches attributes of the action (topic, capability, risk tags, labels, actor, tenant, MCP server, tool or action). The first matching rule wins and the default is deny. Cordum does not store a relationship graph.
Evidence: Edge events keep redacted descriptors, hashes and artifact pointers, not raw prompts or secrets, and audit events are SHA-256 hash-chained per tenant.
Customer-managed and source-available under BUSL-1.1; the documented Edge path builds its binaries from source. SSO, SCIM, advanced RBAC, SIEM export, legal hold, velocity rules and agent identity are Enterprise license entitlements, and license tiers cap custom policy bundles.

Side by side

Each row is checked against OpenFGA's and Cordum's documentation as of 2026-10-26.

Evaluation area	Cordum	OpenFGA
Category	Pre-execution action firewall: policy decision, approval and evidence at the point an action runs.	Authorization engine: an authorization model, relationship tuples, and check and list APIs.
Question it answers	Should this proposed action run now, wait for a reviewer, be throttled or run with constraints?	Does principal P have relation R to object O, under these conditions?
Who enforces	Cordum, in the action path: the Claude Code hook (Edge), Cordum's MCP policy gate, and the Safety Kernel before job dispatch.	Your application or MCP server, after calling Check or ListObjects.
Policy and data model	YAML rules over action attributes; first match wins; default deny; bundles must be Ed25519-signed in production.	Types and relations plus relationship tuples; CEL conditions; contextual tuples at check time.
Outcomes	ALLOW, DENY, REQUIRE_APPROVAL, THROTTLE, ALLOW_WITH_CONSTRAINTS.	Allowed or not (Check, BatchCheck); lists of objects or users (ListObjects, ListUsers).
Time- and task-scoped access	Policy fragments scoped to a workflow, job or Edge session; each approval covers one bound action and is consumed on the first matching retry.	Documented pattern: grants with a start time and duration, call-count limits, agent binding, and revocation by deleting a task's tuples.
Human approval	REQUIRE_APPROVAL stops the action until a reviewer decides; the agent then retries with the bound approval.	Not covered by the agent authorization guides.
Audit evidence	Redacted descriptors, hashes and artifact pointers per action; per-tenant hash chain; SIEM export is an Enterprise entitlement.	Decision audit is not covered by the agent authorization guides.
RAG filtering	Not a retrieval filter. Cordum governs actions, not which documents enter the model's context.	Documented: ListObjects pre-filtering or BatchCheck post-filtering.
MCP	Tenant allow and deny lists for MCP servers, tools, resources and actions; opt-in policy gate with approval holds on Cordum's MCP server.	Documented model for per-user tool access through roles, groups and time-boxed grants; the MCP server calls OpenFGA.
License and governance	Source-available core under BUSL-1.1; CAP protocol and SDKs under Apache-2.0; enterprise features are license entitlements.	Apache-2.0; CNCF Incubating project.

OpenFGA: who may call which tool

An illustrative model. Your code writes a tuple granting an agent can_call on a tool with a grant time and duration, then passes the current time to Check before invoking the tool.

authorization-model.fga

OpenFGA DSL

model
  schema 1.1

type user

type agent
  relations
    define acts_for: [user]

type tool
  relations
    define can_call: [user, agent with time_window]

condition time_window(current_time: timestamp, grant_time: timestamp, grant_duration: duration) {
  current_time < grant_time + grant_duration
}

Cordum: whether the action runs

A Safety Kernel policy excerpt for Claude Code actions classified by Cordum Edge, plus tenant MCP lists.

safety-policy.yaml

YAML

# Excerpt. First matching rule wins; unmatched actions are denied.
version: v1
default_decision: deny
rules:
  - id: deny-secret-reads
    match:
      topics: ["job.edge.action"]
      risk_tags: ["secrets"]
      labels:
        "path.class": secret
    decision: deny
    reason: "Agents may not read credential files."

  - id: approve-git-push
    match:
      topics: ["job.edge.action"]
      capabilities: ["exec.shell"]
      labels:
        "command.family": git_push
    decision: require_approval
    reason: "Publishing repository state needs a reviewer."

  - id: allow-local-tests
    match:
      topics: ["job.edge.action"]
      capabilities: ["exec.shell"]
      labels:
        "command.class": safe
        "command.family": test
    decision: allow
    reason: "Local test runs are allowed."

tenants:
  default:
    mcp:
      allow_servers: ["github"]
      deny_tools: ["delete_repository"]
      deny_actions: ["delete"]

When to choose OpenFGA

You need fine-grained permissions across users, agents, documents and tools inside your own applications.
You must filter RAG results by what the requesting user is allowed to see.
You want task-scoped, expiring agent grants stored as data that your services can query.
You want an Apache-2.0, CNCF-governed engine that you run and query directly.

When to choose Cordum

Agents such as Claude Code run shell commands, edit files or call MCP tools, and some of those actions must be stopped or approved before they run.
You need approvals bound to the exact action and a redacted, hash-chained record of each decision.
You want enforcement at a point every governed action passes through (hook, MCP gate or job dispatch), in addition to checks inside each service.

Using both together

OpenFGA holds the relationship data; Cordum gates the action. Cordum does not call OpenFGA and ships no connector for it, so each check runs where it belongs.

Claude Code proposes an MCP tool call or a shell command. Cordum Edge's PreToolUse hook evaluates it against Cordum policy first.
If Cordum allows it, or a reviewer approves it and the agent retries, the call reaches your MCP server or service.
Your server calls OpenFGA Check, or ListObjects for retrieval, for the user, agent, task and resource, then executes or refuses.
Cordum records the action decision with redacted evidence; your service records its authorization result.

Related comparisons

Frequently Asked Questions

Is OpenFGA an alternative to Cordum?

Not directly. OpenFGA is an authorization engine your code queries to learn whether a principal is related to an object. Cordum sits in the action path and decides whether a specific action runs, needs approval, is throttled or is constrained. Teams often use OpenFGA for fine-grained permissions and RAG filtering, and Cordum to stop or hold risky agent actions before execution.

Can OpenFGA block or approve an agent action by itself?

OpenFGA returns a decision to the caller, and the caller enforces it. Its agent guides describe Check and ListObjects calls made by your application or MCP server; they do not describe approval workflows.

How does OpenFGA model time-limited agent access?

Its task-based and MCP guides use conditions: a grant stores a start time and a duration, and the caller passes the current time with each check. Call-count limits work the same way, and deleting a task's tuples revokes its grants.

Does Cordum do relationship-based access control?

No. Cordum policy matches attributes of an action, such as topic, capability, risk tags, labels, actor, tenant and MCP server, tool or action. It does not store a relationship graph, so teams that need ReBAC run OpenFGA or a similar engine for that layer.

Where does each check run for an MCP tool call?

With Cordum Edge on Claude Code, the PreToolUse hook evaluates the call before Claude Code sends it. Your MCP server can then call OpenFGA for resource-level access before it executes the tool. Cordum does not call OpenFGA and ships no connector for it.

Is OpenFGA a CNCF project?

Yes. OpenFGA joined the CNCF Sandbox in 2022 and was accepted as a CNCF Incubating project in late 2025. It is Apache-2.0 licensed.

Sources

All sources accessed 2026-10-26. Vendor descriptions are paraphrased from the pages below.

OpenFGA

Cordum

Keep your ReBAC model. Gate the action.

Start with Claude Code shell and file actions, then apply the same policy, approval and evidence path to MCP tool calls routed through Cordum.

Govern Claude Code with Edge See MCP governance