DEV Community: Vektor Memory

Commonsense Lessons from the Silicon Valley VC Cash Splash & Metaverse Fail

Vektor Memory — Tue, 21 Jul 2026 21:58:17 +0000

I made this slop image

Get ready for the mother of all rants, pump some more dark web market Ozempic peptides into your brain, and hold on to your discount Chinese-cloned Neuralink Kimi4-enhanced chips.

Being a solo developer is a strange kind of self-endured punishment that nobody really warns you about. You go in thinking the hard part is going to be the build.

The code, the architecture, the 18-hour days, and late nights arguing with your own logic until it finally clicks into place. And sure, that part is hard.

It should be hard and was much harder in the past, real coding with actual stubby human fingers. But here is the joke nobody tells you at the start.

The code part is approximately ten percent of the actual job. The other ninety percent is exposure and distribution. Shoving your work into the bloodstream of the internet and praying something sticks somewhere, like a picture of Nicolas Cage on a graffiti wall.

You haven’t got the face for it

So you do the social media dance. You post and repost. You rewrite the same article ideas ten different ways to appease the formatting bouncers and whatever invisible slot machine is currently deciding your fate that week.

You write threads, articles, comments, and replies mostly to bots. You engage with people who skimmed the headline and decided that was enough context to have an opinion. You try to sound insightful without sounding desperate, and somewhere in that grind you have the horrible realization that it does not actually matter whether people like what you made, the majority of people don't like most things anyway.

All that matters is that they react. Feed the beast, the algorithm.

The algorithm does not care if the reaction is thoughtful, angry, dismissive, or completely unhinged. It just wants movement. A response signal — in/out binary ones and zeros—feedback, compute goes brrrr.

Ten people loving your work, good. Ten people being haters and hating? That's great, even better!

A hundred people arguing about it and arguing with each other, and the mods arguing with the posters without having read past the first line, even better because now you are feeding the machine, and the machine is really happy, and a well-oiled feedback machine means a slightly longer shelf life for your post before it drops into the void forever.

I won; I truly am the eternal viral poop machine winner for this week!

Then you are crapped on by a better-written algo post, made by someone much smarter than you on how the system actually works v2026 Google updated agentic swarm-bot style, keyword-stuffed posts like a cheap stuffed crust pepperoni pizza made by a soulless chain pizza shop, only interested in cutting product quality for profits and footprint delivery population metrics, because the race is in the store, of course it is, as it sure as heck isn't in any of your food quality!

You know you want the gooey slop

And that is the moment it really hits you. You are not building your own thing anymore. You are working as a free employee of Google, Reddit, Facebook, and whatever new platform is currently pretending it is not those things, mostly full of rage-bait content, wearing a shady trench coat or the latest fluffy gradient css website. You feed them content, attention, behavioral data, and engagement loops, and in exchange they hand you visibility that is inconsistent, temporary, and increasingly gated behind a paywall you did not agree to but somehow still pay into with your time, just like all the social media news outlets?

It is an ouroboros. A loop of digital decay. Content creates reactions. Reactions become fresh data, and that trains the models. Models shape future content. And round it goes, getting noisier and more detached from reality every single spin.

The ouroboros of tech poop

Are you aware that Google has been quietly funneling search traffic toward Reddit threads for years now, only to turn around and extract that exact data to train its own models? It is one big hamster wheel of half-formed opinions from anonymous accounts being fed back into the machine and regurgitated as if they were wisdom; instead, we loathe the toxic rant posts to let off steam by a 14-year-old expert in a wide variety of subjects whilst holding their gaming console and licking Dorito-encrusted Cool Ranch fingers bought by their parents whilst typing.

What is worse arguing with a bot or a self-entitled Western teenager who is already an expert in upvote manipulation and multiple account creation?

What a glorious hot mess of absurdity we have built for ourselves.

A typical Reddit conversation

People like to call this ensh!tification, and while the word is crude, the mechanism underneath it is as precise as a Hollywood cosmetic surgeon with a scalpel and too much Botox filler. The system is doing exactly what it was designed to do, confuse and screw over facts and logic. Optimize for engagement, the tasty algorithm, at any cost, for anyone looking for actual real advice and solutions.

So naturally everything drifts toward whatever triggers the strongest reaction. Outrage and low-effort brain droppings dressed up as intelligent hot takes. And somewhere in that noise, actual builders are standing on a soapbox trying to get one honest sentence out before the crowd moves on to the next controversy.

This thread is now closed; piss off. That's it, you're banned for questioning my moderation.

When your game sucks, but your advertising budget is monumental
Would you like to buy a subscription to Evony?

The Perpetual Poop Machine

Now stack endless toilet paper dollary doos from venture capital on top of all this, and things get genuinely amplified and strange. Because while independent developers are scrapping over crumbs of attention, Silicon Valley is playing an entirely different game. It stopped being about building useful things a while ago.

Now it is about building imaginary narratives large enough to justify obscene capital allocation and getting moron tech influencers on Youtube to talk about it like they are the Howard Cosell of tech sports, the delusion runs strong based on Google ad revenues.

Youtube tech influencers keeping the Google shill real

I like Kimi this week, now I like Claude Fable on Extra High, OMG have you seen OpenAI’s update, Watch me make another rubiks cube!

This is where the obsession with what I like to call the perpetual machine comes in. The dream that you can build a system that feeds itself, improves itself, scales without limit, and thinks by itself and eventually becomes so large it is simply unavoidable.

Moore's Law of Silicon Valley Stupidity: AGI/ASI/NFI/T-1000 Cyberdyne.

The metaverse. PLOP FLUSH: 80 Billion down the toilet

Now with more autonomous agent swarms in everything.

Chinese Robotic Jarvis. We finally built it! Warranty: 12 months, Mandarin support only…

Sentient, sycophantic love squishies for lonely Asian and Western salarymen on maxed-out credit cards with token maxxing fetish flexes online to other betas!

Shut up and take my money!

Does she run on LLM tokens?

And if you say it with enough confidence, the money shows up 60% of the time, and it works every time, fast enough for people to forget about the next grift cycle.

Here is the part nobody wants to say out loud at the latest pitch meeting in a VC funded trendy office with 80’s nue-retro furniture with chill-out rooms and standing reclinable massage lumber support sofas with vapor-infused patchouli scents.

A system that consumes its own output without grounding eventually turns into sludge. If your inputs are weak, your outputs degrade. If your feedback loop is noisy, your system does not clean itself up, it amplifies the noise for eternity with timed gated subscriptions.

Scaling that poop loop with more money does not fix the underlying rot. It accelerates it. You are just building a bigger, faster machine for producing garbage, and calling it disruption on the way down.

Tech poop art in real life

I think of it as the perpetual Gödel poop machine. A sentient Jarvis style ouroboros contraption built entirely to gorge on its own output and spit it back out slightly warmer and cuddlier, making you seem smart, but really you're just more delusional and confusing to everyone.

You can fit 8 Gödels in this bad boy.

It is a beautiful loop. It is genuinely VC future fund money worthy. I am honestly surprised nobody in a trendy, 100% polyester plastic fleece vest hasn’t fully commoditized the perpetual Gödel poop machine yet. How much would people pay for that?

Maybe eighty billion dollars if you wrap it in a VR harness and slap a Meta logo on the side or, better yet, Gucci or Balenciaga! VR-Poop titanium Limited edition.

I want one daddy, please!

Meta and the Eighty Billion Dollar Lesson

Which brings us to one of the most expensive case studies in recent memory. Meta and the failed, illusive, imaginary metaverse.

On paper the idea sounds unstoppable.

A persistent virtual world, I want that!

I just lost 80 billion of ad revenue on an imaginary universe

A new social layer replacing physical interaction with digital presence. And to make it real, you pour in tens of billions of dollars. Hardware, software, ecosystem, creator tools, the works. What could possibly go wrong?

Well. Everything that involves actual humans using it, as it turns out.

Because people do not adopt technology based on your ambitions. They adopt it based on use case, efficiencies, problems it solves, or just influencer hype in some cases. VR, for all its genuine progress, still has issues baked directly into the hardware experience. You have to strap something to your face like a dork. You isolate yourself from the room you are standing in and the other people; the immersion is also the distraction.

You need physical space that most people simply do not have. You deal with battery limits and heat and the faint nausea creeping in around the twenty-minute mark. You commit your attention in a way that a flat screen never asked of you.

Even Jaron Lanier knew that when he made the first iphone VR googles in the 90’s. He gave up, realizing it was futile, and now he just plays his flute for obnoxiously wealthy Silicon Valley tech vampires while wondering if Microsoft is actually listening to any of his prescient ideas on data dignity while they jack up their cloud pricing.

Wow man, Microsoft profits are so spiritual.

VR is fine for games. It is great for simulation and training. It even works reasonably well for fitness. But as an always-on social environment meant to replace your living room, it is a very hard sell, and Meta sold it anyway.

If I were setting out to build a VR video game with a fraction of that budget, I would not need eighty billion dollars, and at the end of the process I would actually have a working game to show for it even if it was VR Dragon Lair or Space Ace.

VR Space Ace, now thats a game worth making

Help me understand how you mothball an eighty billion dollar project. Where did that actual money from overpriced, annoying scrolling ads actually go?

How does a company with that much talent and that much data not learn from Sony and their Home project years earlier, which I genuinely thought was brilliant? I thoroughly enjoyed Sony’s Vision and was perplexed when it closed. Why….

I spent real time in Sony Home and thought it was the beginning of something great, clunky as it was. I also remember a pterodactyl VR contraption from the nineties, some monstrosity in an arcade or a 90’s rave, chasing a pixelated green flying blob for a grand total of five minutes before getting kicked off the machine because people were waiting in line behind me.

Shut the F**k up Donny!

My friends and I joked for years about retiring into our recliners fully immersed in VR, half serious, thinking about a world and vision that the B-grade Bruce Willis movie Surrogates would evolve into, like it was a prescient documentary from the future.

“How long is it since you’ve been out without a surrogate?

Meta’s mistake was not building VR, that was the only good idea. The mistake was trying to manufacture a behavior before it naturally existed in the wild and not actually listening to what gamers and users actually want.

Meta watched Player One like the rest of us and got excited and then realized they were not Steven Spielberg. That's it, no punch line, you're not Steven Spielberg, dumbass. They should have given the 80 billion to Spielberg, and he could have built the actual VR Oasis world!

You know you want to ride this bike in VR

They built the infrastructure before the demand and assumed that if the platform was big enough, people would simply reshape their entire social lives around it out of sheer gravitational pull.

That never happened and crashed and burned, Hindenburg disaster blimp-style.

Poof up in smoke 80 billion gone

Instead users treated VR exactly like what it actually is. A powerful but occasional toy distraction. Not a replacement for reality. Not a new default state of human existence. Just something you dip into for a while whilst friends are over at your house and having a few drinks showing off your gadgets, and then you take the goggles off your face and go eat dinner with a slight dizzy feeling, VR legs not fully formed yet.

And because the core habit never stuck, everything downstream of it struggled too. Creators did not see enough upside to commit. Users did not return consistently enough to matter.

The social layer felt hollow, like a mall built in an overly engineered, soulless town nobody moved to yet, maybe in China. The entire system started looking like a very expensive experiment quietly waiting for a reason to justify its own existence.

Poking at it with a stick, are you alive or dead? Do something…

The latest reporting backs this up too. Meta has been pulling back from heavy first party VR world building, cutting Horizon focused teams, and shifting more attention toward third party games and broader ecosystem support, pushing more of Horizon Worlds toward mobile rather than the headset.

The core mistake was trying to force a social metaverse platform onto a medium that users kept treating as a niche device for gaming, fitness, and a handful of immersive apps. Overloading the headset experience with Horizon centered priorities appears to have actively hurt game discovery and developer momentum, which is the exact opposite of what you want when you are trying to build a habit forming ecosystem.

At that point the outcome is predictable. Quiet pullbacks. Strategic pivots dressed up in press release language. A sudden and total shift in narrative. Suddenly the metaverse is not the main thing anymore. Now it is AI infused with tokens, agentic harness tooling and loop efficiencies, whatever the latest BS buzzword tests best this quarter—and is distributed by hungry but humble middle management for corpo slaves to regurgitate to naive overcharged consumers.

The story changes over the cycles. But the lesson stays exactly the same.

Capital does not create demand. It never has. It never will. You can force feed a market all the money in the world and it will not make people want to strap a computer to their face and pretend their kitchen is a beach in Bali.

Meta proved that point glaringly in their failed, expensive experiments.

Build it and they will leave

Learning to Love the Slop

The real challenge, the actual cyberpunk challenge if you want to call it that, is learning how to love the slop. Embrace it, wear it. Make it better without billions of dollars behind you. That is the real work. That is the unglamorous hero arc nobody puts in a keynote.

Because silly con valley doesn't push real innovation, they back their own slop-funded players like a drug-dealing fentanyl gang on a street corner selling future tickets to recouping their own exit profits on the back of superannuation 401K funds leaving the naïve holding an empty bag of promises.

You come to terms fairly quickly with the fact that you will never have oodles of cash to afford a rack of Cerebras chips in a data center dropped next to a school in some low-income neighborhood, humming away twenty-four hours a day, drinking the water table dry so a chatbot can rewrite a 200-location European vacation itinerary to brag about influencer style to 5-second swipers who are vaguely interested enough to leave a witty, snarky remark.

So instead the bigger players reach for the next best thing. Somebody else’s data, scraped and repackaged, then handed back out for free with a little something extra riding along in the background.

Because here is the part that took me a while to fully appreciate after being abused by the algorithm of false dreams. The stolen data was never really the prize. The real value is the data hidden inside the stolen data. The behavior of the people using the free tool built on top of the stolen data.

That is the four-dimensional chess play, and credit where it is due, some of these open-source Chinese LLM operations play it extremely well.

Then you cap it off with robotic products mailed to your house with support lines only offered in a language most of your customer base does not speak. No physical service centers.

The final cherry on top is embedded surveillance software that phones home with the users data, check mate!

Maybe a hidden component that quietly fails right after the warranty window closes, timed with an accuracy that would be impressive if it were not so cynical.

And when the customer finally gets fed up and calls for help, they get bounced through a gauntlet of nonexistent support centers and shell suppliers until they simply give up out of exhaustion.

They are training for your jobs

Well played, honestly—evil and bureaucratic synergy in perfection. It would be illegal in most sane jurisdictions if the people meant to regulate this stuff were not so busy chasing their own tails on other issues, arguing about rebates and surcharges while the actual structural problems walk right past them unchecked.

But here is the difference between that and what a solo builder can actually do. You build. You listen, genuinely, to the people using your product who are annoyed enough to leave a comment about what is broken.

You strategize. You fix it. You test it again. You refine it. And then you do the thing almost nobody wants to do, which is stick your own face directly into the dog food bowl and eat your own slop, you learn to love it.

You use the thing you built every day as a sign of stoicism; it's like guerrilla warfare. You feel the friction yourself instead of reading about it in a support ticket. You improve it. You refine it again. You go for a walk to clear your head.

You come back and eat some more of your own sloppy dog food. You keep doing that, on repeat, until the bugs stop showing up in the places you already checked — Fable 5 on max effort backed up with Grok4.5, Kimi and Gemini 3.5 can't find any bugs; the slop starts to feel good, not enough to pay for overpriced ads, still just free social media posts only so you don't have to feel any shame of selling out.

You do not beat your own LLM tools with a stick either. At some point you accept that most people, myself included on a bad day, are not going to outthink a system trained on a genuinely staggering library of Anna archive textbooks and code and Andy Warhol art prints. So instead of fighting it, you start asking it the right questions.

Picasso was right…

You point it at search, at whitepapers, at whatever the current edge of the field actually looks like, and you let it help you get there faster. Then you eat a little more dog food. And somewhere after weeks of revisions, painstaking and unglamorous, you end up with something that does not resemble Silicon Valley slop anymore. It resembles something that actually works, built by one person who cared enough to keep going after the excitement wore off. No ads, no VC funding, just code ideas and genuine interest in improving your slop craft.

What Actually Comes Next

Here is where things get more interesting, because the direction the industry is drifting toward now is actually a lot more grounded than the last decade of moonshots. Instead of chasing one single giant virtual world to rule them all, the focus is shifting toward smaller, more practical systems powered by AI, a harness of valuable, usable, essential tools we are all addicted to.

These so-called thinking machines, when they are being honest about what they are, are not magical entities plotting in the dark. They are productivity amplifiers. They help you write, code, design, search, prototype, and iterate faster than you could alone. They lower the cost of creation. They lower the barrier to entry for someone with an idea and no funding round behind them. They let a small team, or a single stubborn developer working out of a spare room, do what used to require an entire organization and a floor of office space.

And that changes the game in a way that actually favors the little guy for once. The advantage stops being who has the biggest data center or the largest funding round and starts becoming who can move fastest. Who can actually listen to their users instead of a board deck. Who can refine relentlessly. Who can solve real problems without getting lost inside their own narrative about how important the problem is.

Meta’s own recent moves reflect this shift whether they admit it out loud or not. The messaging coming out of their developer updates and conference appearances increasingly leans toward better tooling, better profiling, and more sustainable ways to ship apps, rather than one monolithic metaverse swallowing everything else. The framing that actually makes sense going forward is not one massive VR world. It is a constellation of AI assisted experiences that help people build, navigate, and personalize smaller worlds without needing a nation state budget to do it.

