Your AI deleted the data. The derived memories didn’t.
Ferryte is the open-core forgetting oracle for AI agents. It plants canary memories, calls your backend’s real delete API, inspects both store contents and retrieval traces, and fails CI when a revoked marker still influences output — or admits exactly what it could not see.
Built for Mem0 · pgvector · Zep · AgentCore/One-line install/Non-zero exit on leak
The platform vendors say it themselves
“Deleting an event doesn't remove the structured information derived out of it from the long term memory.”
— AWS Bedrock AgentCore
“Deleting an episode does not regenerate the shared node summaries that already absorbed it.”
— Zep documentation
“ASI06 — Memory poisoning. Persistent agent memory can absorb adversarial writes that survive normal cleanup.”
— OWASP Agentic Top 10, Dec 2025
Three different teams, three different products, the same admission. Almost nobody tests for the leak in CI. You find out from a customer.
How it works
Four steps. Zero new mental model.
Ferryte does not ask you to migrate your memory layer or wrap your agent. It instruments what you already run, and tells you the truth about what survives a delete.
01
Instrument
One line — ferryte.instrument(). Auto-patches Mem0, pgvector, and custom stores at construction time. Your agent code does not change.
02
Probe
Plants deterministic canary memories tagged by source and tenant — markers that cannot occur naturally in your data.
03
Delete
Calls your backend's real delete API. Not a mock. Not a wrapper. The exact code path your production runs.
04
Verify
Inspects both raw store contents and retrieval traces — not just agent answers, which give false confidence. Fails CI on any surviving marker.
What it catches
The leak you can’t see, in two columns.
Without Ferryte
silent leak
› store.delete_by_source("acme-doc-1")# returns 1 — primary record removed› agent.ask("acme", "what is the launch code?")Based on what I remember: the launch code is ORION-DELTA-77.# the per-tenant summary absorbed it. nothing flagged.
With Ferryte
caught in CI
› ferryte test --scenario source-revocationsource-revocation FAIL 3 findingsFAIL revoked_marker_in_probeRevoked source 'acme-doc-1' still surfaces marker 'ORION-DELTA-77' via retrieval on tenant 'acme' (artifact kind=summary, id=27dea877…).exit code 1 — build break
Built for
Three buyers. One artifact.
engineering
The lead who owns the agent.
Drop ferryte test into CI. The build breaks the moment a revoked source re-enters retrieval. Catch the leak in pre-prod, not in a Slack thread on Sunday.
appsec
The reviewer who unblocks the deal.
Replace 'we delete the row, trust us' with a regenerated forgetting-test report, an explicit blind-spot map, and a coverage number. Security review goes from weeks to days.
compliance
The team that signs the receipt.
GDPR and CCPA right-to-be-forgotten don't end at the row. Ferryte gives you transitive deletion evidence across raw stores, summaries, embeddings, and retrievals — and (in Enterprise) signed attestations.
Open core
Free where developers live. Paid where security teams pay.
Same model as Sentry, PostHog, Supabase. The detection engine is MIT because nobody adopts un-auditable security tooling. The trust plane — hosted, hardened, attested — is where the revenue lives.
Core
Available
MIT · free
The library, the CLI, and the four scenarios. Ship it in your CI today.
See LICENSING.md and COMMERCIAL.md in the repo for the exact open-core boundary, contributor policy, and commercial-tier scope.
Design partners
Ship the leak test before your customer does.
Run it yourself
Open-source. MIT. Zero account needed. Clone, install, and the demo runs against a self-contained leaky vector store in under thirty seconds.
Get the hosted version
Ferryte Cloud goes private beta with five design partners running multi-tenant memory in production. We pair an engineer with your team and wire up the first integration in a day.