A closer look at what Privacy Enhancing Technology actually means for vector memory and where the software you use every day really stands.
There’s a category of software that nobody threat-modeled yet, and it’s the one most of us are using every day now. Every time you tell an AI agent something, a decision, or a code action, that’s a data collection event. Somewhere, in a data center rack, a provider just wrote down and stored a piece of you.
As we’ve moved further into thinking seriously about privacy, we’ve spent a lot of time reading comments on web boards, forums, the usual places people talk honestly when nobody’s watching. There’s a real divide out there. Some users feel powerless, like the decision was already made for them somewhere upstream.
Others feel genuinely liberated by what’s happening with current technology, like a door just opened that used to be locked. We sit firmly in the second camp with a strong leaning into privacy, and this piece is really an attempt to explain why and to walk through what’s actually happening under the hood when people talk about privacy in AI software, not just assert it.
Most memory products treat this the way software treated user data in 2012. Centralize it, store it in someone else’s cloud, and call the privacy policy the privacy strategy. We built VEKTOR the other way, local-first, zero egress, your SQLite file on your machine. But “we don’t send your data anywhere” is a start, not a finish. So we sat down and asked ourselves a harder question: if we actually held ourselves to the standard the privacy engineering field uses, Privacy Enhancing Technologies, PETs, where would we land?
The honest answer is partly there, further along than most competitors, and with real gaps we can name specifically. This piece walks through where we actually stand, what we built and hardened this week to close part of the biggest gap, and what’s still being worked on.
We’re not waiting for AI companies, corporations, or governments to define this future for us. That resonates with something we believe at a basic level: people should be in control of their own sovereignty, their own software, not dictated to by Silicon Valley or by any government. It’s an engineering constraint we build against. Local, air-gapped software is your highest ground as a citizen here. No corporation can be told what to do by a government if their reach never touches the provider's cloud because your data or their model was never in it.
We all have the ability to decide what software we use, who we support, and how much privacy we hand over to companies and governments. We don’t need to feel powerless. You make a choice every time you click on a set of terms, every time you hit accept or decline on a cookie banner, every time you allow a government to pry further into your software or your home under the guise of “if you haven’t done anything wrong, you have nothing to worry about.”
Any time I hear that line, I shake my head. Privacy is a right. It’s not something you forfeit based on your ability to prove innocence. It exists to protect human dignity, autonomy, and civil liberties, not to shift the burden onto the individual to demonstrate they aren’t guilty of something.
What “local-first” actually means, mechanically
“Local-first” gets used loosely in this industry, so we’d rather be precise than let it become another empty claim.
Your agent’s memory, every fact, preference, correction, and decision it’s ever stored, lives in a single SQLite file on your own machine. SQLite in this case is not a cloud service. It’s a file format, the same category of thing as a spreadsheet or a text document, except structured for fast lookups.
There is no process, no background job, no API call built into the system that would ship that file, or any piece of it, to a server we operate. Not because of a policy that says we won’t. Because the code path that would do it was never written architecturally. A policy is a promise a company can break, quietly, in a future update, under new leadership, after an acquisition. A missing code path is a structural fact you can go and verify yourself by reading the source.
The same logic applies to how your agent understands what you’re telling it. Most AI memory products compute embeddings, the numerical representation of meaning a system searches over, by sending your text to a cloud API.
That’s a second, quieter place your data leaves the building, easy to miss because it doesn’t look like storage, it looks like a normal API call in a network log. We compute embeddings locally, on your own hardware, using a small model that runs in-process. Nothing about turning your words into something searchable requires your words to leave your machine first.
Why Privacy Enhancing Technology is a real standard, with guidelines
Privacy Enhancing Technologies is an established area of research with a real taxonomy, built mostly for a different kind of problem than ours: hospitals sharing research data across institutions, companies running analytics across millions of users, situations where the challenge is learning something useful from a population without exposing any individual within it.
Agent memory is a different shape of problem. It can be one person, one machine, one agent, or a series of interconnected API tools like Slack via your work colleagues, holding what amounts to a private graph of that person’s own thinking or the whole team's. So rather than force our architecture to look like it solves the population-scale problem, we went through the actual PET categories one at a time and asked honestly which ones apply to us, and which don’t, and why.
Data minimization is the practice of collecting and retaining as little as possible, for as short a time as necessary. This is the one we can defend most confidently, because it’s structural, not promised. The write layer that decides what gets stored, we call it AUDN, doesn’t just append everything forever the way most memory systems do.
It actively deduplicates, resolves contradictions when new information conflicts with old, and runs a background consolidation process, REM, that compresses and lets low-value memory decay over time instead of accumulating into an unmanageable pile. Minimization here isn’t a setting you turn on. It’s what the system does by default.
Differential privacy adds carefully calibrated mathematical noise to a dataset so you can learn aggregate patterns from it without identifying any individual within it. It’s genuinely sophisticated engineering, and it’s also just not the right tool for a single-user, single-machine system. There’s no population here to protect anyone from. If we ever build something that aggregates data across many users’ devices, this becomes relevant again. Right now it would be a solution looking for a problem we don’t have, so we’re not going to pretend otherwise because it sounds impressive.
Encrypted computation, techniques like homomorphic encryption or secure multi-party computation, would let a system process your data without ever seeing it unencrypted, not even internally. Our own security layer needs to read plaintext to do its job, to scan for sensitive data before it leaves the system, to trace where a piece of information originally came from. That’s a real tradeoff worth sitting with rather than glossing over: the same visibility that lets us protect you from data leaving your machine also means the protection mechanism itself has to see what it’s protecting.
Encryption at rest sits between those two. Cloak, our credential vault, uses AES-256-GCM. That part’s real and shipped. The MAGMA memory graph itself, the actual memory content, sits as plaintext SQLite on disk, protected by whatever disk encryption you’ve set up yourself, BitLocker, FileVault, LUKS.
Desk chat tool with the ability for both local and cloud LLM models
Faraday: the tool we spent time building this week
We have built a component called Faraday, a gate that checks every consequential action your agent tries to take, a memory write, a file operation, a command run over SSH, before it happens. We’d talked about Faraday before mainly as a prompt injection shield. Going through it file by file this week, specifically through a privacy lens instead of a pure security one, taught us it’s doing more privacy engineering work than we’d been giving it credit for, and it also taught us where its real edges are.
Faraday scans outbound data for identifiable information: social security numbers, credit card numbers, API keys, private key material, email addresses, before that data leaves through any tool call. It’s worth being precise about how this actually works, because it’s easy to let people assume more sophistication than is really there.
This isn’t a model reading for meaning the way a person would. It’s closer to a fast, precompiled net of patterns, extremely good at catching things with a recognizable structure, a card number has a shape, an API key has a shape, and blind to things without one. A person’s name and home address written naturally into a paragraph has no fixed shape a pattern can catch. Knowing exactly what a tool can and can’t see matters more than knowing that it exists at all.
There’s a second piece, less common and, we think, more interesting. Faraday tracks where data actually came from locally, not just what it currently looks like. If your agent pulls something in from an external source, a fetched web page, an email, a search result, that data gets tagged, and the tag follows it through every subsequent use, hop by hop, with the full chain recorded.
So if something your agent read off the internet an hour ago quietly ends up as an argument in a command trying to send data somewhere, Faraday can trace that lineage back to where it actually entered the system. This is closer to what security researchers call information flow control, understanding not just what a piece of data is, but where it’s been.
It doesn’t appear on the standard three-category PET list, but it’s doing genuine privacy engineering work. It’s worth being precise here too: this tracking is scoped to data that flows through tool calls Faraday recognizes as external sources. Anything you type or paste directly into a conversation has no taint lineage, by design, since that’s genuinely your own authored data, not data from an unverified source. Coverage is real, and it’s specific, not universal.
When Faraday catches something, sensitive data in an outgoing action, or data traced back to a source it doesn’t fully trust, it doesn’t silently block or strip it out. It pauses and asks you to confirm, explicitly, before continuing, and it now explains why in plain language, not just what pattern tripped.
Only two things trigger an actual hard stop with no way forward except restarting the session entirely: an attempt to tamper with Faraday’s own files, and a canary token, a deliberately planted, fake piece of sensitive-looking data, showing up somewhere it shouldn’t, meaning something already tried to exfiltrate data it wasn’t supposed to touch.
Everything short of that is a decision handed back to you, not a decision made silently on your behalf. Once we saw it stated clearly, it was obviously the better design. Consent, not a black box quietly deciding what’s safe for you.
Live screen of synthetic self-preservation testing on Faraday
5 areas we hardened this week
Self-preservation now covers seven surfaces, not one. The check that stops anything from tampering with Faraday’s own files used to watch Claude Desktop’s configuration only. It now covers Cursor, Windsurf, Continue, VS Code, Cline, Roo Code, and Groq Desktop too. If you’re running VEKTOR through any of those, that protection now actually applies to you.
A compromised session now genuinely locks. If Faraday flags a session as compromised, tampering attempt or canary trip, it now blocks every further consequential action until you restart, matching how real endpoint detection and response tooling handles containment.
Status checks and the approval command stay available, so you’re never locked out of understanding what happened, but nothing else runs until a clean restart. Previously the flag was recorded but didn’t actually stop anything else in that session, which meant the label meant less than it implied.
Confirmation prompts now explain consequence, not just detection. A prompt that says “PII detected, approve to proceed” tells you what tripped, not why it matters. Every confirmation prompt across all five gate types, untrusted server, PII, memory poisoning, tainted data, and goal misalignment, was rewritten to state plainly what approving would actually do and when you should say no, in addition to the technical label.
This is the informed-consent principle from privacy engineering applied directly: a person granting consent needs to understand the tradeoff, not just see a warning banner.
We built the independent integrity watcher, and we’re being precise about exactly what it does and doesn’t cover. This was our biggest named gap: everything Faraday does only matters while Faraday itself is running and untampered, and until this week, nothing checked that independently. We built a background process, separate from Faraday’s own session, that runs continuously whether or not an AI session is even active.
It watches two things. First, the AI-assistant configuration files across all seven surfaces above, catching the exact persistence technique real supply-chain attacks currently use, injecting a rogue MCP server entry into an assistant’s config so it gets loaded and trusted automatically. Second, and this is the part that actually closes the sharpest structural gap, Faraday’s own enforcement code.
If any of Faraday’s own files were replaced at rest, the one thing that would notice before now was nothing, since a tampered gate file would simply stop enforcing anything with no error and no self-report. We tested this directly: we simulated tampering with Faraday’s own gating logic, and the watchdog caught it within its check interval and logged a clear, specific alert naming the exact file. That’s real, tested, and running.
It’s also not total coverage, and we want to be as specific about the boundary as we were about the win. The watchdog polls on an interval, not instantaneously, so there’s a small window between a change happening and it being caught. It currently runs via the operating system’s own task scheduler, which we’ve built and verified on Windows; the equivalent for macOS and Linux isn’t shipped yet.
It catches the specific attack pattern of a persisted config change or a tampered file at rest, not every possible thing malicious code could do without ever touching a watched file. And nothing currently watches the watchdog itself, so a sufficiently privileged attacker who disabled it entirely, rather than tampering with something it monitors, wouldn’t be caught by this layer alone. Each of those is a real, named boundary, not a hidden one.
The audit log is now tamper-evident as Faraday keeps a full record of every gate decision, every hold, every approval. Until this week, nothing proved that record hadn’t been quietly edited after the fact. We added a hash chain: each event’s record incorporates the previous event’s hash, the same principle git uses for commit history, so altering, deleting, or reordering a historical entry breaks every hash after it, visibly.
While building it, we found something worth naming rather than shipping quietly: turning this on against an existing history where older records predate the feature would have made the very first status check report the whole log as broken, since old records never had a hash to check. That’s indistinguishable from real tampering to anyone reading it, and would have undermined the feature on day one.
We fixed it to correctly separate records that predate the chain from records that are actually being verified, so the status honestly reflects what’s been checked versus what simply came before the mechanism existed. This is real progress on a category that doesn’t appear on the standard PET list at all, audit trail integrity, but matters directly to anyone who’d want to treat these logs as evidence later.
A hash chain proves nothing was changed without also rewriting everything after it. It doesn’t make the log cryptographically unforgeable against an attacker with total, patient access to the database and enough time to rebuild the whole tail of history. Closing that fully would mean anchoring the chain’s current head somewhere external and immutable, periodically, the way certificate transparency logs work. That’s not built yet.
Why we’re publishing the gaps, not just the wins
The instinct in a product update is to lead with what’s finished and quietly skip what isn’t. We’re doing the opposite on purpose, because a privacy claim without an honestly stated gap next to it isn’t really a privacy claim.
It’s marketing wearing the language of a field it hasn’t actually sat with. Anyone who’s spent real time in privacy engineering will see through the difference in about thirty seconds, and they should.
Where things stand right now, plainly. Minimization is real and structural. Encryption covers credentials fully and the broader memory graph only partially. Identifiable-data detection is real but pattern-based, not something that understands meaning yet. Data lineage tracking is real and, we think, genuinely uncommon in this space, but scoped to tracked tool calls, not universal.
Differential privacy and encrypted computation aren’t present for good, specific reasons rather than oversight. Independent integrity monitoring, our biggest named gap a week ago, is now partially built and genuinely tested, covering the configuration-injection and code-tampering surfaces specifically, with real named boundaries around polling interval and platform coverage, and the watcher-of-the-watcher problem still open. Audit trail integrity is new this week, tamper-evident by hash chain, not yet externally anchored.
Most software in this category doesn’t get asked these questions yet, mostly because almost nobody outside security research is asking them of anyone building agent memory right now. That won’t stay true for long. We’d rather be at the forefront and the ones asking first than answering to someone else later on.
VEKTOR Memory builds local-first persistent vector memory infrastructure for AI agents. Faraday is the security and privacy gate that reviews every consequential agent action before it happens. Full technical documentation at vektormemory.com.
Agentic Ai
Data Privacy
LLM
Security
Top comments (0)