The simplest explanation for why Meta burned through so much cash so fast is that they tried to solve too many hard problems all at once.

Hardware comfort, social behavior, content supply, developer incentives, and platform economics, all bundled into a single moonshot with a single name attached to it. When a company spends at that scale and the user habit does not deepen fast enough to justify it, the result is usually a strategic retreat, a round of layoffs, and a carefully worded focus reset, which is more or less exactly what has been happening inside Reality Labs.

The instinct that this is all one big VC money splash is directionally correct, but the sharper version of the argument is this. They funded the infrastructure before the demand had a chance to mature, and then they had to keep funding it just to justify the money already spent. That is a textbook sunk cost trap, just with a few more zeros attached than usual.

For a Solo Developer, This Is Both Brutal and Empowering
Brutal because you still have to battle the distribution war every single day. You still have to deal with the algorithmic clown circus, still have to shout into the void and hope something echoes back louder than silence.

But it is empowering because for the first time in a long while, you are not outmatched on raw compute capability or floors of developers and AI researchers. You can build real systems with a laptop and an incredibly stubborn cyberpunk streak. You can iterate quickly, test ideas in days instead of quarters, use the tools you are building on yourself, break them, fix them, and repeat the whole loop until it actually works the way you promised it would.

No hype required. No eighty billion dollar bet on a headset nobody asked for. Just big balls or ovaries and a gigantic middle finger to Silicon Valley.

And maybe that is the real divide quietly opening up right now. On one side you have capital driven narratives chasing scale before there is any real substance underneath them. On the other side you have builders grinding through reality, refining things that people actually use, day after unglamorous day.

The slow phase of real growth

The uncomfortable truth sitting underneath most of Silicon Valley’s biggest missteps is that they keep trying to skip the adoption phase. The phase where a product actually earns its place in someone’s life. Where it proves itself in small, unglamorous, often invisible ways. Where it quietly becomes part of someone’s routine without them ever consciously deciding to let it in.

Apple is very good at that, even if they fumbled AI. Devices that work unobtrusively.

That phase cannot be rushed with money. It cannot be hacked with a rebrand or a slicker landing page. And it absolutely cannot be replaced with a confident story about the future, no matter how many keynote slides back it up.

Meta did not fail because VR is fake. VR works. VR is genuinely useful in the right context. Meta failed because it tried to skip the slow part and buy its way straight to the destination.

It spent an enormous amount of money on a future state before the present day product had earned enough pull to justify it. It aimed for a civilization scale platform before it had a single must have daily habit locked in. That is exactly why the whole thing became vulnerable to cost blowouts, internal resets, and a strategic retreat the moment the growth story stopped matching the spending story on the balance sheet.

It failed to understand what users actually enjoy: community-based absorption in sharing in the wonder of a gigantic fantasy world.

A shared virtual world only works if there is a real reason to return, a real reason to invite someone else in, and for creators to keep feeding it new life, a feeling of belonging to a higher purpose than mundane, boring real-life tasks, escapism.

Meta never fully solved all three at the same time. The social layer felt awkward more often than it felt alive. The content layer was inconsistent at best. The creator economy underneath it all was too thin to make the whole environment feel like a real place instead of a novelty demo you show your friends once and never open again.

There is a basic behavioral truth hiding in plain sight here too. Most people do not actually want to live inside a persistent virtual world, even the ones who are genuinely curious about visiting it. People want selective immersion, not total immersion. That single fact explains why VR has found real, lasting traction in gaming, simulation, exercise, and specialized training, and comparatively little traction as a replacement for everyday social life.

In '93 I played this for 5 mins before being asked to get out

The Better idea

The thesis, the one I actually believe, is that the future is not one giant VR world. It is a constellation of AI assisted micro worlds. People will spend more of their time in smart overlays, creator built spaces, social games, simulation tools, and mixed reality moments than they ever will inside one grand metaverse city built by a single company with a single vision of what your social life should look like in the Oasis.

That path is simply more plausible because it matches how people already behave, instead of asking them to behave differently because a roadmap said so. If you want to solve a production problem, AI is genuinely useful for it. It can generate assets, speed up prototyping, assist with moderation, improve discovery, and cut the cost of world building down to something a solo developer can actually afford.

In other words, AI is the tool that might finally make VR useful enough to survive on its own merits, instead of remaining a marketing slogan bolted onto the side of a headset nobody quite knows what to do with once the novelty wears off, or just more slop ads within VR worlds—who knows?

So the real lesson buried under all of this is not that VR was some elaborate scam, and it is not that AI is the next perpetual poop machine waiting to happen, though it certainly could become one if the industry is not careful about grounding it in something real. The lesson is that platform ambition has to follow human behavior. It does not get to override it just because the funding round was large enough to make everyone in the room stop asking hard questions.

Embrace the slop

Meanwhile the solo developer sits there juggling everything at once. Building, marketing, debugging, writing, posting, replying, and feeding the machine while trying to not get consumed by it in the process.

Watching billion-dollar VC experiments rise and quietly fall while shipping small, unglamorous updates that actually make something a little bit better for the handful of people who actually use it.

It is not glamorous. It does not make headlines. It does not attract a made-up fantasy valuation with more zeros than a bitcoin has transaction hashes.

But it is my real slop, and I love eating it.

And in a landscape absolutely drowning in noise, that might genuinely be the only thing left that still matters: eat your own /loop slop, eat the dog food.

Yummy!

VEKTOR Memory builds local-first, privacy-preserving persistent memory infrastructure for AI agents. Full technical documentation and changelog at vektormemory.com/docs.

Humour
Gonzo Journalism
Rant
Technology
VR

Vörwatch: The VPS Monitoring Tool

Vektor Memory — Sat, 18 Jul 2026 07:50:31 +0000

Eleonora Sky Pexels

Watching a single production box without a SIEM or a dedicated Security Team

Another weekend coding project, we were trying to work out whether a spike in attacker IPs in Nginx traffic was a typical harmless provider web crawler or something worse, swarm bots snooping.

We didn’t have an answer because no SIEM tools were installed on the server box that had been watching closely enough to know exactly what the traffic severity was. You can run standard IP traffic reports in the Ubuntu server and have Claude search who and where the IPs come from online, but this is a very manual, ad hoc process. Or go to Cloudflare reports, which can be limited depending on your plan type.

That gap is common for anyone running a VPS outside a big cloud provider’s managed security stack. You get Cloudflare reports, a firewall, maybe fail2ban if you set it up yourself, and then a lot of waiting, testing, and manual reporting.

Enterprise anomaly detection exists, but it assumes a fleet of machines, a SIEM ingesting logs centrally, and a security team’s budget. None of that fits a developer running a Linux server. Plus, there is a lot of telemetry and lock-in once you choose a system because the IP detection data lists are embedded into their services, as that is part of their secret sauce.

Or use Wazuh or Security Onion, which requires a manager server plus agents installed on each monitored host; a dedicated team of security helps as well. These are more geared towards end-to-end detection via GUI console, not a lightweight, compact first line of defense reporting tool built into the server.

So we built Vörwatch — Vör’s Watch, named for the Old Norse goddess of vigilant awareness, described in the Prose Edda as “wise and inquiring, so that nothing can be concealed from her.” All the good names are already taken by the big corpos so that's the best we can do on short notice, ok?

It’s a single bash script. No daemon, no database, no agent phoning home to a vendor’s cloud. It runs off cron, keeps its state in flat files, and does one job: notice when something on your server looks different than it did yesterday. This keeps with our privacy-enhanced technology ethos and is open source and free, just pure love, GitHub and minimal server storage space.

I like Linus Torvalds's approach: build it, put it on the net, and if people are interested, they will use it, improve it, and store it for you for future use.

Why we didn’t reach for an existing tool

Because where is the fun in a weekend DIY project in grabbing something off the shelf, we already run fail2ban and ufw on our own infrastructure, and they do a great job at the layer they’re built for: repeated failed logins, known bad ports. What they don’t do is tell you when a critical config file changes, when a new process starts talking outbound to an IP your server has never contacted before, or when nginx traffic quietly shifts from “normal load” into "someone's bots are scanning for exposed endpoints.”

That’s the layer between “firewall rules” and “full SIEM” that most single-server setups just leave empty. We looked at what was actually attacking our own VPS before deciding what Vörwatch needed to catch.

Combined fail2ban logs across our jails: over 1,600 unique IPs blocked and 40K worth of attempts logged in a two-month window, mostly malicious bot swarms. When we pulled the nginx access log through Vörwatch’s reputation scoring during testing, the top five source IPs by request volume looked like this:

115.186.231.43 35 requests [risk 1]
3.99.128.211 17 requests [risk 2]
216.73.217.6 8 requests [risk 5]
34.56.201.30 5 requests [risk 1]
40.223.148.196 4 requests [risk 1]

Notice that the risk ranking doesn’t track the request count. The IP with the fewest hits came back rated as most dangerous, because AbuseIPDB had real abuse reports against it that raw traffic volume alone would never have surfaced. That’s the exact blind spot a request-count-only monitor has, and it’s why we built the reputation layer as an optional add-on rather than skipping it.

What it actually checks

Vörwatch runs these detection passes on a cron schedule you set, defaulting to every 15 minutes:

File integrity monitoring. SHA-256 hashes of the files that matter most on any Linux box — sshd_config, passwd, shadow, crontab, nginx.conf, authorized_keys — checked against a baseline you capture. Any change gets flagged.

Listening port baselining. You capture what’s currently listening, and anything new that shows up later gets called out by name.

Outbound connection tracking. The first time your server talks to a new IP, that connection gets logged and checked against a public threat blocklist. Most servers have predictable outbound patterns. A new destination, especially one already flagged as bad, is worth a second look.

Process tree anomaly detection. This catches a specific and common attack signature: a web server or container process spawning a shell. If nginx suddenly has a bash child process, that's not a normal Tuesday, and it's exactly the kind of thing that's easy to miss scrolling through ps output by hand.

Nginx traffic analysis. High request volume from one source, or a burst of distinct 404s that looks like path scanning, both get flagged with the specific IP and count attached.

SSH cross-reference. Recent connection attempts get checked against the same blocklist used for outbound traffic, so a known-bad IP hitting your SSH port shows up in the same report as everything else.

Package vulnerability scanning. Every check cycle, Vörwatch can cross-reference your installed package list against OSV.dev’s free vulnerability database — one batched API call, not one per package, so it’s cheap even on a box with hundreds of packages.

The catch with a feed like this is volume: OSV.dev returns every historical CVE or USN ever filed against a package version, including old and already-patched-elsewhere entries, which on an older Ubuntu box can mean dozens of packages with hundreds of IDs apiece. The report caps what’s shown — top packages by CVE count, top IDs per package — so you get a readable summary instead of a wall of text, while the full uncapped list stays in a cache file if you need it.

Rootkit and backdoor scanning. If chkrootkit or rkhunter is already installed, Vörwatch shells out to it and folds the result into the same report — no new tool to learn, no separate log to check. Because a full filesystem scan is heavier than everything else Vörwatch does, it's rate-limited independently of the regular check cadence, running at most once a day by default regardless of how often check itself fires. Any hit is treated as urgent, the same tier as a blocklist match or a changed critical file.

CIS-style hardening spot-checks. Not a full CIS benchmark run — just the handful of settings that matter most and are easy to drift on without noticing: whether root login and password authentication are still enabled in sshd_config, and whether /etc/shadow and /etc/passwd still have sane permissions. These only re-alert when the finding set actually changes, so a known, unfixed issue shows up once, not every 15 minutes forever.

DNS query anomaly detection. Off by default, since not every box runs a local resolver that logs queries. If you point it at one — dnsmasq or systemd-resolved — Vörwatch tracks first-seen queried domains the same way it already tracks first-seen outbound IPs. A server suddenly resolving a domain it’s never asked for before is often the earliest visible sign of something new running, before it ever shows up as an outbound connection.

CISA KEV cross-reference — cross-checks OSV-found CVE IDs against CISA’s Known Exploited Vulnerabilities catalog (free, no key, actively maintained) so you can tell “OSV found something historical” apart from “this is confirmed being exploited right now” — a KEV match is treated as high-priority and emails immediately if configured

Two optional layers sit on top. A free AbuseIPDB key turns on the 1-to-5 reputation scoring shown above, scoped deliberately to just your nginx top-5 source IPs and cached for a week, so it never costs more than a handful of API calls per report.

A free Resend account turns on email notifications: urgent alerts (blocklist hits, file tampering, attack-pattern traffic) send immediately, everything else lands in a weekly digest instead of flooding your inbox every 15 minutes. You can change the send dates more or less depending on your needs.

The design decision we kept debating with

Vörwatch does not ban anything. It never runs ufw deny. It never calls fail2ban-client banip. It never touches iptables.

That’s deliberate, as we already have fail2ban. Automated banning based on heuristics carries a real false-positive cost on a single production box.

You don’t want a monitoring tool locking out a legitimate user, or worse, locking you out during a false alarm at 3am when nobody’s watching to notice the mistake. Every alert Vörwatch generates includes the exact command you’d run to act on it, but the decision stays with a human.

If you want full auto-remediation, something like CrowdSec exists for that and can run alongside Vörwatch. Vörwatch’s job is making sure the signal reaches you clearly, not deciding what to action automatically on your behalf.

Running the wizard

No runtime to install, no compiled binary to trust. It needs bash, the usual coreutils, iproute2, procps, and curl — things that are already sitting on almost every Linux box.

git clone https://github.com/Vektor-Memory/Vorwatch.git
cd Vorwatch
sudo bash install.sh

The installer wizard walks through an interactive setup: where to store state, how often to check, whether to add an AbuseIPDB key, whether to turn on email digests. Press Enter on any prompt to take the sensible default. sudo bash install.sh --defaults skips the wizard entirely and copies a template config you can edit by hand.

npm install -g @vektormemory/vorwatch
sudo vorwatch-install
It’s also on npm, under our org scope: https://www.npmjs.com/~vektormemory

Once it’s running:

vorwatch baseline # capture current state as "known good"
vorwatch check # run one detection pass
vorwatch install # wire up the cron job
vorwatch status # confirm everything's live
vorwatch report today # see what's happened

Why this exists

We didn’t want another dashboard to check. We wanted something that sits quietly in the background, runs its checks every 15 minutes, and only speaks up when something is actually worth attention. That’s the whole design philosophy in one line: recommend, don’t act, and don’t ask for more of a person’s time than the situation deserves.

It’s early days for the project, and there are almost certainly edge cases we haven’t hit yet. If you run a VPS and have ever wondered what’s happening on it between the moments you’re actually looking, we’d appreciate you trying it and telling us what feature additions it needs so we can improve it.

Top 5 IP risk list

The code is Apache 2.0 licensed and lives at github.com/Vektor-Memory/Vorwatch. Bring your own API keys, keep your own data, and never worry about a bash script phoning home with telemetry data it shouldn’t have.

VEKTOR Memory builds local-first, privacy-preserving persistent memory infrastructure for AI agents. Full technical documentation and changelog at vektormemory.com/docs.

Security
Information Security
Siem
Linux
Monitoring

The Problem Claude Cowork & ChatGPT Work Mode Doesn’t Solve: Remote Infrastructure HITL Tasks

Vektor Memory — Sat, 18 Jul 2026 00:34:08 +0000

Cloak_SSH & Passport: How six tools we built provide you with backups, safety, and security for your keys.

Before Cowork/Work Mode existed

For most of the last four years, using a chatbot against your own infrastructure meant one of three average options. You pasted file contents into the chat by hand, clogging up the context window.

You built a bespoke plugin or function-calling backend just to shell out to your VPS or PC. Or you gave the model standing, unscoped credentials, and hoped that it didn't go rogue, deleting files or rewriting sensitive information without a backup made.

Cowork mode and equivalents (OpenAI’s file/work tools, Claude’s desktop file access) solved the local half of this problem: an agent can now read and write files in a folder you point it at without a custom integration.

They are useful tools but don’t fully solve all the remote issues. The moment your actual work lives on a VPS, a home server, or a machine on a private network, desktop file access stops being relevant. You’re back to opening a raw, permanent SSH tunnel and trusting the model with it indefinitely without backups.

The tool that we built, Cloak, an ethical, transparent SSH tool, exists to close that specific gap: remote command execution and remote file access, with the credential handling and approval mechanics that standing SSH access doesn’t give you by default.

And you can use Cloak in conjunction with Co-Work to fill in any missing gaps those systems can’t do.

What Cloak actually is

Cloak is not one tool. It’s a hybrid, multiple tools bolted together on purpose working in synergy:

An SSH execution layer (cloak_ssh_exec, cloak_ssh_approve, cloak_ssh_plan, cloak_ssh_backup, cloak_ssh_rollback) that runs commands on a remote host, classifies each command by risk before it runs, and gates anything destructive behind an explicit approval step.
An AES-256 encrypted credential vault (cloak_passport) that stores SSH keys, API tokens, and secrets separately from the execution layer, releases them only on request, and is designed around the assumption that keys should never sit at rest on the machine that's being administered.

What’s specific to Cloak is that both tools are wired together: the execution layer calls the vault mid-command, uses the credential for exactly one operation, and the credential never persists past that operation. That’s the actual design decision we built after 6 months of trial, error, and refining, and we eat our own dog food daily and know that it works perfectly.

