▚ Writing
Writing
Notes on building memory for agents that has to respect who is allowed to see what.
Why agent memory leaks permissions, and why prompt-filtering can't fix it
sourceaccount-team
→
memoryno scope
→
recalldenied · leaked
Give an agent memory over permissioned systems and it quietly launders the permissions away. The failure mode, why the obvious fixes don't hold, and where the boundary actually has to live.
Matt Fleming
July 2026 · 5 min read
Read →
More writing
The same permission boundary, through six agent frameworks
We put one shared memory store behind six agent frameworks and tried to make team A's data leak into team B's recall through each framework's own API. It doesn't.
Matt FlemingRead →The clean install that went dark
A fresh Verity install returned empty for every recall. Nothing crashed. A fail-closed freshness fence couldn't tell "no data yet" from "stale."
Matt FlemingRead →Zero leaks isn't a benchmark. Here's the one we ran.
"Zero leaks" means nothing without naming the oracle. Here's how we reconciled Verity's Salesforce visibility against Salesforce's own access API.
Matt FlemingRead →Revoke a permission, watch it stop leaking on the next read
Verity makes zero live authorization calls at read time. Here is how a revoked permission stops leaking, and the exact window where it does not.
Matt FlemingRead →Can this API prove who is allowed to see this record?
A four-rung ladder for ranking SaaS source APIs by whether they can prove, per record, who is allowed to see it.
Matt FlemingRead →Access control belongs in the index. Not the model, not a post-filter.
There are three places to enforce who can see a memory. Two quietly break. Here is why the index pre-filter wins, and where it costs you.
Matt FlemingRead →