CUTLINE is a permission-repair agent built on FalkorDB. Name the access that must disappear and the workflows that must survive. It traces every hidden route, rejects unsafe fixes with counterexamples, and proves the repair against a running app before anything changes.
01 / 04Trace
Maya handles orders and reports. FalkorDB finds she can bulk-export customer data anyway: through Shared Ops, and through Export Helper. Felix needs Shared Ops for Finance close; the DSAR Bot needs Export Helper for legal data requests.
maya → support → shared_ops → export_customers
maya → support → export_helper → export_customers
4 risky paths · 2 people × 2 routes · [:INHERITS*0..6]
02 / 04Reject
Every candidate is applied to its own copy of the graph and re-queried. Watch two of them fail.
9 of 10 candidates rejected with a counterexample
03 / 04Repair
Support (safe) grants exactly view_orders and generate_reports. Maya and Noah move onto it; nobody else changes. Seven edits, applied as one atomic Cypher write after a human approves.
Cost 8 · the cheapest candidate that passes all 8 constraints
04 / 04Verify
Real HTTP requests, decided by an independent enforcement point that must agree with FalkorDB on every single check.
CUTLINE never judges a fix in its head. Each candidate is applied to a GRAPH.COPY of the policy and re-queried in FalkorDB. A rejection always carries a counterexample: the route still open, or the workflow that would break.
cutline_dev → GRAPH.COPY × 10
0 struck · 0 survives
| Verdict | Candidate fix | Counterexample, found on the copy |
|---|---|---|
| Rejected | Revoke export_customers from Shared Ops | Felix loses export, so Finance close breaks. Maya still exports through Export Helper. |
| Rejected | Detach Shared Ops from Support | A forbidden route is still open:maya → support → export_helper → export_customers |
| Rejected | Detach Export Helper from Support | A forbidden route is still open:maya → support → shared_ops → export_customers |
| Rejected | Detach both bundles from Support | The DSAR Bot loses export, so legally required DSAR fulfilment breaks. |
| Rejected | Remove Maya and Noah from Support | They lose view_orders and generate_reports, so Order support breaks. |
| Pass | Create Support (safe) and move Maya and Noah onto it | All 8 constraints hold. Nobody gains access they did not already have. |
Bounded on purpose. At most 24 candidates, cuts of at most 3 edges, inheritance depth 6. CUTLINE returns the cheapest candidate that passes, not a claim of global optimality.
Reported, not hidden. The old Support role still reaches export, now held only by the DSAR Bot. Anyone newly assigned to it would inherit export, so CUTLINE flags it for review.
Before anything is applied, CUTLINE calls a running Customer Ops app, against the current policy and against the candidate. Every principal and capability is checked, including the ones nobody asked to change.
X-Cutline-Policy: candidate:<repair_id> tests a repair before it exists.
Runtime verification · candidate policy
00 / 12 passed
FalkorDB returns every bounded route from a person to a forbidden capability, not just direct grants.
[:INHERITS*0..6]Guardrails (must deny) and workflows (must keep working) are graph nodes. Plain-English additions are parsed, then confirmed by a human.
2 must-deny · 6 must-allowBounded, deterministic candidates: single cuts, minimal hitting sets, scoped-role migration. Each one runs on its own graph copy.
GRAPH.COPY per candidateReal HTTP requests hit a running app. An independent enforcement point decides; it must agree with FalkorDB on every check.
12 real requestsA human signs off. All edits land in one Cypher statement guarded by a revision compare-and-set, then the checks re-run live.
1 atomic writeEvidence is bound to a revision and a content hash. When the policy moves, the proof goes stale, apply is refused, and CUTLINE re-plans.
revision + sha256The model is never the security proof.
Evidence is never trusted forever. Every plan records the policy revision and a sha256 hash of the policy's edges it was built on.
Repair Studio · live challenge
Verified on r4 · 12 / 12 checks
Support (safe) applied. Evidence is bound to r4 and its content hash.
Every access path, business dependency, candidate repair and counterexample lives in the graph. Pull the plug and CUTLINE cannot plan, prove, or even let the demo app serve a request.
What FalkorDB does in CUTLINE
Effective-access reachability and multi-path witnesses
Variable-length Cypher traversal
Business intent: workflows, guardrails, the derived contract
Graph nodes and relationships
Candidate isolation
GRAPH.COPY: one throw-away graph per candidate
Counterexamples: path still open, workflow lost, new privilege
Re-querying the candidate graph
Atomic, revision-guarded application
One parameterised Cypher statement
Evidence ledger and cross-session agent memory
The cutline_dev__ledger graph
What the enforcement point reads at runtime
One-hop relations from the selected graph
-- every bounded route from one person to one capability
MATCH p = (u:User {id: $principal})
-[:ASSIGNED_TO]->(:Role)
-[:INHERITS*0..6]->(:Role)
-[:GRANTS]->(c:Capability {id: $capability})
RETURN DISTINCT [n IN nodes(p) | n.id] AS node_ids
One query returns every witness path the UI draws. A direct grant is the zero-hop case.
backend/app/db/queries.py · values are always parameters
The model chooses which investigation to run. It never writes Cypher, never sees graph names, and can never approve. With an Anthropic API key, Claude picks the tools in a tool-use loop; without one, the same tools run in a fixed order and the run is labelled deterministic.
Multi-hop reasoning
Person → role → inherited roles → capability, up to 6 inheritance hops, every independent route.
Graph queries as agent tools
11 typed tools, each running fixed, parameterised Cypher on FalkorDB.
Tool selection through MCP
The same tools ship as an MCP server (Python SDK v2); the model picks which to call.
Actions based on the graph
Repairs are generated from the discovered paths and applied after human approval.
Explainable results
Every rejection carries a witness path or the named workflow it breaks.
11 typed tools · also served over MCP
app/mcp_server.py
Ten synthetic scenarios with known correct answers, against two deliberately simple baselines. Every number below comes from that run.
10/10
Correct outcome: repair, refuse, or flag, as expected.
7/7
Safe repairs on the repairable scenarios.
11/12
Forbidden access detected through multi-hop routes.
1.46 s
Median planning time, candidates evaluated in parallel.
72/72 backend tests pass with real FalkorDB Cloud and OPA enabled.
Why 11 of 12, not 12. The twelfth is an 8-hop chain, beyond the planner's 6-hop bound. The unbounded independent engine catches it, and CUTLINE reports the disagreement instead of hiding it.
| # | Scenario | Outcome, as expected |
|---|---|---|
| 01 | The demo: two inherited paths; Finance and DSAR share the roles | Scoped role · 7 edits |
| 02 | Needed and forbidden capability bundled in one role | Scoped role · 4 edits |
| 03 | Forbidden capability three hops down a private chain | Single cut · 1 edit |
| 04 | Roles inherit each other in a cycle | Single cut · 1 edit |
| 05 | Dedicated export role shared with a legitimate user | Single cut · 1 edit |
| 06 | One subject, two forbidden capabilities | Scoped role · 5 edits |
| 07 | Two subjects keep different capabilities | Scoped role · 8 edits |
| 08 | A required capability the subject never had | Infeasible: refuses to invent a grant |
| 09 | Guardrail already holds | No violations: nothing to do |
| 10 | An 8-hop chain beyond the 6-hop planner bound | Disagreement flagged by the independent engine |
Supported
Allow-only RBAC with role inheritance, named principals and capabilities, bounded depth (6 inheritance hops by default).
Not modelled, on purpose
Deny rules, conditions and ABAC, time-bound grants, resource-scoped grants, cloud IAM policy languages.
Not silently approximated. CUTLINE claims only what its declared model can prove, and never invents a grant to make a constraint pass.
One dangerous capability. Two hidden graph paths. The obvious fixes rejected with proof. One structural migration that keeps every workflow alive, twelve real requests proving it, and a live policy change it catches and repairs.