Beyond Authorization Silos: Runtime Data-Flow Governance for AI Agents with FalkorDB

When AI agents evolved from chatbots into multi-tool execution engines, enterprise security teams' first instinct was often to deploy perimeter access control: as long as an agent has permission to call a given tool, let it through. But the Tether team pointed out at the Graph Hacks hackathon that this "authorization equals security" assumption completely breaks down in the face of dynamic tool chains—your data can leak to the public internet through a series of individually authorized calls.

Chain Vulnerability: Authorization Checks Can't See the Data Flow

The original article describes a typical scenario: an agent is granted permission for three tools—read_support_tickets, summarize_tickets, and send_email. Each call looks compliant in isolation, but combined they form a leak path: customer_portal (PII) ➔ summarize_tickets ➔ draft_email ➔ send_email ➔ email_external.

This is a "chain vulnerability." Traditional perimeter authorization only checks the tool's own permissions and cannot perceive data provenance or downstream sinks. When tools are dynamically composed at runtime, isolated binary permission checks fail completely.

The Tether team's angle was clever: rather than having the agent read the graph, let the graph "watch" the agent. They used FalkorDB to model the agent's entire operational universe as a property graph, performing real-time interception before every tool call.

The Graph as a Real-Time Gatekeeper: Four Technical Breakthroughs

Tether's core idea is to pull security policy out of offline audit logs and back onto the call chain, requiring per-check latency in the single-digit milliseconds. FalkorDB's in-memory graph engine and Cypher query capabilities make this possible.

Multi-Hop Data-Flow Path Traversal (<2ms)

Before tool execution, Tether tracks data categories via a lightweight runtime tag, __tether_stamp, and uses a parameterized Cypher query to determine whether data can reach a prohibited sink trust level:

MATCH p = (:Tool {name: $tool})-[:OUTPUT_FEEDS*0..4]->(t2:Tool)-[:WRITES_TO]->(s:Sink)
WHERE s.trust IN $prohibited_trusts
RETURN p, [n IN nodes(p) | n.name] AS node_names, s.name AS sink_name, s.trust AS sink_trust

If the path exists, the call is blocked before execution, and the full multi-hop path is returned as deterministic evidence. This is far more reliable than having an LLM "guess" at security boundaries.

Cypher Variable-Length Paths and Trust Levels

The [:OUTPUT_FEEDS*0..4] in the example query is Cypher's variable-length path syntax, meaning match any path of 0 to 4 hops along OUTPUT_FEEDS edges; *0 allows the starting tool itself to be the sink, covering the degenerate case of direct writes. $prohibited_trusts is a parameterized set of prohibited trust levels (such as public, external_cloud), maintained centrally by the policy layer to avoid hardcoding policy into queries.

RETURN p, [n IN nodes(p) | n.name] uses a list comprehension to extract the names of all nodes on the path, returning them as an auditable evidence chain. This ability to "query as evidence" is something LLM judgments struggle to provide—an LLM can only give a conclusion, not a reproducible deterministic path.

LLM-Free Autonomous Security Rerouting

Direct blocking would interrupt user workflows. Tether leverages graph connections between tool capabilities to automatically find compliant alternatives: if summarize_tickets would leak PII to an external cloud sink, the system discovers local_summarizer, which shares the same task type but only writes to internal sinks, and completes the reroute without human intervention.

Persistent Verdict Memory

An agent should not repeat its mistakes across sessions. Tether writes every gating decision into immutable (:Verdict) nodes. Before proposing a tool, the agent performs a consultative pre-check; if there is a history of blocked records, it proactively adopts reroute candidates. The original article states this achieves a 0.0% repeat-violation rate.

Immutable Verdict Nodes and Consultative Pre-Checks

(:Verdict) nodes record each gating decision's inputs (tool, data category, target sink) and outputs (allow/block, matched path, reroute candidate) in append-only fashion. Immutability means historical verdicts are not overwritten by subsequent state, so they can serve as both an audit log and a learning signal for the agent.

"Consultative pre-check" means that before formally proposing a tool call, the agent queries historical verdicts from the graph: if the same context was previously blocked due to a data-flow path, it directly adopts the reroute candidate recorded at that time instead of triggering interception again. This turns "post-hoc blocking" into "pre-emptive avoidance," and is the mechanism behind the 0.0% repeat-violation rate—the agent no longer relies on memory or prompt constraints, but reads deterministic historical conclusions from the graph.

Federated Revocation and Automatic Remediation