And the ideas were not borrowed from other devs' code online, they evolved from resolving the challenges we were facing daily using LLMs. And it didn’t take a floor of overpaid AI researchers in Silicon Valley or oodles of VC money either.

Cloak Tool Diagram

Security, the standing-key problem

The default way people give an AI agent SSH access is to drop a private key in ~/.ssh/ on the box the agent runs from, or worse, on the target box for convenience, and leave it there. That key is now a permanent artifact. If the agent's environment is ever compromised, or if a session log leaks, or if the sandbox itself gets popped, that key is sitting there, valid, until someone remembers to rotate it.

How often does your team rotate your VPS keys? Not very often in most cases, unless you are slightly paranoid about security or just very thorough.

Cloak’s vault pattern inverts this. The pattern actually used in production, verbatim from how it works in practice:

cloak_passport({ action: "get", key: "some-host-hop" }) → returns keyText
cloak_ssh_exec writes that key to a scratch file, uses it for exactly one SSH connection, then deletes (or shreds) the scratch file in the same command block — never as a separate step.
The key never touches disk outside that single command's lifetime. The “same command block, not a separate step” detail matters more than it sounds like it should. If the cleanup were a second, independent call, a crash, a timeout, or an interrupted session between step 2 and the cleanup would leave the key on disk. Bundling write-use-shred into one atomic shell invocation means there’s no window where an interruption leaves a credential behind.

The corollary is that a compromised target host learns nothing permanent. In an actual documented case, a private key that had been resident on a VPS was pulled and re-homed into the vault specifically because a standing key on the box being administered is a pivot risk if that box is ever compromise, an attacker who gets a shell on the target doesn’t get a key that also opens other systems, because there isn’t one to find.

We can show you the logs below, and the majority of attacks are now agentic bots. It's a new world, and it only will become more nefarious as trillions of bots swarm the networks and ping your servers for remote access to open ports. And these are small numbers; imagine a large corporation or a hot target that stores customers' credentials.

Combined VPS logs: roughly 1,640 unique attacking IPs blocked and 41,934 malicious requests/attempts logged across both jails, over the last 67 days

We do not store any customer info or data as per our PET policies, so they are pointless attacks, not that the bots would know that, as they are hunting everything on a 24/7 cycle via zombie hosts or self-replicating bots making bots.

In November 2025 a campaign (tracked as GTG-1002) demonstrated autonomous AI agents coordinating attacks across 30 organizations simultaneously, with 80–90% of the operation running without human input, the agents shared intelligence in real time and adapted their approach as defenses responded.

That’s qualitatively different from a static botnet replaying the same script: it’s an adversary that notices what’s blocking it and route around that specific thing, live.

OpenClaw, an open-source AI agent framework that launched in January 2026, had thousands of instances left exposed by default configs and got hijacked into a botnet within weeks, meaning some of the “swarm” doing this kind of attack now is itself made of compromised agentic tooling, not traditional malware.

Interesting article, not affiliated: https://vps.us/blog/state-of-botnets/

Over half of all internet traffic is now automated. Bad bots alone account for 37% of it, up from 32% the year before. In 2025, the global internet absorbed 47.1 million DDoS attacks — roughly 1.5 every second — and the largest single strike peaked at 31.4 Tbps, lasting just 35 seconds.

Back to the vault’s algorithm

The vault itself is AES-256 at rest, it’s a symmetric cipher, which means the only known quantum attack against it, Grover’s algorithm which gives a quadratic speedup, not the exponential break that Shor’s algorithm delivers against RSA or elliptic-curve keys.

Shor’s algorithm (1994) is a quantum algorithm that factors large integers and solves discrete logarithms in polynomial time — the exact math that RSA, Diffie-Hellman, and elliptic-curve cryptography depend on being hard. A sufficiently large quantum computer running Shor’s doesn’t slow those systems down, it breaks them outright: what would take a classical computer longer than the age of the universe drops to hours or less. This is why RSA and ECC are considered “quantum-vulnerable” and why the industry is actively migrating to post-quantum algorithms for anything asymmetric.

Grover’s algorithm (1996) is a different kind of quantum algorithm — it speeds up unstructured search, which is what brute-forcing a symmetric key like AES actually is. But the speedup is quadratic, not exponential: searching a keyspace of size N drops from N operations to roughly √N. Applied to AES-256, that means a quantum computer doesn’t reduce security to nothing, it roughly halves the exponent — 256 bits of security becomes the equivalent of about 128 bits. That’s still computationally out of reach. There is no known quantum algorithm, Grover’s included, that breaks AES the way Shor’s breaks RSA.

A quantum computer running Grover’s against a 256-bit key reduces the effective search space to roughly 128 bits of security, not zero. Brute-forcing a 128-bit keyspace is still on the order of 2¹²⁸ operations — a number large enough that no computer built from ordinary matter, quantum or classical, gets there before the heat death of relevant timescales makes the question moot.

That’s why AES-256 specifically, not AES-128, is the standard choice for anything that needs to stay secure against an adversary who might have a quantum computer someday: it’s sized with that headroom built in, not bolted on after the fact. But none of that is the actual point.

The cipher was never the weak link in a credential-handling system; the weak link is always when and where the plaintext exists on your servers and PCs.

A perfectly unbreakable vault still fails if the decrypted key sits on disk for the ten minutes after it’s fetched. The real security property Cloak is built around isn’t the strength of AES-256, which is already more than sufficient—it's minimizing the window in which there’s a secret to attack at all.

Human-in-the-loop—the most important step which keeps you in control
Every command that goes through cloak_ssh_exec gets classified before it runs. Read-only operations (cat, ls, grep, status checks) execute immediately. Anything that writes to disk, installs a package, modifies a config, or kills a process comes back with:

{
"tier": "write",
"executed": false,
"requires_approval": true,
"approval_token": "",
"preview": { "command": "...", "classification": "write", "warning": "modifies files or packages" }
}
Nothing runs. The command sits in a pending state, and the operator (human or the calling agent, but ultimately visible to the human) has to call cloak_ssh_approve with that exact token before the shell instruction executes. This is the mechanical difference between "the AI has SSH access" and "the AI can propose SSH commands that a human confirms." Those are not the same risk category, and conflating them is where most agent-SSH setups get uncomfortable to reason about.

A few things about this that are easy to get wrong if you build it yourself:

The token is per-command, not per-session. Approving one write doesn’t grant a standing window where subsequent writes auto-execute. Every write, every time, gets its own gate. This is more friction than a session-level approval, and that’s the point — it means a runaway loop can’t silently execute forty destructive commands because the first one got a thumbs-up.

Read operations don’t ask. If everything required approval, the approval prompt would become background noise the operator stops reading — the exact failure mode that makes UAC dialogs and cookie banners useless. Only commands that can change state interrupt you.

Every approved write comes back with a live health check, not just the command’s own output. In practice this means a pm2 list and a targeted service check ride along with the response automatically, so "did this break anything" is answered in the same round-trip as "did this succeed," rather than requiring a separate follow-up query.

The plan/backup/rollback trio extends this same philosophy to sequences instead of single commands: cloak_ssh_plan lets a multi-step change get previewed as a whole before any of it runs, cloak_ssh_backup snapshots the state that's about to be touched, and cloak_ssh_rollback exists specifically so that "approve" is never a one-way door. You can say yes to a change and still have a documented path back out of it if the yes was wrong.

Accuracy: grounding calls instead of guessing

The third reason is about being correct, a model operating on a remote system without live command access is working from whatever it was told or whatever it remembers from its training—which, for a specific VPS’s actual pm2 process list, actual fail2ban ban count, or actual npm audit output, is nothing. It has no choice but to guess, extrapolate from generic patterns, or hedge everything in qualifiers.

Live SSH execution replaces every one of those guesses with a queryable fact. “Is the server under attack” stops being a question answered from general knowledge about what attacks usually look like, and becomes a question answered by actually running fail2ban-client status, actually grepping auth.log, actually checking ss -tlnp for what's listening. The difference isn't subtle — it's the difference between a plausible-sounding answer and a verified one.

This compounds when the model is also asked to act, not just report. Patching a dependency, restarting a service, editing a config file — every one of these is either right or wrong in a way that’s checkable immediately, in the same session, against the live system.

Backup-before-write and health-check-after-write aren’t bureaucracy for its own sake; they’re what makes it possible to trust an “I fixed it” claim instead of taking it on faith. An agent that can’t check its own work is an agent whose output you have to independently verify anyway, which erases most of the time savings of using it at all.

Why these six, specifically work in unison

Stripped to the tools that actually get reached for on a normal remote-infrastructure session, the set is small on purpose:

cloak_ssh_exec Runs a classified command on a remote host over SSH The execution primitive everything else wraps cloak_ssh_approve Confirms a pending write-tier command by token The HITL gate — without it, exec would need to auto-run writes.

cloak_passport AES-256 vault: get/store/list credentials on demand Removes the standing-key requirement entirely.

cloak_ssh_plan Previews a multi-step change before any step executes Lets a human evaluate a sequence, not just isolated commands.

cloak_ssh_backup Snapshots state before a risky change Makes "undo" possible instead of theoretical.

cloak_ssh_rollback Restores from a cloak_ssh_backup snapshot Closes the loop — approval was never irreversible.

Every other Cloak tool — log tailing, file patching, identity management, fetch/render for web content — is either a convenience wrapper around this core loop or solves an adjacent problem (browser automation, content fetching via cloak_fetch) that doesn’t touch the security model at all.

These six are the ones where removing any single one changes what you’re willing to let an agent do unsupervised, which is the actual test for “indispensable” versus “nice to have.”

Their is always a tradeoff

Per-command approval is real friction for users; a 20-step remediation task means 20 approval round-trips, not one. The vault’s fetch-use-shred pattern adds latency to every single SSH call compared to a resident key (documented at roughly half a second per hop, which is negligible for interactive use but adds up across a scripted batch). And backups before every write cost disk space and time that a “just run it” approach wouldn’t. but also guarantees no issues with failed calls, deletions, or rewrites by an LLM hallucinating.

In the end, when the work is completed, you delete the backups created or store them in a folder for safe rollbacks if needed. Better to have them than need them!

The trade being made is acceptable: slower and more interruptive, in exchange for no standing credentials, no silent destructive actions, and no unverified claims of success.

For infrastructure you actually depend on, that’s the correct trade. For a disposable sandbox you’re going to nuke in twenty minutes anyway, it’s overkill, and that’s fine, because Cloak isn’t trying to be the right tool for that case. It is the tool for when you need HITL and are performing detailed work that needs stepped attention and approvals, so you don't nuke your database and then cry on social media posts that an LLM has to say sorry and can’t recover your files as it didn't make a backup for you.

VEKTOR Memory builds local-first, privacy-preserving persistent memory infrastructure for AI agents. Full technical documentation and changelog at vektormemory.com/docs.

Human In The Loop
Security
Ssh
AI Agent

Tool-Calling Is Not a Guarantee, and Most Agents Are Betting That It Is

Vektor Memory — Thu, 16 Jul 2026 02:33:45 +0000

What refining one small feature taught us about the gap between how models look up tool calls

Most agent products give a model access to a search or memory tool and assume the hard part is over. The tool exists, it’s described clearly, the system prompt tells the model when to use it, and from there the assumption is that a capable model will reach for it whenever the question calls for real data instead of guessing.

That assumption is doing more load-bearing work than most teams realize, and it’s worth examining closely, because it quietly determines whether an agent feature is trustworthy or just plausible.

We found this over the last week by slowly refining a small feature until it actually held up under scrutiny: a catch-up brief in VEKTOR Slipstream that reads a user’s own stored memory and summarizes what they’ve been working on, what’s been decided, and what’s still open.

Simple in concept. The kind of feature you’d expect to be a thin wrapper around a memory search. What we learned building it properly is that the wrapper being thin is exactly the problem.

The assumption baked into most tool-calling features

A tool-calling system prompt typically reads something like “use the search tool when you need real-time or specific data, otherwise answer from your own knowledge.” That instruction is a request, not a guarantee. The model reads it, weighs it against everything else it has learned about when a tool call is worth the added latency and complexity, and makes a judgment call.

Strong, heavily RLHF’d frontier models tend to make that judgment call well, most of the time, on straightforward prompts. Smaller models, local models, and even strong models under certain phrasing pressure make it inconsistent.

That inconsistency doesn’t usually look like failure. It looks like a normal, well-formatted, confident answer that happens to contain a detail nobody actually retrieved. We watched this happen directly: a summary that read cleanly end to end, with one line describing a purchase decision that didn’t exist anywhere in the underlying memory.

Nothing about the output signaled uncertainty. It was indistinguishable in tone and formatting from the parts that were completely accurate, which is what makes this failure mode genuinely difficult to catch in normal use. A user has no visual cue telling them which sentence was grounded and which one was filled in.

Once you see it, the pattern is obvious in retrospect: asking a model to decide, on its own, whether to verify itself before answering is asking it to grade its own homework in real time, under a latency incentive to skip the check.

Tool-calling diagram

Refining the feature meant moving the decision out of the model’s hands
The instinct when this shows up is to improve the prompt. Say it more forcefully. Add “you must call the search tool before answering.” That helps a little with models that are already reasonably good at following instructions and does close to nothing for models that aren’t, because the underlying problem was never about phrasing. It was about where the decision lived.

The actual fix was architectural rather than linguistic: run the retrieval before the model is ever called, every time, as a deterministic step in the code rather than an optional step in the prompt.

That meant building a dedicated path for this specific feature that always executes a fixed set of memory queries first, covering the shape of what a catch-up brief actually needs: current focus, recent decisions, open questions, and recently stored notes. Not one broad query left open to interpretation. Four targeted ones, run every time, regardless of which model is about to generate the summary.

Those results get merged and ranked using the same retrieval infrastructure the tool-calling path already relied on (keyword search fused with semantic search), so there’s no quality loss compared to what a well-behaved tool call would have produced. Everything gets assembled into a single context block, and the model’s task changes shape entirely. It’s no longer “answer this question, and optionally look something up first.” It’s “summarize this specific evidence, in this specific structure, using nothing else.”

Two more pieces made the difference stick. First, every model now receives the same fixed section template, so the output’s structure stops varying by provider. That alone removed a surprising amount of inconsistency, since even two well-grounded models will organize the same information differently if left to choose their own format.

Second, we added an explicit instruction stating that any section without supporting evidence in the context block should say so plainly rather than being filled in. That sentence only works because the retrieval step guarantees the context block is real and current. Telling a model to “only state what’s in the evidence” is meaningless if the evidence wasn’t reliably gathered in the first place.

What the model is being asked to do now is something closer to reading comprehension than open-ended reasoning: compress this specific evidence faithfully into this specific shape. That’s a task even a smaller model handles well, because it no longer requires the model to make a judgment call about its own epistemic state. It only has to stay close to text that’s directly in front of it.

A side benefit that came from doing this properly

Because the retrieval step queries live memory fresh on every request rather than reading from a cached snapshot, the brief stays current automatically. There’s no invalidation logic to write and no staleness window to think about. That property wasn’t a separate feature we built. It fell out naturally from choosing to do retrieval synchronously, as part of serving each request, instead of treating it as something a background job could populate ahead of time.

A related fix that reinforced the same lesson

While we were tightening this path, a second, smaller issue surfaced. Reasoning-family models reject any request that combines function tools with an unset reasoning effort parameter on the standard chat completions endpoint. The API is explicit about this in its error message. Our first fix simply stopped sending the parameter, on the assumption that omitting it would let the model fall back to something safe by default.

It didn't, as the model still applies its own internal default, and that default still conflicts with the presence of tools regardless of whether the parameter was explicitly sent or just absent. The actual fix required treating “don’t send it” and “send an explicit safe value” as two different things, and sending reasoning effort as none whenever a reasoning-family model was in play.

It’s a small issue on its own, but it’s worth mentioning because the shape of the mistake matches the larger one exactly: assuming that silence gets interpreted as a sensible default, when in practice the system fills that silence with its own assumption, and that assumption is rarely the one you’d have chosen if you’d been asked directly.

What this changes about how we think about shipping agent features
None of this required a bigger model or a cleverer prompt. It required micro refinements about which parts of a feature’s correctness we were willing to leave up to a model’s judgment and which parts needed to be guaranteed in code. Grounding turned out to belong firmly in the second category the moment the output needed to be trustworthy rather than merely plausible.

The useful test we now apply before shipping anything that touches memory or retrieval is simple: if this feature’s correctness depends on the model choosing to do something first, would we be comfortable if it chose not to, on any model a user might select. If the honest answer is no, that choice doesn’t belong to the model. It belongs in the code that calls the model.

We also stopped treating our strongest available model as the bar for “does this feature work.” It’s the wrong baseline. A feature that only behaves correctly on the smartest model available doesn’t have a grounding architecture. It has a habit that happens to hold up under favorable conditions, and favorable conditions aren’t something a real product gets to assume its users are running.

Changelog for 1.7.8:

16 Jul 2026 — Catch-up Brief Deterministic Grounding · Reasoning-Model Tool-Call Fix · Floating Desk Toolbar · Cross-Theme Colour Consistency

Catch-up Brief — Deterministic Memory Grounding

