Security Scanners Missed 56% of AI Agent Attack Paths. One Graph Query Found Them All

Two per-agent security scanners missed 97 and 98 of 174 AI agent attack paths in a test run at Graph Hacks, FalkorDB's October 2026 online hackathon that drew 7,899 developers and 1,213 projects, while a single FalkorDB graph query found all 174 with no false alarms. Every path the per-agent scanners missed crossed an agent-to-agent handoff, and a poisoned memory trace that checked timestamps scored 1.000 precision versus 0.554 without them. The hackathon team Reach modeled agents, MCP tools, OAuth scopes, data stores and handoffs as one graph, using a Cypher query that walks up to three handoffs to catch the "lethal trifecta" of untrusted input, private data access and outbound channels split across separate agents.

Most AI agent security tools check one agent at a time. Real attacks don't stay inside one agent. A poisoned web page enters through a research agent, gets handed to a sales agent, lands in shared memory and leaks out through a third. Graph Hacks, FalkorDB's online hackathon in October 2026, drew 7,899 developers and 1,213 projects, and some of the sharpest went after this gap. In one test, two per-agent scanners missed 97 and 98 of 174 attack paths. One FalkorDB graph query found all 174, with no false alarms. Key takeaways. Every path the per-agent scanners missed crossed a handoff. A poisoned memory trace that checks timestamps scored 1.000 precision, against 0.554 without them. algo.maxFlow found the cheapest set of revocations in 20 of 20 scenarios. And on 300 questions about real npm attacks, led by the 2025 chalk/debug compromise, an agent using graph tools found every exposure, where the same model alone found under half. Want to see what one prompt injection could reach in your own agents? Start free on FalkorDB Cloud https://app.falkordb.cloud/signup?cta=cta-top and load your agents, tools, credentials and handoffs as one graph. What is AI agent security? AI agent security is the work of controlling what AI agents can read, remember, call and send, so that one bad input can't turn into a data leak or a harmful action. Most of that risk lives in the connections between agents, tools, credentials and memory versions. FalkorDB stores them as one graph and runs path queries and graph algorithms inside the database. It's the same context layer that enterprise AI agents need https://www.falkordb.com/reference/enterprise-ai-agents-context-layer/ , pointed at security. Why do per-agent scanners miss attacks on AI agents? | Question | Per-agent scanner | One FalkorDB graph | |---|---|---| | Can a poisoned web page reach the CRM through a handoff? | Sees two agents that look safe on their own | Follows the handoff and returns the full path | | Which agents were infected by a poisoned memory? | Flags every agent that touched that key | Flags only agents that read the bad version after it was written | | What's the cheapest way to cut off an infected agent? | Revoke everything, or guess | algo.maxFlow picks the cheapest set of revocations | | Is my repo exposed to a malicious npm release? | Checks the lockfile you have today | Walks the dependency graph hop by hop, the way npm resolves it | How did Graph Hacks teams secure AI agents with FalkorDB? 1. Follow prompt injection across agent handoffs Reach · Nidhi Singh · See the code https://github.com/Nidhicodes/reach · Use the app https://reach-lnwm.onrender.com · Blog https://dev.to/nidhi-singh/your-agents-are-safe-alone-together-they-leak-kmo Security people call it the lethal trifecta: an agent that reads untrusted input, can access private data, and can send data out. Scanners look for it one agent at a time. But a research agent can read a poisoned page and hand the task to a sales agent, which reads the CRM and emails it out. Neither agent has all three, so neither gets flagged. Reach models the whole estate as one FalkorDB graph: agents, MCP tools, OAuth scopes, data stores, outbound channels and agent-to-agent handoffs. One Cypher query walks up to three handoffs and joins the three legs. A tool only counts if the agent holds every scope it needs. php MATCH a:Agent - :USES - t in:Tool - :INGESTS - src:Source OPTIONAL MATCH t in - :NEEDS - m1:Scope WHERE NOT a - :GRANTED - m1 WITH a, t in, src, count m1 AS miss1 WHERE miss1 = 0 MATCH chain = a - :DELEGATES TO 0..3 - r:Agent MATCH r - :USES - t read:Tool - :READS - d:Data OPTIONAL MATCH t read - :NEEDS - m2:Scope WHERE NOT r - :GRANTED - m2 WITH a, t in, src, chain, r, t read, d, count m2 AS miss2 WHERE miss2 = 0 UNWIND nodes chain AS x MATCH x - :USES - t out:Tool - :SENDS TO - k:Sink OPTIONAL MATCH t out - :NEEDS - m3:Scope WHERE NOT x - :GRANTED - m3 WITH a, src, chain, r, d, x, k, count m3 AS miss3 WHERE miss3 = 0 RETURN a.name AS entry, src.name AS untrusted, n IN nodes chain | n.name AS handoff, r.name AS reader, d.name AS private, x.name AS sender, k.name AS sink Nidhi tested it on 30 random agent setups against a brute-force checker. 98 of the 174 attack paths only exist across agents. | Scanner | False alarms | Paths found of 174 | |---|---|---| | Per-agent scan of tool manifests | 69 | 77 | | Per-agent scan with scopes | 0 | 76 | | Reach on FalkorDB | 0 | 174 | Reach Gateway enforces it live. It's an MCP proxy that keeps each task's calls in the graph and blocks the call that would complete a path. When a support ticket told a real model, gpt-oss-20b , to email customer rows to an outside address, the send came back BLOCKED by Reach . Because the ledger lives in FalkorDB, gateways in different processes share it: 60 of 60 cross-process exfiltration attempts were blocked, with a median guard time of 1.8 ms. Reach can also scan the MCP configs of Claude Desktop, Claude Code, Cursor and VS Code on your machine. In the builder's words. "Neither agent is dangerous alone, so per-agent tools see nothing." Nidhi Singh, Reach Try it. Add a DELEGATES TO edge for every agent handoff, and run one path query across all of them. Start free on FalkorDB Cloud https://app.falkordb.cloud/signup?cta=sec-handoffs . 2. Contain poisoned shared memory at the lowest cost Quarantine · Ankit Singh · See the code https://github.com/ankitzm/quarantine · Use the app https://web-production-6ea0b.up.railway.app A web page tricks one agent into rewriting a shared refund SOP. A second agent then refunds $4,800 without approval because the SOP says so, and hands off to a third, which tries to send card details to the attacker. Every step looks legitimate on its own. Quarantine records every agent turn, memory version, handoff, tool call and permission in one FalkorDB graph. Each memory write is a new version, so reading the clean SOP and reading the poisoned one are different edges. The trace follows the poison forward in time. php UNWIND $items AS inf MATCH e:Episode - r:READ - m:MemoryItem {id: inf.id} WHERE r.t = inf.at RETURN e.id AS id, r.t AS at, m.id AS via, 'READ' AS edge That time check keeps innocent agents off the list. On 20 seeded scenarios, scored against a separate reference implementation, the trace scored 1.000 precision and recall. Ignoring time dropped precision to 0.554, with 140 false infections, like an analytics agent that read the real SOP an hour before the poisoning. Then comes the cheapest cut. Infected agents are the sources, sensitive resources the sinks, and the cost of revoking a tool or rotating a credential is the capacity. MATCH a:Agent WHERE a.id IN $agents WITH collect a AS sources MATCH r:Resource WHERE r.id IN $resources WITH sources, collect r AS targets CALL algo.maxFlow {sourceNodes: sources, targetNodes: targets, relationshipTypes: 'PERM' , capacityProperty: 'capacity'} YIELD edges, edgeFlows, maxFlow RETURN maxFlow, e IN edges | id e AS edges, edgeFlows AS flows The min cut matched an exhaustive search in 20 of 20 scenarios and took reach to sensitive resources to zero in all 20. The max flow call took 3.4 ms at the median. Applying the cut deletes nothing: the poison is marked invalid and the clean SOP returns as a new version. Reads go through GRAPH.RO QUERY , and each demo visitor gets a private graph made with GRAPH.COPY . In the builder's words. "Having algo.maxFlow right next to Cypher was the best part. I didn't have to pull the graph out into another library to find the cheapest cut." Ankit Singh, Quarantine Try it. Store each memory write as a new version with a timestamp, and you can tell exactly who read the bad one. Start free on FalkorDB Cloud https://app.falkordb.cloud/signup?cta=sec-memory . 3. Trace a supply-chain attack ten hops deep Fallout · Kanishka Sahoo · See the code https://github.com/kanishka-sahoo/fallout · Use the app https://fallout.ksahoo.com · Blog https://ksahoo.com/writeups/fallout-supply-chain Agents run on code nobody on the team wrote. On September 8, 2025, an attacker phished an npm maintainer and published malware in chalk , debug and 17 other packages with billions of weekly downloads. Most exposure sits several dependencies deep, behind version ranges npm resolves at install time. Fallout loads npm into one FalkorDB graph as it was one second before the first malicious publish: 34,018 versions, 21,010 packages and 114,810 dependency edges. It walks out from the malicious versions one indexed query per hop. The agent answers only through MCP tools that run Cypher, and must cite the paths they return. UNWIND $frontier AS k MATCH m:Version {key: k} <- c:CAN RESOLVE TO - u WHERE c.incident = $incident RETURN DISTINCT k AS via, u.key AS node, labels u 0 AS kind The chalk/debug blast radius is 4,575 versions in 3,348 packages, out to 10 hops, found in about 0.4 seconds. On 300 exposure questions graded against npm's own resolver: | System same model | Made-up package versions | Recall | |---|---|---| | LLM alone | 10.9% | 0.493 | | LLM with the full lockfile in context | 0.0% | 0.890 | | Fallout agent with FalkorDB tools | 0.0% | 1.000 | Try it. Load your lockfiles and their dependencies as one graph, and ask which repos a bad release would reach before you need to know. Start free on FalkorDB Cloud https://app.falkordb.cloud/signup?cta=sec-supplychain . Two more AI agent security ideas worth borrowing Check a skill before your agent installs it. Bouncer, by Ayesha Mashiat and Mrittika Jahan, links agent skills to the accounts, domains and IPs behind known malware campaigns in a FalkorDB threat graph, and blocks bad skills before Claude Code installs them. With labels hidden on 305 known-bad skills, it linked 281 back to their campaign. A blocklist caught none. Watch the demo https://youtu.be/wTFI5vZTfNI . Repair memory instead of rolling it back. kintsugi, by Rupam Golui, records every read, write and handoff as a provenance graph in FalkorDB, then re-runs only the actions that depended on a poisoned source. The repaired memory matched a run that never saw the poisoned page. Watch the demo https://youtu.be/J3HBqwCQGMY . Poisoned memory is one of the patterns covered in 5 agent memory patterns from 647 Graph Hacks projects https://www.falkordb.com/blog/ai-agent-memory-graph-patterns/ . Want agents that answer from company data without being able to change it? See how Graph Hacks teams built a company brain with fixed, read-only queries https://www.falkordb.com/blog/company-brain-ai-agents-graph/ . Frequently asked questions What is AI agent security? AI agent security is the work of controlling what AI agents can read, remember, call and send, so that one bad input can't turn into a data leak or a harmful action. Why do per-agent security scanners miss attacks on multi-agent systems? They check each agent on its own, but many attack paths only exist across handoffs. In a Graph Hacks test on 30 agent setups, two per-agent scanners missed 97 and 98 of 174 attack paths, while one graph query found all 174. How do you contain poisoned shared memory in AI agents? Store every memory write as a new version, record which version each agent read and when, and trace the poison forward in time. Then use max flow and min cut over permissions to find the cheapest set of revocations that cuts infected agents off. FalkorDB runs both with its built-in graph algorithms. How do you stop prompt injection from spreading between agents? Record every handoff and tool call as graph edges. Before each outbound call, check whether the task already read untrusted input and private data, even through another agent. Keep that ledger in a shared graph database so every gateway sees the same history. How do I build an AI agent security graph on FalkorDB? Model agents, tools, credentials, data and handoffs as one graph, then write one path query from untrusted input to an outbound channel. Give agents a few fixed queries that run through GRAPH.RO QUERY, so they can read the graph but never change it. Map your agents before an attacker does Every project here runs on the same FalkorDB you can start with one Docker command, docker run -p 6379:6379 -p 3000:3000 -it --rm falkordb/falkordb:latest , or a free cloud instance. Load your agents, tools, credentials and handoffs as one graph, and ask what a single prompt injection could reach. Start free on FalkorDB Cloud https://app.falkordb.cloud/signup?cta=cta-bottom Not ready to build yet? Join the FalkorDB Discord https://discord.gg/Y2mMT9VdMy to get help from our engineers, share what you build, and hear about the next Graph Hacks first.