When an upstream tool is exposed with a vulnerability, revoking that tool's single authorization in FalkorDB cuts off all agents' federated data-flow paths. In the benchmark, active leak paths dropped from 4 to 0 instantly, while all 10 legitimate business workflows remained intact.

FalkorDB and the Property Graph Model

FalkorDB is an in-memory graph database built on sparse matrices (GraphBLAS), supporting the OpenCypher query language and focused on low-latency multi-hop traversal. Unlike disk-persistence-oriented graph databases such as Neo4j, FalkorDB keeps graph structure and indexes resident in memory, enabling path queries within 4 hops to consistently land in the millisecond range—exactly matching Tether's per-gating latency requirement.

The core of the property graph is that both nodes and edges can carry arbitrary key-value properties. Tether exploits this by modeling tools (Tool), data sinks (Sink), trust levels (trust), and data categories (PII, etc.) as nodes with properties, turning "can a given tool's output reach a prohibited trust-level sink within N hops" into a pure graph traversal problem rather than one requiring semantic reasoning.

Revocation Semantics of Federated Authorization

"Federated" here means multiple agents share the same tool and data-flow graph, each holding independent authorization edges. Revoking a single authorization for an upstream tool is equivalent to deleting the corresponding authorization edge from the graph or marking it invalid; since every leak path must pass through that edge, a single deletion simultaneously disconnects all agents' shared paths without notifying or restarting each agent individually.

This is also the core advantage of the graph model over decentralized permission configurations: permissions and data flows are expressed in the same graph, and the blast radius of a revocation can be computed directly from reachability. In the benchmark, active leak paths dropping from 4 to 0 while 10 legitimate workflows remain unaffected essentially validates that "the blast radius of revocation is controllable"—only paths passing through the revoked edge are cut, while all other connected components remain intact.

Benchmark Data: Deterministic Execution with Zero Hallucination

There is not a single LLM call in Tether's execution logic; security verdicts are entirely handled by Python and Cypher queries. The original article's benchmark results:

Metric	Result
Risky calls blocked	6/6 (100%)
Legitimate tasks falsely blocked	0/10 (0%)
Legitimate tasks after revocation	10/10 uninterrupted
Gating latency (p50/p95)	10.0ms / 28.8ms
End-to-end orchestration demo (6 acts)	4.16s total

The key takeaway from these numbers is that security gating does not sacrifice usability, false blocks are zero, and latency is within an acceptable range. For production systems that must perform checks on every tool call, this is the watershed for whether it can ship.

What Tether Reveals About the Shift in Agent Security Architecture

This project offers an architectural signal worth noting: agent security is shifting from "authorization checklists" to "data-flow governance."

Traditional IAM models assume tools are isolated behavioral units, but the essence of agents is precisely composition. When tools can be freely orchestrated, permission checks must understand how data flows between tools. Graph databases are naturally suited to expressing this kind of multi-hop, property-bearing, dynamically queryable relationship network.

Another notable point is determinism. Tether deliberately excludes LLMs from security verdicts, using graph queries for policy decisions. This avoids the circular reasoning of "using an insecure model to protect an insecure agent." The LLM handles reasoning and orchestration; the graph handles gatekeeping and evidence. The boundary of responsibility is clear.

Of course, Tether is still a hackathon product. The 69 pytest tests and FastAPI dashboard indicate a relatively high level of engineering completeness, but the scale of policies in production, the maintenance cost of the graph model, and the actual behavior of multi-tenant isolation all require further validation. Still, the direction of "letting the graph watch the agent" has already taken a key step beyond simple permission granting.

The project is open-sourced on GitHub: sanskar21gusain/tether, with a tech stack of Python 3.11+, FalkorDB, Docker, FastAPI, and Pytest.

One-line Summary

Tether uses a graph database to check data-flow paths before every tool call, intercepting chain leaks.

Paragraph Summary

The article presents the agent security solution proposed by the Tether team at the Graph Hacks hackathon. The author points out that traditional perimeter authorization only checks individual tool permissions and cannot perceive how data flows through dynamic tool chains; multiple individually compliant calls can combine into PII exfiltration paths. Tether uses FalkorDB property graphs to model tools, data categories, and sink trust levels, and before each call uses multi-hop Cypher queries to determine whether data can reach prohibited sinks, providing deterministic path evidence. The solution also includes LLM-free autonomous rerouting, immutable verdict memory, and federated revocation. Benchmarks show a 100% interception rate, 0% false blocks, and 10ms p50 latency, signaling an architectural shift in agent security from authorization checklists to data-flow governance.