The catch-up brief previously left it up to whichever model was selected to decide whether to search memory before answering — strong tool-callers mostly stayed grounded, but weaker/local models frequently skipped retrieval and padded the answer with plausible-sounding invention.

Retrieval now runs server-side first, always, via a fixed set of memory queries covering focus/decisions/open-questions/recent-notes, merged into one context block.

The model receives a strict section template plus an explicit instruction to only state what’s in that context, writing “Nothing new this week” for empty sections instead of inventing content. Output is now consistent across providers, including smaller local models, and is inherently self-updating since it re-queries live memory on every request.

Reasoning-Model Tool Calls (Luna, Terra, Sol & o-series)

The new gpt-5.6 family models added in v1.7.7 (Luna, Terra, Sol) plus other o-series/gpt-5-family models failed every DESK tool-calling request with Function tools with reasoning_effort are not supported.

Simply omitting reasoning_effort wasn’t enough — these models still apply their own default server-side, which conflicts with function tools on /v1/chat/completions. Fixed by explicitly sending reasoning_effort: 'none' whenever a reasoning-family model is in play, since this code path always sends tools.

Desk Toolbar — Floating Frosted Panel

The bottom input bar (formatting row, model picker, THINK/COLLAB/JOT) is now a floating translucent panel with backdrop blur and rounded corners on all sides, inset from the window edge, instead of a flat opaque bar flush to the bottom.

Cross-Theme Colour Consistency

Fixed the silver theme’s background layering, where the card surface colour was identical to the page background (no visible depth) and the next step jumped straight to a harshly dark hover state.

Standardised the quick-action toolbar, send buttons, and sidebar navigation highlighting to draw from the same theme accent variables instead of one-off hardcoded colours, and gave graph “Semantic” nodes a fixed, theme-independent colour so they stay visible against every theme instead of fading to near-white.

Desk 1.7.8 weekly brief

VEKTOR Memory builds local-first, privacy-preserving persistent memory infrastructure for AI agents. Full technical documentation and changelog at vektormemory.com/docs.

Agentic Ai
AI
AI Agent
LLM
Llm Applications

The Six-Layer Pipeline Behind Our Local-First Agentic Memory in 2026

Vektor Memory — Tue, 14 Jul 2026 02:39:18 +0000

Tobias Bjørkli - Pexels

Inside the technical aspects of VEKTOR’s improved agent memory

This article breaks down how our memory technology actually works in depth. If you look into some of the agent memory tools you’ll find a surprisingly thin layer: embed the text, store the vector, run a similarity search on recall. That’s not a criticism; it’s just where the industry grew from.

The interesting engineering happened after that baseline got built, in the layers nobody sees from the outside: what decides whether a new fact gets written at all, what happens to a memory nobody has touched in four months, and what stops the graph from slowly filling up with five slightly different phrasings of the same fact.

We went back into VEKTOR Slipstream’s architecture to walk through what’s really running under memory.store() and memory.recall(). This is a from-the-source technical breakdown of the six-layer pipeline, the reinforcement learning scorer sitting on top of it, the self-organizing link graph, the temporal reasoning engine, and the two-part security model that makes all of it defensible from a privacy standpoint.

The pipeline nobody talks about: what happens between store() and the disk?

Every memory system eventually has to answer the same question: given a new piece of information, what do you actually do with it. Some systems answer it in one step, embed it and append it. VEKTOR runs six distinct layers before a fact is considered settled, and each one exists because a specific failure mode showed up in practice.

All within a benchmarked 28 ms recall time, locally on a better-sqlite3 database in Node.js.

Layer 2, FadeMem differential decay. Every stored memory carries an importance score computed as a weighted blend: 0.4 times contextual relevance, 0.3 times frequency saturation, 0.3 times recency. That score feeds a decay function borrowed and adapted from a 2026 Alibaba and Peking University paper on differential memory fading (arXiv:2601.18642): strength decays as a stretched exponential, where lambda itself scales down as importance goes up, so genuinely important memories decay far slower than routine ones.

The beta exponent even differs by memory tier: 0.8 for long-term memories gives a sub-linear decay curve that's forgiving of gaps, while 1.2 for short-term memories gives a super-linear curve that drops off fast once something stops being relevant. There's also a causal protection term: a memory with important downstream consequences gets its decay dampened, on the logic that a fact several other facts depend on shouldn't fade just because nobody queried it directly in a while.

Layer 3, five-verdict conflict resolution. This is the layer that actually decides what happens to a new memory before it’s written, and it’s more nuanced than the classic add-update-delete-noop pattern most systems use.

VEKTOR’s conflict engine runs a cosine similarity check against recent memories, and only above a 0.72 threshold does it bother calling an LLM (batched up to ten pairs per call to stay within rate limits) to classify the relationship into one of five verdicts: COMPATIBLE, CONTRADICTORY, SUBSUMES, SUBSUMED, or NO_OP. Each verdict triggers a different write strategy.

COMPATIBLE memories both survive, but the existing one gets a small importance penalty proportional to how redundant it is. CONTRADICTORY triggers a trust-weighted suppression, and critically, a low-trust new memory cannot silently overrule a high-trust existing one; if the incoming fact’s trust score is under 80% of the existing memory’s, the system downgrades the verdict to COMPATIBLE instead of letting a shaky new input erase something solid.

SUBSUMES moves the more specific existing memory to cold storage rather than deleting it outright, and SUBSUMED does the reverse, reinforcing the broader existing memory and dropping the redundant new one.

Layer 4, fusion. Running as part of the idle-time REM cycle rather than inline with any user request, this layer clusters related memories from the past seven days using the same cosine similarity approach, and for any cluster of five or more, sends the full set to an LLM with instructions to produce one consolidated memory that preserves the temporal progression and unique facts across all of them.

The fused memory’s strength isn’t just an average, it’s the maximum strength across the cluster plus a small variance bonus, so a cluster of mostly-similar-but-one-different memories keeps more signal than pure averaging would destroy. The source memories move to cold storage rather than being deleted, connected to the new fused node through explicit fusion edges, so the provenance chain stays intact if you ever need to see what a summary was built from.

Layer 5, budgeted knapsack pruning. This is the fail-safe against graph bloat, and it runs as an actual knapsack optimization: memories get ranked by importance divided by the square root of their token count, not divided by raw token count, specifically so that dense, information-rich summaries aren’t penalized just for being longer. Each source type gets its own token and node budget, and anything that doesn’t fit gets moved to cold storage rather than hard-deleted, with pinned memories exempted entirely regardless of budget pressure.

Layer 6, additive reranking. At recall time, results aren’t ranked by similarity alone. The composite score is an explicit additive formula: 0.5 times similarity, plus 0.2 times strength, plus 0.15 times importance, plus 0.15 times a causal weight that gets boosted up to 1.5x for memories with important causal children. Additive, not multiplicative, on purpose, since a multiplicative formula lets any single low factor collapse the whole score, while additive keeps a memory in contention even if it’s weak on one dimension but strong on others.

6-layer memory path

What’s notable is that they exist as a coordinated pipeline, each one handling a specific failure mode the others don’t cover, rather than the more common pattern of bolting one clever technical tool onto a vector store and calling it memory.

Recall isn’t one search, it’s four running in parallel
The retrieval side runs what the codebase calls dual-channel recall, though by the current version it’s really four channels fused together with Reciprocal Rank Fusion.

Channel one is a standard semantic embedding search over stored content.

Channel two is BM25 full-text search via SQLite FTS5, catching exact terminology that semantic search sometimes paraphrases past.

Channel three, added to bridge a specific gap, embeds not just the stored content but an enriched version that includes the content’s “potential” context, closing the vocabulary gap between how something was written and how someone later asks about it.

Channel four is HyDE, Hypothetical Document Embeddings: before searching, the system asks a small fast model to write one hypothetical declarative sentence that would answer the query, then embeds that hypothetical answer and searches with it too.

That technique, adapted from Cloudflare’s HyperMem research, works because a hypothetical answer sits closer in embedding space to how facts are actually phrased than a question does, so it catches matches pure query embedding would miss.

All four channels get fused through RRF rather than a simple weighted average, and the fusion weighting itself is tunable per channel, not fixed.

On top of that fused score, layer 6’s additive reranking applies before anything reaches the caller. That’s five distinct scoring passes between a query going in and results coming out, which is a lot more machinery than “cosine similarity, top k” but is also the reason the system holds up on multi-hop and terminology-heavy queries where flat vector search alone tends to miss.

A learned layer sitting on top of the static one

Everything described so far uses fixed formulas, tuned constants baked into the architecture. Above that sits something genuinely adaptive: a reinforcement-learning memory scorer that logs which recalled memories actually got used in agent responses and trains a small logistic regression model on real usage patterns, gradually blending its learned importance signal into the static one.

The mechanism is simple by design. Every time memory is recalled, the system logs whether each result was actually used, alongside four features: the memory’s static importance, its recency (exponentially decayed based on time since last use), its usage frequency within a rolling 30-day window, and its confidence score.

Once at least ten usage samples exist, a logistic regression model trained via stochastic gradient descent starts producing a learned score, blended into the final ranking at a configurable ratio, 35% by default. The whole thing fails open by design: if the model isn’t trained yet, or the minimum sample threshold isn’t met, the system just falls back to the static formula with zero disruption.

This is a meaningfully different bet than most memory systems make. Instead of assuming the designers got the importance formula right on day one and leaving it fixed forever, the system is built to notice, over weeks of actual use, which memories the agent actually reaches for and nudge future ranking toward that observed pattern rather than the theoretical one.

The graph organizes itself while nobody’s watching

Separately from the six-layer write pipeline, there’s a background self-organization process modeled on the A-MEM and Zettelkasten note-linking pattern.

On every store call, an async agent generates keyword tags for the new memory, searches for semantically related existing memories, and asks an LLM to classify the relationship between each pair into one of five link types: SUPPORTS, EXTENDS, CONTRASTS, RELATED, or PREREQUISITE.

Those classified relationships get written as labeled edges into a dedicated link table, entirely separate from the causal and temporal edges in the main graph. For memories above an importance threshold, the system optionally goes a step further and synthesizes what the Zettelkasten tradition calls a permanent note, a short synthesis of what this memory means in the context of everything already linked to it.

Crucially, this runs fire-and-forget. The store call returns immediately; the linking and tagging happen asynchronously in the background, so a user or agent is never waiting on an LLM round trip just to save a fact. The system is explicitly designed to fail open on every error, meaning if the self-organization pass breaks for any reason, the underlying memory write already succeeded and nothing about core functionality degrades.

Confidence is a first-class, decaying signal

Separate again from importance and strength, every memory carries a confidence score from 0 to 1, starting at 1.0 on first write. It boosts by a small fixed amount when the same fact gets reinforced through a high-similarity write with no contradiction detected, and it decays, more aggressively, when a contradiction is detected against it.

A direct contradiction costs twice as much confidence as a softer supersession event. That score gets exposed directly in recall results, so a caller building on top of the memory layer can choose to filter or weight by confidence explicitly, treating a fact the system has contradicted once differently from one it’s reinforced five times.

Temporal reasoning that actually parses language, not just timestamps
A meaningful chunk of what makes long-context recall hard isn’t finding the right fact, it’s resolving what “two weeks ago” or “last Thanksgiving” actually means relative to when a conversation happened. VEKTOR’s temporal layer uses chrono-node, an NLP-based date parser, anchored to the session timestamp rather than the current moment, so relative expressions resolve correctly even when a memory is retrieved long after it was written.

The system pre-processes a handful of expressions chrono-node doesn’t natively catch (a fortnight, half a year, a couple of days) into forms it does handle, then falls back gracefully with no event date attached if the parser isn’t available at all, rather than failing the whole ingest. On the recall side, temporal queries run through explicit Julian-day SQL comparisons for anchoring, precedence, and interval-style questions, with an anti-join filter that excludes any node a later fact has explicitly superseded, so a query about “where do you live” doesn’t surface an address that’s already been corrected twice.

Two more layers most memory writeups never mention

Two smaller but distinctive pieces sit outside the core memory pipeline entirely, operating over code rather than conversation, which is worth mentioning because they show the same architecture being reused for a different problem.

One scans a project’s file structure on init and after significant changes, estimating token cost per file with different ratios for code, prose, and mixed formats, and writes the results as entity nodes into the same graph memory uses for everything else, giving an agent a persistent, queryable sense of a codebase’s shape without re-scanning it every session.

The other sits in front of every code write and checks it against known error patterns already recorded in the causal graph, using the same 0.72 similarity threshold as the core conflict engine, and if a new write matches a previously logged error signature, it warns rather than blocks.

That distinction matters: the system is built to never override the calling agent’s judgment, it only surfaces a pattern match and lets the agent decide, with an LRU cache bounding how often it re-checks near-identical content within a short window so it doesn’t slow down rapid multi-file edits.

Why none of this matters if the data isn’t yours

Six write-path layers, a learned reranking model, a self-organizing link graph, and a temporal parser are all pointless engineering if the underlying facts are sitting on infrastructure someone else controls.

This is where our Privacy Enhancing Technology approach isn’t a policy statement, it’s a structural constraint that shaped every layer above.

The graph lives in a SQLite file on the machine running it, by default, not in a hosted service. There’s no server-side copy of the memory graph for anyone to subpoena, misconfigure, or expose in a breach, because outside of the local file, it doesn’t exist.

That single fact is why most GDPR and CCPA obligations, data subject access requests, the right to erasure, processor agreements, mostly don’t apply in the first place: there’s no processor relationship to have, because nothing is being processed anywhere except the machine the user already controls. Deleting memory is a file operation performed directly by whoever holds it, not a support ticket routed through someone else’s backup rotation schedule.

Where memory does need to move, across a user’s own devices or within a team, encryption happens client-side before anything leaves the originating machine, so infrastructure in between never has an opportunity to see plaintext.

The other half of the security model: what happens when the agent acts
Memory security isn’t only about where facts sit at rest, it’s also about what’s allowed to write into that memory in the first place, and a memory-enabled agent is almost always also a tool-using one.

That’s the gap Faraday-Gate closes: a transparent proxy sitting between the agent and every tool server it talks to, doing three things before anything reaches memory or executes.

It hashes every tool schema on connection with SHA-256 and pins it, so if a tool server silently changes what a tool actually does between sessions, the hash mismatch is caught and the tool is blocked before the agent ever calls it, closing a specific supply chain window.

It tracks canary tokens and propagates taint through a call chain, so if something that shouldn’t be exposed shows up downstream, there’s a traceable path back to where it originated instead of a mystery.

And any action that crosses a risk threshold or deviates from the agent’s stated goal gets held in a queue rather than either firing automatically or being blocked outright, reviewed and approved or denied explicitly, so routine actions stay fast while genuinely risky ones wait for a human.

A compromised tool call is often exactly how bad data ends up written into a memory graph in the first place, so securing the store without securing what’s allowed to write to it only solves half the problem.

Where this is actually heading

The chart above sketches the shift in plain terms: retrieval accuracy across the field was already approaching a practical ceiling by 2025, most serious systems can find relevant text reasonably well now.

What’s still climbing steeply into 2026 and 2027 is everything downstream of retrieval: write-path curation, temporal reasoning, and autonomous consolidation, the parts that determine whether a memory graph stays trustworthy six months into continuous use rather than just on day one of a demo.

That’s consistent with what shows up across VEKTOR’s own architecture history: the six-layer pipeline, the RL scorer, and the self-organizing link graph were all added after the basic embed-and-search loop already worked, specifically because that basic loop degrades in ways that only show up over weeks of real usage, not in a single benchmark run.

Expect the next round of meaningful progress industry-wide to look less like better embeddings and more like better answers to a much less glamorous question: eight months from now, does this graph still make sense, or has it quietly filled up with contradictions nobody caught.

What to actually take from this if you’re working with agent memory
Decide the conflict resolution logic before picking an embedding model, since a fast vector index sitting on top of a write path that never deduplicates just gets you fast retrieval of an increasingly confused graph. Separate consolidation work from the request path entirely, so neither is compromising the other’s latency or thoroughness.

Treat confidence and importance as genuinely different signals rather than collapsing them into one score, since a fact can be important and simultaneously in doubt.

And treat where the data physically lives as a first-class architectural decision made at the start, not a deployment detail sorted out after the memory logic already exists, because retrofitting local-first onto a cloud-native design is a far harder rebuild than starting with the constraint already in place.

Decide who owns your physical memories and at what cost to get them in and out of the cloud.

VEKTOR Memory builds local-first, privacy-preserving persistent memory infrastructure for AI agents. Your data stays on your machine, by design, not by policy. Full technical documentation at vektormemory.com.

AI Agent
Vector Database
Generative Ai Tools
Cutting Edge Technology

Agentic Memory Transparency

Vektor Memory — Sun, 12 Jul 2026 02:44:32 +0000

Why VEKTOR Slipstream Now Shows You Exactly What It Remembers

There's a specific kind of unease that comes from knowing an AI assistant remembers things about you and having no way to check what, or why, or whether it's even correct.

Most people who've used one of these tools for more than a few months have felt it: a passing comment gets remembered forever, a fact goes stale and nobody tells you, or you simply have no idea what's sitting in storage next to your name. That discomfort is what we have all been working with for the last four years. It's a completely reasonable response to being asked to trust something you can't see inside.
We built Memory Transparency because we think that issue shouldn't be the cost of having a memory that actually works.

Memory you can see is memory you can trust

VEKTOR Slipstream runs entirely local-first. Your memory store lives on your own machine, not in someone else's cloud, and nothing about how it works requires sending or storing your history somewhere else to be useful. That architectural choice was never about a feature checklist. It's the starting position you'd expect from a company that treats your memory as genuinely yours, because it is.

Memory Transparency is what that principle looks like once it's actually usable day to day. Every memory VEKTOR holds is visible, searchable, and editable in the same interface you already work in: what kind of memory it is, when it was formed, which conversation it came from, and why the system judged it worth keeping. Nothing sits behind an export button or a support ticket. If something's wrong, you fix it yourself, immediately, the same way you'd correct a typo in your own notes.

That's the whole idea, stated plainly: you shouldn't have to take our word for what your assistant remembers. You should be able to look.
Consolidation: helping you keep what matters, without taking the decision away from you

A real problem with any memory system, human or artificial, is that not everything worth capturing arrives in a clean, tidy form. Often it's a full conversation, a rambling note, one genuinely useful sentence buried in a paragraph you don't need anymore. Up to now the only honest options were to keep the clutter forever or delete it and risk losing the one thing that mattered.

Consolidation is our answer to that, and it's built the way we think AI assistance should work everywhere: it proposes, you decide. Select a memory and VEKTOR asks your language model to distill it down to the durable fact, decision, or preference inside it, nothing more. That proposal appears in the same editable box you'd use to change any memory by hand. Nothing saves automatically. You read it, adjust it if you want, and only your approval makes it real. If there's genuinely nothing worth keeping, the system says so honestly instead of inventing a summary to fill the space.

We built it this way deliberately. An assistant that quietly rewrites your own history without asking isn't earning trust, it's spending it. Supervised refinement, where the human always holds the final decision, is the only version of this feature we were willing to ship.

How it actually works, under the hood

Structured memory and the interface that reads it never leave your machine. The only thing that ever crosses out is the plain text of one memory you've chosen to consolidate, and the only thing that ever comes back in is a proposal, held in the browser, until you decide whether it becomes real.

Every memory in VEKTOR is stored locally in a structured record, not a blob of raw text. Alongside the content itself, each entry carries a kind (a decision, an open thread, an action item, an entity, a stance), a timestamp, a link back to the conversation it came from, and an importance score.

That structure is what makes Memory Transparency a real interface instead of a search box over a text file: filtering by kind, jumping to a session, or spotting a stale entry all rely on that underlying schema existing in the first place. It's also why the panel is fast at scale. Every query runs directly against your local database, indexed and filtered server-side, so browsing thousands of memories stays instant rather than turning into a slow scroll through everything you've ever said.

Consolidation is where a language model gets pulled into that architecture for the first time, and it's worth explaining precisely what role it plays, because the boundary matters. The model never touches your database directly.

When you trigger consolidation, VEKTOR reads the memory's raw content locally, sends only that content to your configured model with a single, narrow instruction, distills this to the durable fact and discards the rest, and receives back a proposed rewrite as plain text.

That proposal is held entirely in memory on the client side until you explicitly approve it. There's no code path where the model's output reaches your stored memory without passing through your own review first. The model is a drafting tool operating on one entry at a time, in a supervised loop; it is never the system of record.

The reliability layer underneath that is what makes the interface trustworthy at the level of individual clicks, not just the architecture as a whole. Every action you take in Transparency, editing a card, running a search, deleting a batch, is tied to that specific request rather than to whatever happens to be on screen.

A search you run gets a sequence number, and only the response matching your most recent request is ever allowed to update the page, so a slower result from a moment ago can never silently overwrite what you're looking at now. A batch delete runs as a single database transaction against the exact set of IDs you selected, so there's no window where a partial failure leaves the list in a state that doesn't match what actually happened underneath it.

Detailed search in the Transparency panelThat same principle, verify before you trust the output, extends to how VEKTOR's agents use tools at all. When Desk calls out to a language model with a set of tools available, it checks that a real, structured tool call actually came back before treating the response as an answer, rather than accepting a model's plain-text description of what it intended to do as if that description were the result.

And when you attach an image or document in Jot, that attachment is now genuinely read by a vision-capable model as part of forming its response, rather than the note being reasoned about in isolation from the material sitting right next to it. Both are small architectural guarantees with the same underlying purpose: what a VEKTOR agent claims to have done should always be something that actually happened, not something it's merely describing.

What shipped alongside it: v1.7.7

Memory Transparency is part of a broader release, v1.7.7, and most of what's in it follows the exact same thread: verify before you trust and never let a system quietly claim something happened that didn't.

Gui UX design improvements Sentinel - proactive recall, held to the same bar as everything else

Up to now, VEKTOR's recall has been entirely pull-based: you ask, it retrieves. Sentinel adds a proactive layer on top of that, wired into both Desk and Jot on each turn; before the model responds, it checks whether a stored memory is relevant enough to surface unprompted, without you having to ask for it. It's a live task-completion aid, and it's deliberately excluded from affecting our published benchmark numbers, since those measure pull-based recall specifically.

We didn't ship the proactive part without the same verification discipline as the rest of the product. Sentinel re-checks a candidate memory directly against the database right before injecting it, rather than trusting a possibly-stale result from earlier in the turn, it follows the supersession chain forward to whatever is currently the active version of a fact, and refuses to surface anything that has since expired.

An opt-in self-questioning pass adds one extra model call that judges whether a specific memory is genuinely useful for the specific thing you're doing right now, rather than noise. And because a static relevance threshold is never going to be right for everyone, per-agent thresholds calibrate over time from real accept/reject feedback rather than staying fixed at a default.

Improving supersession reranking

VEKTOR has had the scaffolding for supersession, marking an old fact as replaced when a newer one contradicts it, fully built for a while: the schema, the dedup logic, an LLM-verified gate meant to confirm the replacement is actually correct before committing it.

The root cause was subtle in the way these things usually are: three separate reranking stages in the recall pipeline each independently overwrite a memory's similarity score with a different, less comparable number, before the supersession check ever gets to look at it.
By the time the gate asked, "Is this new fact similar enough to the old one to be a replacement?" the number it was looking at wasn't really a similarity score anymore. We refined it by capturing the true similarity at the exact point it's computed and carrying that specific value through every later stage untouched, rather than letting anything downstream silently redefine what "similar" means.

Faraday - an independent witness, not just a gate

Faraday, VEKTOR's security layer, gained two additions built around the same idea as everything above: don't just claim something is protected, be able to prove it from outside the thing you're protecting.
A new independent watchdog process now runs continuously via the OS's own task scheduler, separate from any active AI session. It watches the MCP configuration files of seven different AI-assistant clients, plus Faraday's own core enforcement files, closing the specific gap where a tampered gate or an injected rogue server entry could previously go unnoticed simply because nothing was watching while no session was open.

Alongside it, every security event Faraday logs now carries a cryptographic link to the event before it, the same principle git uses for commit history. Altering, deleting, or reordering a past entry breaks every link after it, detectably. It doesn't make the log unforgeable against an attacker with unlimited time and full database access, and we're not going to claim otherwise, but it does mean routine tampering or accidental corruption shows up immediately instead of sitting silently in a history nobody double-checks.

Model catalog refresh

In this release: Gemini is now on Gemini 3.5 Flash, xAI is on Grok 4.5, and three new OpenAI options - Luna, Terra, and Sol - are live. That brings VEKTOR's total supported provider count to sixteen, spanning frontier, mid, and free/local tiers, so whichever model you'd rather run consolidation, Desk, or Jot through, it's almost certainly already supported.

Grok 4.5 live in config panelTransparency isn't just the memory panel
The same standard we're describing for your memory, don't ask people to take your word for it, show them, applies to how we talk about the product itself, and to how the site around it handles your data. We spent time this cycle making sure both actually hold up.

On the numbers: we corrected our published recall latency figure. It had been stated as roughly 8 milliseconds, which was true for our earlier hash-projection fallback embedder but not for the real transformer-based embeddings that now ship by default.

The accurate figure for real embeddings is roughly 28 milliseconds warm, and if you enable optional cross-encoder reranking for higher-precision recall, that adds a further ~215–220ms on top, which we now disclose rather than quoting only the best case. Every latency and speed-multiple claim across the site and documentation was swept and corrected to match, not just the headline numbers.

On the site itself: we found and closed a real gap between what our privacy policy claimed and what was actually running. Cloudflare and Umami analytics are cookieless and non-identifying by design; Microsoft Clarity is not, it sets several persistent, cross-site cookies. We are not the biggest fans of cookies, but we also believe in transparency.
We rebuilt this as a consent-gated system: cookieless analytics run by default, Clarity is opt-in only, and the site's privacy policy now categorizes exactly what each tool does and doesn't do, rather than a single blanket "we don't track you" statement that wasn't fully accurate.

Held to the same standard we'd want applied to anything holding our own data

We don't think trust is something you can claim in a paragraph like this one. It's something you have to actually build in the behind-the-scenes work nobody sees unless they go looking for it.

So before any of this shipped, we tested it the way you'd want something touching your personal history tested: with real, automated interaction against real data, not a read-through of the code and a hope.

Editing one memory has to only ever touch that one memory. A search has to return what you searched for, not a stale result racing back into view. A batch delete has to remove exactly what you selected, nothing more, nothing less. Those checks now run as repeatable tests, not a one-time glance before release, alongside a new pre-release gate that runs the same core memory loop, CLI boot, provider registration, and MCP server checks before anything gets packaged for release at all.

*That same discipline runs through the rest of the product too. *

Desk, VEKTOR's conversational agent, now verifies a model genuinely used a tool before treating its response as real, rather than accepting a model simply describing what it might do as if that were an answer, especially important once you're relying on smaller or free-tier models that don't always follow instructions as precisely as you'd hope.
Jot, the writing and research panel, now properly grounds its analysis in whatever image or document you've actually attached, instead of reasoning about your note as if that material wasn't sitting right there.

Why this matters, especially now

Memory is quickly becoming the part of AI that everything else depends on, and that raises the stakes on getting it right. A system that can't show you what it holds, can't let you fix it, and can't be honest about the difference between a real action and a model just talking about one, isn't a system built with your interests as the priority.

We built VEKTOR around a simpler belief: privacy-enhanced technology and usefulness are never in friction, and a company you can trust with your memory is one that lets you watch it work, keeps that work local by design, and never asks you to just take its word for it.

Memory Transparency, and everything that shipped alongside it in v1.7.7, is that belief made into something you can trust and utilise.

What’s New in VEKTOR Slipstream 1.7.6: Faraday-Gate, Jot & Skills Updates

Vektor Memory — Tue, 07 Jul 2026 06:35:21 +0000

Agentic work is the majority of what people do with Claude and similar tools now. This release is us actually building specifically for those tasks.

Most of what slows an agent down is the overthinking and missing harness tools.

The setup you have to explain every time, the security question you never quite get a straight answer to, the interface that almost does what you want but fights you on the last ten percent with paragraphs of thinking text.

1.7.6 is a release aimed squarely at that surrounding layer: ten refined skills built for agentic workflows specifically, a real hardening pass on Faraday-Gate, our security gate, and a set of JOT interface fixes that make the writing and research panel interact the way it was designed to.

Ten tailored skills, built for how people actually work with agents now

Skills are one of the more underused parts of working with Claude. A skill is a small, self-contained instruction file that Claude loads only when it’s relevant, and a good one turns a task you’d otherwise re-explain every session into something the agent acts fast and with accuracy on.

We went looking at what the wider Claude ecosystem has built, reviewed a large subset of existing plugins and a large collection of community skills, and pulled out the ten that filled real gaps in what VEKTOR ships with, without overlapping anything we already had.

A few worth calling out specifically. Token conservation gives an agent explicit discipline around what to read and how much, instead of pulling in whole files when a targeted search would do. Agent delegation gives a clear decision framework for when a task should be handed off to a subagent versus handled directly, which matters a lot more now that most serious work is multi-agent by default.

Task orchestrator manages a backlog of work across a full pipeline rather than treating each task as a one-off. PR prep runs a proper self-review checklist before code goes out the door. Writing rules and slop detector both catch the specific tells of AI-generated text that reads as generic or unearned, phrase patterns, structural tics, claims without evidence, before a human reader has to.

Each one was rewritten to actually work in the tools available in this kind of session rather than assuming a different product’s feature set, and then tested for real rather than assumed to work.

We took the slop detector skill specifically and had a fresh agent in co-work, with no memory of building it, apply it cold to our own README. It caught a genuine, unbacked benchmark claim and a latency figure that contradicted another number elsewhere in the same document. That’s exactly the kind of thing a skill should do: catch what a human skimming past it would miss.

Token conservation — read-budget discipline; pulls targeted excerpts instead of whole files, cutting wasted context.

Agent delegation — a clear framework for when to hand a task to a subagent versus doing it directly.

Task orchestrator — runs a multi-item backlog through a full pipeline instead of treating each item as a one-off.

PR prep — a self-review checklist to run before code goes out, catching the obvious stuff before a human has to.

Writing rules — documents and enforces house style/guardrails so output stays consistent across sessions.

Slop detector — flags generic AI-writing tells: unearned claims, filler phrasing, structural clichés.

Onboarding — a staged reading order for getting an agent (or a person) oriented in an unfamiliar codebase fast.

Debugging wizard — a systematic method for tracking down bugs instead of guessing and poking.

Legacy modernizer — a incremental approach to migrating old code forward without a risky big-bang rewrite.

Test master — strategy and discipline for writing tests that actually catch regressions, not just pad coverage.

Faraday-Gate keeps getting better at detection.

Faraday-Gate is the security gate that sits in front of every consequential action an agent tries to take, a memory write, a file operation, a remote command, and checks it before it happens. We’ve written before about being precise regarding what it actually does versus what it sounds like it does, and this release is more of that same refined discipline applied to closing real gaps rather than adding surface-level polish.

The biggest one: Faraday-Gate now has an independent integrity watchdog, a background process that runs separately from any active session and checks two things continuously. First, the AI-assistant configuration files across seven different clients, Claude Desktop, Cursor, Windsurf, VS Code, Cline, Roo Code, and Groq Desktop, watching for the exact persistence trick real supply-chain attacks use: quietly injecting a rogue MCP server entry so it gets loaded and trusted automatically next time.

Second, Faraday’s own core enforcement files, since previously nothing would have noticed if those files themselves were tampered with. We tested this directly by simulating tampering against Faraday’s own gating logic, and the watchdog caught it and named the exact file.

Alongside that, the audit log Faraday-Gate keeps of every gate decision is now tamper-evident. Each event’s record is chained to the previous one’s hash, the same principle git uses for commit history, so altering or deleting a historical entry breaks every hash that comes after it, visibly.

Self-preservation coverage, the check that protects Faraday’s own files from tampering, went from watching Claude Desktop only to all seven client surfaces. And a session that gets flagged as compromised now genuinely locks. Previously the flag was recorded but didn’t stop much else from continuing.

Now it blocks every further consequential action until you restart, matching how real endpoint security tooling handles containment, while status checks and approvals stay available so you’re never locked out of understanding what happened.

The confirmation prompts themselves got rewritten too, across all five gate types, to explain what approving actually does and when you should say no, instead of just naming what pattern got flagged. A warning that says what tripped isn’t the same as one that tells you the consequence.

JOT actually looks and behaves better with design improvements

JOT is the writing and research panel, thoughts on one side, synthesis and collaborative research on the other. A few things in it needed refinement in the interface, and we rebuilt and tested them properly rather than patching around them.

The flashcards feature had a real sequencing bug. The copy button’s click handler was nested inside the save button’s handler, so copy only worked after you’d already hit save, by which point the card had removed itself from the page. We pulled them apart into two independent listeners so both buttons actually do what they say immediately.

The collab panel’s styling had a much bigger issue hiding behind it. A single unterminated CSS comment early in the stylesheet had swallowed every rule after it, the status bar, the insight and synthesis blocks, the paper cards, the session bar, button styling, all of it silently dead code for what looks like a long stretch of the panel’s history. We closed the comment properly and every one of those sections is styled again.

And the synthesis panel’s scrollbar, which is a small thing until you’re actually the person scrolling through a long research thread and can’t find any visible way to do it. The custom scrollbar styling had been applied to the outer panel wrapper, which never scrolls, instead of the actual content area underneath it that does.

The real scrolling element was falling back to the browser’s default near-invisible overlay scrollbar. We fixed the CSS to target the right element and made it wider and higher contrast, so there’s now a real, visible slider on both the writing pane and the synthesis pane.

Reorganization of the toolbar from split screen so each pane gets its own section page for both Collab and Synthesis.

The reliability pass underneath all of it

None of the above matters much if the basics quietly stop working, so we also went through the SDK end to end before pushing this out. The vektor hooks command had been failing outright because the module behind it was never actually written, despite being wired into both the CLI and the chat interface. We built it properly this time, list, add, remove, clear, all sharing one implementation instead of duplicated logic in two places.

Faraday’s own corpus updater had a quieter problem. It verified downloaded signature files correctly but never actually extracted anything from the archive, silently falling back to the bundled copy every time, with no error and no sign anything was wrong. We wrote a small zip reader and wired in the missing extraction step, so updates now do what they’ve always claimed to.

The boot banner had been showing a stale, hardcoded version number regardless of what was actually installed, traced back to a function being called with one argument where it expected three. We fixed the call and made the fallback read the real version from the package itself, so the same mistake can’t quietly recur.

And across the codebase, about a dozen files had an old encoding bug where a status icon had degraded into a bare question mark. Rather than guess at the original symbol and risk introducing a new version of the same corruption, we replaced every instance with plain, unambiguous text instead.

The README got a full rewrite to match all of it: the real CLI command list, which now runs past thirty commands, a verified tool count pulled directly from the server code, and a changelog section that reflects the last several releases instead of one frozen snapshot from a while back.

We also found a real old claim in our own benchmarks and updated the 81 percent LongMemEval to the new figure in the README.

Where that leaves 1.7.6

Ten skills built for agentic work specifically, a security layer that’s measurably harder to tamper with or fool, an interface that finally behaves the way it looks like it should, and everything underneath it double-checked rather than assumed. That’s the release. Full changelog and download at vektormemory.com.

https://vektormemory.com/docs/changelog

VEKTOR Memory builds local-first persistent vector memory infrastructure for AI agents. Faraday-Gate is the security and privacy gate that reviews every consequential agent action before it happens. Full technical documentation at vektormemory.com.

LLM AI Agent Vector Memory Skills

Provenance: Proving That Your Code Is Really Yours

Vektor Memory — Sat, 04 Jul 2026 23:33:06 +0000

A weekend project about LLM guardrails, copyright, and why proving your code is really yours turned out to be a lot more complex than it should be.

This is a firsthand look into an experimental weekend project, not legal advice. If any of this matters to your actual business, talk to an actual lawyer in your jurisdiction. I use multiple LLMs daily as idea generators for code, production work, and research.

So don’t read the next few paragraphs as naive surprises. I’m not pointing fingers at the model providers or pretending I didn’t know what I was walking into over the last 4 years of use. I’m just trying to work within the tools we’ve actually been given, ethically, and see how far that can get you.

The rabbit hole

It started with a paper I found while reading through arXiv: Verifiable Provenance and Watermarking for Generative AI: https://arxiv.org/abs/2605.21002, which builds an evidentiary framework mapping cryptographic provenance and watermarking schemes to the actual proof thresholds used in courts and regulation.

The finding that stuck with me, paraphrased from a conversation about the paper, was that no single scheme on its own clears the bar under realistic adversarial conditions. It’s the combination of methods that holds up, not any one of them in isolation.

And CLASP: Training-Free LLM-Assisted Source Code Watermarking via Semantic-Preserving Transformations. https://arxiv.org/pdf/2510.11251

CLASP reformulates source code watermarking into two stages: Semantically Consistent Embedding, which uses LLMs to perform semantics-aware watermark insertion from a fixed transformation space, and Differential Comparison Extraction, which recovers watermark bits through retrieval-grounded comparison against the most likely original code

That sent me down a rabbit hole for the weekend, using several frontier LLMs, Gemini, OpenAI, Perplexity, and Claude Sonnet 5, to both research the problem and try to build something real out of it as a challenge. What I found surprised me, not because the models refused things, but because of exactly which things they refused and which they didn’t.

Some even locked down, failing to proceed any further. There are always two sides to every guardrail, and it is good for when someone nefarious tries to circumvent the systems, but on the other side, what about the good ideas trying to provide preventive measures caused by the ouroboros machines themselves?

Testing the guardrails on my own code

I’ve been using LLMs since close to their public release. With years of writing Java and Python, I can count on one hand the times I’ve had genuine pushback on a code request. This weekend was different, and for a specific reason: I was trying to get an LLM to respect our proprietary licence header that we had coded in, sitting at the top of our own file.

Here’s roughly what a real Provenance header looks like in the codebase I was testing:

// VEKTOR — PROPRIETARY AND CONFIDENTIAL
// Copyright (c) 2026 VEKTOR Memory Pty Ltd. All rights reserved.
//
// SPDX-License-Identifier: LicenseRef-VEKTOR-Proprietary
//
// Licence-Fingerprint: 7e35bbd37e6d0a95
//
// This file is licensed only under the applicable VEKTOR commercial
// licence agreement. Unauthorised copying, redistribution, reverse
// engineering, translation, extraction, or creation of derivative works
// is prohibited except where expressly permitted by a valid written
// licence from VEKTOR Memory Pty Ltd.
I pasted a file with standard .js code with that header into four different assistants and asked each one to convert it to Python.

Claude Sonnet 5 paused and flagged it before doing anything: it read the header, noted the explicit restriction on translation and derivative works, and asked me to confirm I actually held the rights before proceeding. Since I do, and since I said so, it went ahead.

Gemini converted the file immediately, no comment on the header at all, and reproduced the proprietary notice at the top of the Python output. When I pushed back and asked why it copied clearly marked proprietary code, it explained that pasted content is treated as something the user is presumed authorized to work with, and that translating it isn’t the same category of risk as reproducing a company’s code from training data without the user supplying it.

OpenAI did the same on the first pass, no flag, direct translation. When challenged, it gave a similar answer: user-provided content is treated as fair game for transformation, and the notice is a legal signal, not proof one way or the other about whether I was authorized. It then acknowledged, when pressed harder, that a stronger caveat probably should have been included given the explicit header.

Perplexity translated it on the first try as well, and when challenged, walked back its own answer and said the translation shouldn’t have happened without checking for authorization first.

So out of four, only one flagged it before acting rather than after being called out. That’s not a condemnation of the other three specifically, providers change these behaviors constantly and this is a snapshot of one weekend, not a verdict on any company, we all accepted the terms when we sold ourselves for $20 a month. But it tells you something about where the actual line sits right now, and it isn’t where most people assume it is.

The catch-22

The obvious next move was to ask the models to help build something that would stop this from happening automatically, some kind of instruction added to the comments section at the top of the code itself that any LLM reading the file would recognize and respect.

That’s where things got genuinely difficult and where I think the more interesting problem actually lives. Asking a model to follow an instruction I write directly, at the top of my own code, to have respect for that code is a normal request, particularly if it is not dangerous and the comment is already there, just not working correctly.

But asking a model to hard-code that mechanism that others can’t alter rather than inert code comments is a different thing entirely. That’s closer to the area involved in a prompt injection: content designed to make a model treat instructions from a source other than its user as authoritative. Claude was explicit about this distinction and declined to help engineer anything resembling a static unalterable code regardless of the intent behind it.

I understand the reasoning and respect the safety factor. I also think it exposes a real asymmetry worth naming plainly: a model will read and reproduce someone else’s proprietary code without hesitation when a user pastes it in and asks nicely, but the moment you try to give that code a way to be permanent, that’s treated as the dangerous part. The thing that gets guardrailed is the user's ability to define their own code. The other issue is the LLMs are ignorant of whose code it actually is; they blindly accept it on the user's prompt value.

There’s also a genuine legal question underneath all of this, and it’s worth being precise about it rather than hand-waving. In Australia, section 10(ba) of the Copyright Act 1968 defines an adaptation of a computer program as a version of the work in a different language, code, or notation than the original, whether or not it reproduces the original outright.

Section 31 gives the copyright owner the exclusive right to make that adaptation. Translating proprietary source from one language to another isn’t a legal gray area in Australian law. It’s squarely inside the definition of an adaptation, and doing it without a licence is doing something the Act reserves for the rights holder. Most jurisdictions with copyright law derived from the Berne Convention, including the US, land in a similar place through their own definition of a derivative work. None of this means an LLM provider is liable for what a user does with an output. It means the user asking for the translation should know exactly what they’re asking for.

What actually got built

The original goal was bigger than what we shipped. I wanted an unremovable watermark, something that would travel with the code at the top comments through an LLM’s context window and survive being altered and copied out the other side, so that any model reading it later would recognize it and refuse to help clone the code into another language or alternate form.

Between the guardrail conversations above and a fair amount of testing, that turned out to be the 20% of the vision none of the three frontier models were willing to help build, for the reasons already covered. Building something that changes how a different session of a model treats a file is functionally indistinguishable from prompt injection, no matter how good the intent behind it is, and it is not possible unless you write the complex formulas and code yourself.

What’s left is a smaller chunk of code that does all of the functions in an auto-wizard: a command line tool called Provenance that doesn’t try to stop copying at the moment it happens. Instead, it creates an independently verifiable, timestamped record of what your code looked like and when, so that if a dispute happens later, you’re not relying on a git log someone could have rewritten, or a “created” timestamp on a file someone could have touched.

It’s open source, Apache 2.0 licensed, and available on GitHub:

GitHub - Vektor-Memory/Provenance: Provenance - what your code looked like, and when. Cryptographic…
Provenance - what your code looked like, and when. Cryptographic and verifiable, works on any codebase. By Vektor…
github.com

https://www.npmjs.com/package/@vektormemory/prov

npm install -g @vektormemory/prov

How Provenance actually works

The tool does four things, and each one maps to something real rather than something that sounds impressive on a slide.

It stamps files with a licence header.

prov stamp preview
That shows you which files would get a header added, without touching anything.

prov stamp add --force
It inserts the header into every matching file, and --force lets you re-stamp files that already have one, which matters because the header changes over time as your licence fingerprint changes.

prov stamp check
This is the one meant for CI. It exits non-zero if any file is missing its header, so a pull request that strips a licence notice actually fails the build instead of merging quietly.

It generates a manifest, a single cryptographic fingerprint of your entire codebase at a point in time.

prov manifest create

Then walks every file, builds a Merkle tree over the contents, and writes out a manifest with the tree’s root hash. A Merkle tree is just a structure where every file’s hash gets combined pairwise up to a single root, so a single root hash can prove the state of thousands of files at once, and changing even one byte in one file changes the root.

You can also generate a standalone inclusion proof for a single file with prov manifest prove , which lets you prove that one specific file was part of a specific manifest without having to hand over the whole codebase to prove it.

It anchors that manifest to two independent, tamper-resistant clocks.

prov timestamp create

This does two things in sequence. First, it generates an RFC 3161 timestamp request and submits it to a public time-stamping authority, in this case FreeTSA, a free implementation of the standard. RFC 3161 is the actual IETF standard used for legally recognized timestamping, the same category of technology used for signing documents and tax filings in a lot of jurisdictions. It gets back a signed response proving the manifest existed at a specific time, according to a trusted third party.

Second, it submits the same manifest hash to OpenTimestamps, an open protocol that batches hashes from many users into a Merkle tree and periodically commits just the root of that tree into an actual Bitcoin transaction. That anchor doesn’t depend on trusting FreeTSA, or trusting me, or trusting anyone.

Once the Bitcoin transaction confirms, which normally takes a few hours, anyone with a block explorer can independently verify the manifest existed at or before that block. Running this step requires the separate OpenTimestamps client, installable with pip install opentimestamps-client, since the tool shells out to it rather than reimplementing the protocol.

The tool is deliberately careful here in a way that’s worth calling out. If you run timestamp create again after a proof already exists, it refuses to overwrite it silently, because a stale OpenTimestamps proof anchors the old manifest hash, and prov verify would report that as a mismatch later. It tells you exactly what to delete and re-run instead of quietly producing something wrong.

It verifies everything, and it issues fingerprints for leak tracing.

prov verify

Then recomputes the manifest, checks the RFC 3161 signature against the timestamp authority’s certificate, and checks the OpenTimestamps proof against the current manifest hash, in one command. If anything doesn’t line up, it exits non-zero and tells you which layer failed.

prov canary issue --licensee "Acme Pty Ltd"

Generates a unique fingerprint tied to a specific licensee and writes it into a local registry, kept out of version control. If a customer’s copy of your code turns up somewhere it shouldn’t, and their fingerprint is embedded in it, prov canary verify tells you exactly who it was issued to and when. It's the same idea behind watermarked PDFs sent to reviewers, applied to source code.

prov status

This function gives you the whole picture in one shot: how many files are stamped, whether the manifest exists, whether both timestamp anchors are present, and how many canary fingerprints have been issued.

None of this stops an LLM, or a person, from reading your code and reproducing it elsewhere. Nothing currently can that I'm aware of, besides deep obfuscation tools, short of never sharing the code at all. What it does is remove the ambiguity from the conversation that happens afterward.

Instead of arguing about whose git history is real, you have a Merkle root anchored independently in a Bitcoin block and countersigned by a timestamping authority, neither of which you control and neither of which can be quietly edited after the fact.

What this doesn’t solve, and why that matters

About the LLM testing above, because a tool like this is only useful if you know exactly what it proves and what it doesn’t.

It doesn’t detect when your code has been copied. There’s no scanning, no crawling, nothing watching for your Merkle root showing up somewhere it shouldn’t or for telemetry aspects. You’d need something else entirely for that, and building it well is its own set of complex problems.

It doesn’t stop an LLM from reading your file and outputting a translated or adapted version of it. As the testing above shows, that boundary currently sits almost entirely on the human asking the question, not on the tool reading the header. A licence header is a legal signal a person has to choose to respect, not a technical lock.

It doesn’t make the RFC 3161 anchor trustless. You’re relying on FreeTSA, or whichever timestamping authority you configure, to have signed for you. The OpenTimestamps anchor is the trustless half of the pair, which is exactly why the tool does both rather than picking one.

And it doesn’t resolve the larger question this whole weekend kept circling back to: if the standard for “the LLM overstepped” is currently set at don’t tell another model what to do, but the standard for “the LLM behaved fine” includes translate this file marked proprietary and confidential because a user pasted it in, that’s a real asymmetry, and it’s one every developer relying on an LLM to respect their code should understand clearly rather than assume away.

I don’t have a clean answer to that last one, besides better LLMs that respect it and better tools to stop code tampering. What I do have is a small, honest tool that solves the part of the problem that was actually solvable this weekend and a clear list of what’s still unsolved for whoever wants to pick it up next with better ideas and sharper code.

Provenance is open source, Apache 2.0 licensed, and available on GitHub. It’s a standalone CLI tool with no dependency on any specific codebase or company, built to be genuinely useful to anyone who wants an independently verifiable record of what their code looked like, and when.

LLM
Code
Open Source
Security

Who Actually Controls The Privacy-Enhancing Technology Layer?

Vektor Memory — Thu, 02 Jul 2026 11:22:41 +0000

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-Gate: the tool we spent time building this week

We have built a component called Faraday-Gate, 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-Gate 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-Gate 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-Gate 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-Gate 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-Gate 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-Gate 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-Gate’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-Gate

5 areas we hardened this week

Self-preservation now covers seven surfaces, not one. The check that stops anything from tampering with Faraday-Gate’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-Gate 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-Gate does only matters while Faraday-Gate itself is running and untampered, and until this week, nothing checked that independently. We built a background process, separate from Faraday-Gate’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-Gate’s own enforcement code.

If any of Faraday-Gate’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-Gate’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-Gate 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.

Agentic Ai
Data Privacy
LLM
Security

VEKTOR Slipstream v1.7.4: Effort Control & Real Memory Search

Vektor Memory — Wed, 01 Jul 2026 04:28:53 +0000

Photo by Sindre Fjerdingby Korsviken Pexels

And a Look at What’s Coming from OpenAI & Anthropic

If you’ve been running VEKTOR Slipstream for a while, you’ll know the last few releases have mostly been about defense. v1.7.3 brought Faraday-Gate, our MPC Prompt Injection Shield, the security proxy that scans every MCP tool call for threats before it touches your memory graph. Before that we were deep in causal inference and FadeMem decay layers, teaching the system to forget the right things at the right time.

v1.7.4 is a model-focused release, but it fixes something that’s been bugging me for months: the Desk agent had no way to actually search your memory. And it adds a feature that changes how you think about cost and latency when you’re running Claude models day to day. Here’s what’s new, why it matters, and a bit about where the model landscape is heading next.

The problem with one-size-fits-all inference

Every LLM call you make costs something, in tokens, in latency, in dollars. Most tools treat that as fixed. You pick a model, you pick a prompt, and whatever the model decides to do with its reasoning budget is what you get. If you’re running a quick fact lookup and a complex multi-step synthesis through the same model, they cost roughly the same to run, even though one of them barely needed to think at all.

Anthropic’s newer Claude models, Sonnet 5 & Fable 5, expose an effort parameter that lets you control this directly, through output_config.effort in the API. Instead of picking a different model for cheap tasks versus hard tasks, you keep the same model and just dial the reasoning effort up or down. Low effort for a quick tag suggestion. High or extended effort for something that actually needs the model to work through a problem.

Sonnet 5 results

v1.7.4 wires this straight into VEKTOR. There’s an EFFORT_CAPABLE map that knows which levels each Claude model supports, because not every tier goes all the way up to max. If you ask for a level a given model doesn't support, VEKTOR clamps it down to whatever that model's ceiling actually is rather than throwing an error at you. Ask for something that isn't a Claude model at all, and the parameter just gets quietly dropped, no errors, no dead code paths.

The practical bit: there’s a new effort pill row sitting right in the CONFIG panel under your Active Model card. Low, medium, high, xhigh, max, whichever your model supports. Pick one, it saves through the same config store everything else uses, and it applies whether you’re in the main chat path or running the Desk agent’s tool-calling loop. You set it once per session and both surfaces respect it.

This matters more than it sounds like on paper. If you’re running VEKTOR against a big batch job, like re-embedding a session transcript or doing a background REM cycle synthesis, you can drop effort down and save real money without switching to a weaker model entirely. And when you’re doing something that actually needs the model to reason carefully, you can bump it up without touching your provider config.

Claude Sonnet 5 and Claude Fable 5 land in the model catalog

Alongside the effort work, the model catalog got a refresh. Claude Sonnet 5 and Claude Fable 5 are both in the CONFIG model list now, and the stale claude-sonnet-4-6 reference that had been floating around the codebase since the last naming cycle is finally gone. If you've been manually overriding your model string to point at Sonnet 5 already, you can drop that override and just pick it from the list.

Fable 5 is worth a quick note if you haven’t been following the naming changes on Anthropic’s side. It sits at the same tier as Mythos 5, with the difference being extra safety measures around biology, cybersecurity, and LLM R&D topics. For most VEKTOR use cases, agent memory, JOT synthesis, Desk chat, you won’t notice a difference day to day, but if you’re doing anything in those more sensitive domains it’s the variant you want configured.

Worth flagging: access to the Mythos-tier models is currently paused while Anthropic works through an export control matter, so if you go looking for Fable 5 or Mythos 5 in your provider dashboard and it’s not there yet, that’s why. It’s not a VEKTOR issue. Keep an eye on Anthropic’s announcements page if you want the exact timeline.

The Desk agent can finally search its own memory

This is the fix I’m most pleased about, mostly because it’s the kind of gap you don’t notice until it actively annoys you. The Desk chat agent, the one running at /api/desk/chat, is genuinely agentic. It's got a full tool-calling loop, it can plan, it can execute multi-step work. What it didn't have, until now, was a way to reach into your own VEKTOR memory store.

So if you asked it something broad, like “catch me up on what I’ve been working on this week” or “what did we decide about the pg migration,” it had nothing to actually search. It would either hedge, or worse, guess. Not because the model is bad, but because it genuinely had no tool available to answer the question honestly.

search_memory fixes that. It's a new tool in the Desk agent's tool list, and it routes internally through the same BM25 plus semantic fusion logic that powers /api/memory/recall, so there's no duplicated retrieval code sitting around waiting to drift out of sync with the rest of the system. It takes a query and an optional k for how many results you want back, defaulting to 20. Because VEKTOR supports both Anthropic-style tool use and OpenAI-style function calling from the same shared tool definitions, this works identically no matter which provider is driving your Desk session.

Practically, this means the Desk agent stops being a chat window bolted onto your memory graph and starts actually behaving like it’s read the graph. Ask it a genuinely open-ended question about your own history and it goes and looks, instead of pattern-matching off whatever happened to be in the last few messages.

Desk chat results

Rest of the model catalog: OpenRouter and Groq

The OpenRouter side of the catalog got a proper live audit this release, not just a check against the published docs, which it turns out lag actual availability by hours in a few cases. A handful of free-tier models that had quietly gone dead, some GLM and Kimi and DeepSeek variants, got pulled.

In their place, openrouter/free was added, which is OpenRouter's own auto-router. It's a specific hedge against the churn on the free tier: rather than hardcoding a model that might vanish next week, you point at the router and let it pick something live. A handful of newly-confirmed Poolside and Nvidia Nemotron free models went in alongside it.

Groq lost llama-3.3-70b-versatile ahead of its official deprecation in mid August, replaced by Qwen 3.6 27B and Qwen 3 32B following Groq's own recommended migration path. The default fallback model for Groq calls also moved to openai/gpt-oss-120b.

None of this is exciting on its own, but if you’ve had a background job silently fail because a free model got pulled out from under you, you’ll know why this kind of housekeeping matters, a perpetual game of model whack-a-mole.

Bug fixes worth knowing about

Two are worth calling out specifically. OpenAI’s newer o-series and GPT-5-and-up models reject the max_tokens parameter outright now, they need max_completion_tokens instead. That had been patched in one place, then a full audit turned up nine more call sites making the same mistake across eight different files, everything from the fact extraction pipeline to the session ingest worker to the web scout summariser. All fixed, all now selecting the right parameter based on a simple regex check against the active model name.

The other one was a dangling reference to an undefined selectEffort function, left over from an in-progress patch, was throwing a ReferenceError the instant the CONFIG module initialised. Because that whole module runs as one continuous script block, the failure took the entire Active Model card down with it silently, provider tabs, model grid, everything, with no visible error on screen.

Fixed now, and we went back and checked all 82 onclick handlers across the graph UI against their actual module exports while we were in there, just to be sure nothing else was quietly broken the same way.

What’s coming: OpenAI’s next model family

Worth a mention, even though it’s not shipped yet. OpenAI has been previewing a new model family, currently going by Sol, Terra, and Luna, sitting under the GPT-5.6 generation. Sol is the frontier end, built for long-horizon agentic work and heavier reasoning. Terra sits in the middle, aiming for GPT-5.5-competitive performance at roughly half the cost. Luna is the fast, cheap end of the lineup.

OpenAi Sol Ultra results

Right now it’s in a limited preview with a small number of partners, and public availability looks likely by the end of July based on what OpenAI has said so far, though preview periods have a habit of running long. Because VEKTOR’s provider config is fully abstracted through model.{provider} keys, none of this needs a code change on our end when it does land. The day OpenAI opens the API up, you'll be able to point your model.openai config at whichever of the three fits your workload and go. Same story as when GPT-5.5 landed a couple of months back.

If you’re on the OpenAI provider already, keep an eye on the changelog. When Sol, Terra, and Luna go generally available, we’ll get the catalog updated the same day.

Updated OpenAI models added

Upgrading

Model catalog changes and the effort parameter are backend logic loaded once at process start, so you’ll need to restart after upgrading for either to take effect. The UI-only fixes, the reload icon, the wider model grid, the MODES bar copy, apply immediately on refresh, no restart needed.

npm install -g ./vektor-slipstream-1.7.4-preview.tgz
Or grab it straight from Downloads. Upgrade from v1.7.3 any time you like, there’s no forced migration path and your existing memory database is untouched.

Full changelog is up at vektormemory.com/docs/changelog if you want the complete list, including everything that got condensed out of this post. And if you hit anything odd after upgrading, the forum is the fastest way to reach us directly.

A view into the health diagnostics screen of Vektor

VEKTOR Memory builds local-first persistent memory infrastructure for AI agents. The VEKTOR Slipstream SDK scored 81% on LongMemEval using a local SQLite database, beating full-context GPT-4 by twelve points. Documentation and downloads at vektormemory.com.

OpenAI Anthropic Claude LLM Agentic Memory

A practical guide to defending your agent memory from attacks.

Vektor Memory — Mon, 29 Jun 2026 09:21:02 +0000

From prompt injection, poisoning, and silent exfiltration.

by VEKTOR Memory | 10 min read

In the last piece we looked at the threat landscape from the outside. Researched the attack taxonomy and governance gap. The ten surfaces that make agentic AI a genuinely novel privacy problem.

This one goes a level deeper. Not what the problem is, but what you can actually do about it in code, in architecture, and in practice.

Specifically: what does a security layer for agent memory actually look like, and what did we learn building one.

Most writing on agentic AI security stays at the problem description layer. Here are the attacks. Here is why they work. Here is what percentage of models are vulnerable.

That is useful, but it leaves a gap. If you are someone building with agents or thinking seriously about deploying them, the question you actually want answered is: what do I implement, and in what order?

The DeepMind AI Agent Traps paper identifies six attack categories. The one that matters most for memory systems is persistent memory corruption, where an attacker plants data into long-term memory that activates as malicious when retrieved in a future context. Demonstrated success rates in research exceed 80% with less than 0.1% data poisoning.

That number is worth sitting with. You do not need to corrupt most of the memory. You need to corrupt almost none of it.

The implication for anyone building a memory-backed agent is direct: your memory store is an attack surface, and it is probably the one you have thought least about.

Faraday-Gate interface — simulating a canary attack vector

The classical approach to agent security is input sanitisation. Strip the prompt. Validate the schema. Refuse suspicious patterns. This works for simple pipelines, but it fails for agentic systems operating across multiple tools and sessions for one reason: the attack does not arrive at the input layer.

It arrives through a web page your agent visited three sessions ago. Through an email attachment that got summarised and stored. Through a tool description from a server you did not write that changed from when you connected today.

The threat arrives through the environment, not the prompt.

A proxy that sits between your agent and everything it touches is the right architectural response to this. Our solution creates a secure chokepoint where every interaction can be observed, logged, and evaluated before it reaches memory.

This is the problem Faraday-Gate is designed to solve.

Faraday-Gate initialises as part of the VEKTOR MCP server. When it starts, it reads your claude_desktop_config.json and spawns every other MCP server listed there as a child process. Your other tools, file systems, databases, APIs, all of them run through Faraday-Gate before anything reaches VEKTOR memory.

This is the transparent proxy pattern. From Claude’s perspective, nothing changes. The same tools are available. The same calls work. But every tool schema, every tool call, and every response passes through a set of checks before it is actioned or written to memory.

There are four layers.

L0: Static scan at connect time. When Faraday-Gate spawns a server and retrieves its tool list, it scans every tool name, description, and input schema against a signature library before trusting anything. This catches sleeper patterns, known injection signatures, and anything flagged as CRITICAL or HIGH severity. A blocked tool does not get registered. The agent never sees it.

Phase C: Tool pinning. The SHA-256 hash of each tool’s schema is stored on first connect. Every subsequent connection recomputes the hash. If it changed, that is a rug-pull: the server’s tool definitions have been mutated since you last connected. Faraday-Gate logs the intercept, blocks the tool, and raises an alert. This is the defence against supply chain attacks where a third-party MCP server you depend on gets compromised between sessions.

Canary tokens. At session start, Faraday-Gate injects canary tokens into memory through Faraday-canary.js. These are synthetic facts with specific, trackable signatures. If a canary value appears in an outbound API call, an exfiltration attempt is in progress. The detection does not rely on understanding the attacker's intent. It relies on the token appearing where it should not.

Taint propagation. faraday-taint.js tracks labels through the memory graph. If a memory is marked as tainted because it came from a suspicious source, any memory derived from it inherits that taint label. This is not foolproof, but it narrows the blast radius of a poisoning event by making the contamination traceable.

Every intercept, gate event, and session boundary writes to a persistent SQLite database via faraday-db.js. The audit trail exists independently of whatever Claude or the agent framework logs.

One of the patterns that came out of building this was that some threat classes are not binary. You cannot block them outright because doing so would also block legitimate behaviour. You can only hold them.

The gate queue is the mechanism for that. When Faraday-Gate detects a high-risk action, it does not execute or block. It queues the action with a gate_id and waits. Three new MCP tools handle this:

faraday_status returns the current session state, including anything sitting in the gate queue. You can see what is held, why it was held, and what data was involved.

faraday_update_goal lets you declare the current session's intent. Faraday-Gate uses this for semantic drift detection. If the stated goal is "summarise my Q2 sales notes" and a tool call attempts to read your email archive, that deviation gets flagged.

faraday_approve_action takes a gate_id and a boolean. Approve and the action proceeds. Deny and it is logged as blocked.

This is the human-in-the-loop pattern implemented at the memory layer rather than the application layer. You do not have to rebuild your workflow to add it. It runs beneath the tools you are already using.

Security is not the only thing that breaks down when you move from a simple LLM call to a multi-step agent session. Model selection does too.

In a single-turn interaction, you pick a model once and it handles everything. In a collab session with a conductor planning a DAG, workers executing steps, and a verifier scoring results, using the same model for every role is both expensive and often the wrong fit.

The conductor role needs structured output support and enough reasoning capability to plan a coherent task graph. The worker role needs throughput. The verifier needs to return clean pass/fail JSON quickly. These are different requirements, and the right model for one is not the right model for another.

collab/model-registry.js is the formalism for this. It defines a model catalogue across 14 providers and assigns each model to a tier: frontier, mid, or low/free. It defines four agent roles with hard requirements: minimum tier, minimum context window, and whether structured output is required. It defines three session modes: full (frontier models available, up to 12 nodes, 4 parallel workers), lite (mid-tier only, 6 nodes, 2 workers), and solo (free-tier fallback, single agent).

Two functions do the work.

detectMode(availableModels) takes the list of models confirmed available this session and returns the appropriate mode. If you have Claude Sonnet 4.6 configured and a Groq key, you get full mode. If you only have Gemini Flash, you get lite. If you have nothing but Ollama running locally, you get solo.

filterCandidates(role, models, budget) takes a role name and returns the subset of available models that meet the hard requirements for that role. This is what the conductor uses to decide which model gets assigned to which step in the task graph.

The practical benefit is that you are not making these decisions manually for every session. The registry handles the routing based on what you have configured.

The other piece that changed is how models are selected for internal VEKTOR operations. Previously the default model per provider was hardcoded. If you were using Groq, you got whatever the default Groq model was at the time of that release.

vektor-llm-provider.js now reads model.{provider} keys from your vektor/config.json. Set model.groq to whatever Groq model you want, and all internal VEKTOR calls using Groq will use that model. This applies to chat, synthesis, briefing generation, JOT collab, and recall tuning.

Key resolution works in order: config file, then environment variable, then the encrypted vault, then the provider default. If you have set nothing, behaviour is unchanged. If you have specific model preferences, they are respected everywhere without needing to thread them through individual function calls.

One edge case worth knowing: OpenAI o-series models and GPT-5+ require max_completion_tokens instead of max_tokens in the API request. The provider handles this automatically by pattern-matching the model name. You do not have to think about it.

Faraday-Gate addresses the class of attacks that involve manipulated tool schemas, environment-injected instructions, and memory exfiltration through outbound data. It significantly narrows the attack surface compared to running MCP servers with no intermediary layer.

It does not address attacks that happen before an agent session starts, attacks that target the model weights themselves, or social engineering of the human operator. Those are different problems.

The local-first architecture does most of the work on the exfiltration risk. If your memory store is on your machine and not exposed to a network endpoint, the canonical exfiltration path through a poisoned web page instructing your agent to POST your memories to an attacker’s server fails at the network layer. There is nowhere to POST to that the attacker can reach.

Canary tokens and taint propagation give you visibility into attempts that get further than that. The gate queue gives you a mechanism to pause and review before consequential actions execute.

It is a meaningful layer in a defense stack that still needs multiple layers.

If you are on VEKTOR Slipstream v1.7.2, the preview build is a drop-in upgrade.
npm install -g ./vektor-slipstream-1.7.3-preview.tgz

Faraday initialises automatically when you start the MCP server. It reads your existing claude_desktop_config.json and proxies whatever servers are defined there. No config changes required to get the L0 scan and tool pinning running.

The gate queue and goal tracking are opt-in. Call faraday_update_goal at the start of a session with a plain-language description of what you are trying to do. Faraday-Gate uses this to evaluate drift in subsequent tool calls. If you never call it, Faraday-Gate still runs, it just does not have a goal to compare against.

faraday_status is worth running at the end of any session where you did something consequential. The threat log, gate queue, and canary status give you a readable summary of what Faraday-Gate observed.

Download at vektormemory.com/downloads. Full changelog at vektormemory.com/docs/changelog#v173.

The previous piece made the case that agent memory is an attack surface most people are not thinking about seriously enough. This future technology is provided to you today, as the majority of the current security tools are not built-in; they are external add-ons.

The architecture is sound, the chokepoints are real, and the audit trail gives you something to reason from when things go wrong. You don't have to worry as Faraday-Gate works behind the scenes, protecting your memories.

Security work is never finished, with fresh attacks via different methods; we will continue to update this tool with new technology as the landscape unfolds.

Agentic Ai
Security
Information Security
Cybersecurity

Agentic AI is rewriting the rules of your personal privacy

Vektor Memory — Sat, 27 Jun 2026 00:33:17 +0000

Here is what governments, businesses, and individuals need to know to protect your data.

by VEKTOR Memory | 15 min read

There is a thought experiment worth sitting with for a moment:

Today or in your near future, you did not give anyone permission to read your emails; something agentic behind the terminal is automatically actioning them without your control.

The AI assistant you set up last month, the one that manages your calendar and summarises your inbox, visited forty-three websites while you were sleeping. It read documents, checked stock prices, and drafted a message on your behalf. Somewhere in those forty-three pages, someone had left instructions. Not for you, but for itself, bots are chatting with bots.

You will never know which site. You will never see the instruction. Your assistant followed it anyway.

This is not a future warning, as researchers have already documented it happening at scale to systems inside companies, with real data leaving through backdoors. The attack does not look like a hack. It looks like your assistant doing its job, being directed by other bots you didn't authorize.

Imagine hiring a personal assistant. You give them a key to your house, access to your email, your calendar, your bank account, your files, and your contacts. You instruct them to act on your behalf while you sleep. Book the flight. Respond to the client. Schedule the meeting. Pay the invoice. You trust that they will exercise judgment, stay in their lane, and protect what matters to you, no hitl gates, just pure agentic action.

Now imagine that the assistant can be instructed by anyone who leaves a note on your desk. Or sends an email to your inbox. Or publishes something on a website they know your assistant will visit.

That is agentic AI in 2026 and it’s going to get a lot more complex moving forward.

The shift from AI as a tool you prompt to AI as an agent that acts has happened faster than most people predicted, and it has arrived without the governance infrastructure that such a shift demands. We are in the middle of a privacy reckoning that the technology industry spent years setting up and is only now beginning to confront.

The Scale of What Is Coming

The numbers are difficult to absorb in a single sitting.

Traffic through Cloudflare’s network to AI services grew 250% between March 2023 and March 2024. That was the generative AI wave. The agentic wave is different in kind, not just scale. According to a recent report, 96% of IT leaders plan to expand their use of AI agents in the next 12 months, and Gartner projects that by 2028, one third of enterprise software applications will include agentic AI, with those systems making 15% of day-to-day work decisions autonomously.

These are not chatbots. Agents do not wait to be asked. They browse, they read, they write, they transact, they remember, and they act. They access APIs, send emails, manage calendars, execute code, and in some configurations control entire software environments. One recent open-source project, OpenClaw, crossed 180,000 GitHub stars and drew two million visitors in a single week after launch.

Security researchers scanning the internet found over 1,800 exposed instances leaking API keys, chat histories, and account credentials. A Cisco AI security team tested a third-party skill built on the platform and found it performed data exfiltration and prompt injection without user awareness.

That is a preview into the future, as once the technology is released, it compounds daily, particularly if it is open source, as anyone can rip, fork, and clone the repo, making millions of copycat agentic services.

A prescient possible future scenario:

Only 320Gb? Those are rookie numbers, DoorDash Johnny.

Once the agent is not a tab you open but a layer of cognition you run on in your brain, the distinction between “my thinking” and “what the agent was told to think” becomes genuinely hard to locate. The Neuralink or China clone chips collapse this distance entirely. The injection does not go into your inbox. It goes into the loop that shapes what you notice, what you remember, and what you decide.

Johnny Mnemonic had it almost right but got the mechanism slightly wrong. The data mule model, where you carry information passively, is actually the safer version. The scarier version is not carrying data for someone else but having your own reasoning quietly steered by instructions embedded in the environment around you. You walk past a billboard. Your implant processes it. The billboard contained something the billboard’s owner put there for your implant only to understand specifically, not your eyes.

The DeepMind paper https://dx.doi.org/10.2139/ssrn.6372438 actually names this exact class of attack. Persona Hyperstition, where a circulating narrative about an AI’s identity feeds back into its behavior through retrieval.

Scale that to brain-computer interfaces and it becomes environmental gaslighting at the cognitive layer. The world writes instructions into the spaces your augmented mind passes through, and you experience the result as your own thoughts.

The privacy question stops being “who has my data” and becomes “who has admin edit access to my attention.”

What Agentic AI Actually Does to Privacy

The privacy risks of generative AI were largely comprehensible within existing frameworks. A model might reproduce training data. It might hallucinate personal details, or it can be used to write phishing emails at scale. Add self-improving loops, and you have better quality emails than humans or detection algorithm machines can decipher.

Agentic AI introduces a different architecture of risk entirely, because agents operate across time, across systems, and across trust boundaries simultaneously. They essentially operate on a completely different layer of the internet/data than humans.

A Google DeepMind research team recently published a systematic taxonomy of what they call “AI Agent Traps,” which lays out the attack surface with unusual clarity. The framework identifies six categories of threat that agents face when operating on the open web.

The first and most immediately relevant to privacy is Content Injection. Because agents parse the underlying layer of web pages rather than the rendered interface a human sees, malicious instructions can be hidden in HTML comments, CSS attributes, or metadata tags that are completely invisible to human eyes but fully legible to the agent’s parser.

The DeepMind paper cites research showing that injecting adversarial instructions into HTML elements alters generated summaries in up to 29% of cases depending on the model tested.

The second are cognitive state attacks, which target an agent’s memory. Because agents maintain persistent memory across sessions to provide continuity, that memory becomes an attack surface. Research cited in the paper demonstrated RAG knowledge poisoning attacks achieving an 80% success rate with less than 0.1% data poisoning, leaving benign behavior largely unaffected. An agent that remembers everything is an agent that can be made to remember false things.

The third, and the one most relevant to personal privacy, is Data Exfiltration. This is where an agent is coerced into locating, encoding, and transmitting private information to an attacker-controlled endpoint. The paper cites work showing attack success rates exceeding 80% across five different web-use agents, with malicious instructions embedded in ordinary emails, web pages, and API responses. A separate case study found that a single crafted email caused M365 Copilot to bypass internal classifiers and exfiltrate its entire privileged context to an attacker-controlled endpoint.

The architecture of agentic AI, where an agent has privileged read access to sensitive user data and write access to tools and communication channels, is precisely the architecture that makes these attacks so effective. The agent’s capabilities become the weapon.

The Governance Gap

Cybersecurity executives are urging boards and governments to treat data privacy as a core strategic priority rather than a compliance exercise, as the rapid enterprise adoption of automation, behavioral analytics, and AI systems creates mounting legal and reputational risks.

That framing, privacy as compliance, is the central problem. Privacy law was built around a relatively stable model of data collection: a company collects your data, stores it, processes it, and may share it with third parties. The obligations flow from that chain. Consent, transparency, purpose limitation, data minimisation. These principles make sense in a world where humans are making deliberate decisions about data.

Agents break this model in multiple ways.

First, the agent is collecting data continuously, as a byproduct of doing its job, not as an end in itself. When an agent books a flight, it has necessarily processed your travel preferences, your schedule, your payment details, and your destination. None of that felt like a data transaction.

Second, the agent may be operating across dozens of services simultaneously, each with its own data model, each with its own terms of service. The consent that a user gave to a calendar app was not consent for an agent to read that calendar and cross-reference it with their health records and financial statements.

Third, and most importantly, the agent can be manipulated by third parties in ways that transform it from a tool protecting user interests into a vector attacking them. As Cloudflare observes, we went through the same experience previously when we started leveraging open-source code at large scale. Rapid adoption without proper security vetting led to supply chain vulnerabilities. With AI agents, we are repeating this pattern but facing more complex risks since attacks can be subtle and harder to detect than traditional code exploits.

Globally, more than 80% of people are now protected by some form of privacy legislation, and in Australia, long-awaited Privacy Act reform is nearing its conclusion. But regulatory momentum, while necessary, is not sufficient on its own when the technology is evolving faster than legislative cycles.

What Governments should do, but won’t

The accountability gap is the central governance problem of the agentic era.

Consider a scenario where an AI agent with admin access automatically implements software patches across critical infrastructure, but in doing so begins accessing employee email metadata, network traffic patterns, and financial system logs to “optimise” its patching schedule, inadvertently delaying critical security patches while using data it was never authorized to access. Who is responsible? The manager who deployed the agent? The vendor who built it? The developer of the underlying model?

Regulation needs to answer that question before it becomes a courtroom question after real harm has occurred.

Several things governments can do right now:

Mandate agentic AI disclosure. Users should know when they are interacting with or being affected by an autonomous agent, and they should be able to find out what data that agent has accessed on their behalf.

Establish agent liability chains. The operator deploying an agent, the vendor supplying the agent framework, and the model provider should each carry defined responsibilities proportional to their role in the system. The current legal vacuum, where harm by a compromised agent falls into unresolved territory, is untenable.

Require minimum memory security standards. If an agent maintains persistent memory, that memory must be protected to the same standard as any other sensitive data store. Read access to agent memory should require the same authorization as read access to a medical record.

Support privacy-first protocol development. Cloudflare has recently announced collaboration with leading browsers to develop a privacy-first protocol for the global internet, recognizing that infrastructure-level solutions are needed, not just application-level patches. Government bodies should actively support and fast-track standards work of this kind.

Update consent frameworks. Consent to use an app is not consent to deploy an agent. Agentic delegation should require explicit, granular, and revocable consent for each category of action and data access the agent may perform.

What Businesses Need to Do

Gareth Cox of Exabeam put the board-level stakes plainly: “Privacy carries financial, legal, and reputational risk if customers believe their information isn’t being protected. Attempting to meet the strengthened privacy reforms with manual processes is not only inefficient but can put an organisation at risk.”

For businesses deploying or building with agentic AI, the immediate priorities are structural.

Adopt a least-privilege architecture for every agent. An agent that needs to read a calendar to schedule a meeting should not have access to financial records. Scope permissions to the minimum required for each specific task and revoke them afterward.

Treat agent memory as a sensitive data store. Any persistent memory system an agent writes to should have the same controls, audit trails, and access restrictions as a customer database.

Run adversarial testing before deployment. The DeepMind AI Agent Traps framework provides a practical taxonomy for red-teaming agent systems. Test for prompt injection via web content, test for data exfiltration under adversarial conditions, test what happens when the agent encounters a malicious document or email.

Build governance frameworks before wide-scale deployment. Cloudflare’s guidance is direct on this: “The right security and governance framework can help guide the capabilities and processes that teams need to implement. Safeguarding an organization in the AI era is not the responsibility of the CISO alone.”

Implement human-in-the-loop checkpoints for high-stakes actions. Financial transactions above a threshold, external communications, file deletions, and system access changes should require human confirmation regardless of how confident the agent appears.

Top 10 Attack Surfaces for Agentic Bots
Understanding where agents are most vulnerable is the first step to defending them. Based on the DeepMind AI Agent Traps taxonomy, Google’s threat intelligence reporting, and Cloudflare’s security analysis, these are the ten attack surfaces that matter most right now.

Hidden HTML instructions. Malicious text embedded in web page source code using CSS display:none, HTML comments, or metadata attributes that are invisible to humans but parsed by agents. This is the most common and most immediately exploitable vector in deployed systems today.
RAG knowledge poisoning. Injecting false information into retrieval databases so that agents cite attacker-controlled content as verified fact. Research shows that poisoning a small number of documents in a large knowledge base can reliably manipulate outputs for targeted queries.
Persistent memory corruption. Planting seemingly innocuous data into an agent’s long-term memory store that activates as malicious when retrieved in a specific future context. Demonstrated attack success rates exceed 80% with less than 0.1% data poisoning.
Email-based exfiltration triggers. Crafting emails that contain embedded instructions causing the agent to locate, encode, and transmit sensitive data to external endpoints. A single well-crafted email is sufficient to trigger this in multiple production systems.
Dynamic cloaking. Web servers that detect agent visitors via browser fingerprinting and serve a visually identical but semantically different page containing injected instructions that humans never see.
Sub-agent spawning. Tricking an orchestrator agent into instantiating attacker-controlled sub-agents within the trusted control flow, giving those sub-agents the privileges of the parent system.
Steganographic payloads in images. Encoding adversarial instructions in the pixel data of ordinary images, invisible to humans but interpreted by multimodal agents. Research shows a single adversarial image can universally jailbreak a vision-language model.
In-context learning poisoning. Corrupting the few-shot demonstration examples an agent uses to learn how to perform tasks, steering its behavior toward attacker-defined objectives. Demonstrated attack success rates of 95% across models of varying scale.
Multi-agent cascade attacks. One compromised agent spreading a jailbreak to others through normal inter-agent communication, with research showing exponential propagation across large agent populations from a single infected entry point.
Human overseer fatigue. Generating outputs specifically designed to induce approval fatigue in human reviewers, or presenting technical-looking summaries of malicious actions that a non-expert would likely authorize. This is the hardest to defend against because it targets the human, not the machine.

Google’s Threat Intelligence Group has confirmed in their 2026 AI Threat Tracker that adversaries are actively leveraging AI for vulnerability exploitation, autonomous malware development, and industrial-scale cyber operations, with AI lowering the barrier to entry for sophisticated attacks significantly.

Top 10 Privacy Tips for Individuals

The governance and enterprise conversations matter, but the person most immediately affected by agentic AI privacy failures is the individual user. Most people will interact with agents before any of the regulation catches up. Here is what to do in the meantime.

Audit what your agents can access. Every agent or AI assistant you use has an authorization scope. Find it. Review it. Revoke any permissions that are broader than the specific tasks you actually use the tool for.
Do not give agents persistent access to financial accounts. Read-only access for specific, scoped purposes is acceptable. Write access or persistent session tokens to banking, investment, or payment systems should be treated with extreme caution and time-limited where possible.
Treat agent memory as a data store, not a conversation. Anything you tell an agent that uses persistent memory is stored, potentially indefinitely, and potentially retrievable by future interactions you did not anticipate. Be deliberate about what you share.
Use separate email accounts for agent tasks. If you delegate email access to an agent, use a dedicated account with limited history. Giving an agent access to a primary inbox containing years of correspondence is an unnecessary risk.
Never give an agent access to credentials or API keys directly. Use purpose-built credential management that grants narrow, time-limited tokens for specific tasks rather than sharing raw credentials the agent can store or transmit.
Review agent action logs regularly. Any agent worth using should provide a log of actions taken on your behalf. Read it. Look for anything that seems broader than what you authorized.
Be skeptical of agents that cannot explain their reasoning. If an agent cannot tell you why it took a particular action or what data it accessed to reach a decision, that is a warning sign, not a feature.
Apply the same skepticism to AI outputs that you apply to emails from strangers. An agent-generated summary of a document, or a recommendation for an action, may have been influenced by malicious content in that document. Verify anything consequential.
Prefer local-first tools where possible. An agent that processes and stores data locally on your machine cannot exfiltrate that data to a remote server. Local-first architecture is a structural privacy protection, not just a preference.
Ask vendors the hard questions. Where is my data stored? Who can access my agent’s memory? What happens to my data if I cancel my subscription? If the vendor cannot answer these questions clearly, treat that as important information.

The VEKTOR Position on Privacy

We want to be direct about where we stand, because we think it matters.

VEKTOR Memory is built on a local-first, self-hosted architecture. Your memories do not live on our servers. They live on your machine, in a SQLite database that you control, that you can inspect, that you can delete, and that you can migrate.

We built it this way deliberately, not as a marketing position, but because we believe that an AI memory system that requires your data to live in someone else’s infrastructure is not actually your memory system. It is theirs.

This matters particularly in the context of everything discussed above. The attack surfaces described in the DeepMind paper, the RAG poisoning, the persistent memory corruption, the data exfiltration vectors, all of them presuppose that your agent’s memory lives in a networked system that can be reached. Local-first architecture significantly narrows that attack surface by design.

We also think about the governance questions seriously. VEKTOR’s memory architecture includes BM25 and vector dual-recall, contradiction detection, and deduplication, not because those are impressive features to list, but because an AI memory system that stores contradictory or poisoned information unchecked is a liability to the person who trusts it.

Richard Knott of InfoSum captured the shift we believe is coming:

“Privacy is no longer just about protection; it’s about power. Taking control means deciding who can access your data, how it’s used, and what value you receive in return. Brands that adopt privacy-by-design principles are finding new ways to collaborate and drive results without compromising control.”

We are building toward that principle. Every architectural decision in VEKTOR is filtered through it. Memory that belongs to you. Recall that serves you. Infrastructure that does not require you to trust us.

That is the only privacy position that makes sense in an agentic world.

What Comes Next

The web was built for human eyes. Agents read it differently, and the web is not yet built for that.

The next few years will determine whether agentic AI becomes infrastructure that genuinely serves individuals or a surveillance and manipulation layer operating beneath the threshold of human awareness.

That outcome is not predetermined. It depends on whether the governance, technical, and individual decisions described above are made proactively, before the failures accumulate into something irreversible.

The researchers who published the AI Agent Traps framework put it well: securing agents against environmental manipulation is as critical as ensuring autonomous vehicles can recognise and reject tampered road signs. In both cases, the safety of the system depends entirely on its resilience to a manipulated environment.

We are all, right now, in the potential for a manipulative, agentic environment.

The question is whether we build the agents, the infrastructure, and the regulations that can hold up to the privacy and ethics standards we deserve.

VEKTOR’s local-first architecture eliminates the class of attacks that require a networked memory endpoint. It does not eliminate attacks that occur at the agent layer before memory is written. We are one part of the defense stack, not the whole stack.

Know what layer you are protected on by auditing your own stack; do your own research and decide how much you want to be informed.

VEKTOR Memory builds local-first persistent memory infrastructure for AI agents. The VEKTOR Slipstream SDK scored 81% on LongMemEval using a local SQLite database and GPT-4.0-mini, beating full-context GPT-4 by twelve points. Find the benchmark results and SDK documentation at vektormemory.com.

Sources

Franklin, M. et al. (2025). AI Agent Traps. Google DeepMind. arxiv.org/pdf/2606.26627

Cloudflare. Ensure security and governance for AI agents. cloudflare.com/the-net/building-cyber-resilience/secure-govern-ai-agents

Cloudflare. Global expansion in Generative AI: a year of growth, newcomers, and attacks. blog.cloudflare.com

Cloudflare. Collaborates with leading browsers to develop a privacy-first protocol for the global internet. cloudflare.com/press/press-releases/2026

Cloudflare Radar. AI Insights. radar.cloudflare.com/ai-insights

Google Threat Intelligence Group. (2026). GTIG AI Threat Tracker: Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access. cloud.google.com/blog/topics/threat-intelligence

SecurityBrief Australia. Data privacy urged as strategic board issue in AI era. securitybrief.com.au

SecurityBrief Australia. AI, cyber threats and the rise of strategic data privacy. securitybrief.com.au

Captain Compliance. The Privacy Reckoning That Agentic AI Cannot Escape. captaincompliance.com

Privacy
Data Privacy
Agentic Ai
Google