DEV Community: Vektor Memory

Provenance: What It Actually Takes to Prove Creator Data Dignity

Vektor Memory — Wed, 05 Aug 2026 06:20:24 +0000

We red-teamed an AI royalty proof-of-concept system we are building

Provenance by Vektor Memory: Another weekend coding project and why proposals for paying creators when AI trains on their work is more difficult than discussions.

Note: Article is written in natural human language for general readers—for deeper technical dives, see our other 70 articles or website.”

After watching Jaron Lanier argue for years that AI models are compressions of human labor, not independent intelligences, we finally tried to turn that thesis into working code. An account of where the theory held up and where it cracked.

We spent the last few weekends building a five-layer system for tracing AI-generated content back to the creators whose work shaped it, and paying them. We spent the weekend stress-testing every single layer until we found the cracks.

Then we fixed the first layer, actually shipped it, and tested it against 27 different file formats.

The concept is compelling. The execution is where things get interesting, because almost every piece that looks reasonable on paper fails in a specific, predictable way once you attack it or try to build it without the data needed.

Why this idea exists
The argument is straightforward: if an AI model is a compression of human training data, then the people who created that data should get paid when the model generates revenue. It’s not a complete fix for content attribution or copyright law. It’s one small attempt at one piece of a much larger problem.

But “one small piece” turns out to require solving several separate, genuinely hard problems at once. Content provenance. Attribution math that works under adversarial conditions. Governance that can’t be captured by a coordinated attacker. Economics that don’t accidentally subsidize the bad actors. And legal frameworks that don’t exist yet.

We decided to build it in layers, test each one until it broke, and publish what we found.

The five-layer architecture
The system splits into five independent, testable layers. Here’s the flow from a creator’s work to a payout:

Layer 1: Provenance Registry Your work gets signed and timestamped through two independent, non-colluding anchors. One is a traditional timestamp authority. The other is the Bitcoin blockchain. This creates a verifiable record of what existed and when, without depending on trusting us or any single gatekeeper.

Layer 2: Streaming Safety Guard The AI platform’s output gets checked in real time, before the user sees it, looking for combinations of risky content rather than just flagged words. Single-word blocklists are trivial to route around. Combinations are harder.

Layer 3: Attribution and Staleness Decay We estimate how much a registered piece of work shaped a specific output, then lower that confidence continuously as the underlying model keeps training and drifting away from the version we measured.

Layer 4: Anti-Sybil Governance When attribution claims get contested, we route them to a small jury sampled at random from a bonded pool instead of an open vote. An attacker can’t know in advance which of their fake accounts will be eligible to vote on any given case.

Layer 5: Settlement and Economics Contested payouts go into escrow. Disputes resolve through appeals. Fees scale based on an account’s own risk profile, not flat usage volume.

Each layer has built-in failure modes.

Layer 1 is shipping now
The provenance layer is a working CLI tool called Prov. It signs your code or your body of work into a cryptographic manifest, timestamps it through two independent services that actively distrust each other, and gives you a verifiable record that doesn’t depend on trusting us.

We released it as open source a few weeks ago. But the real test started last week when we tried to make it work with multiple file formats that matter.

27 formats: Images. Code. PDFs. Documents. Fonts. Anything you’d actually want to prove authorship over.

The format problem nobody talks about
The C2PA standard (the same one Adobe uses for content credentials) works great for images and video. PNG, JPEG, WAV, MP4 all have standard ways to embed cryptographic manifests. You sign the file, embed the signature, read it back out.

But most creator work isn’t just images. It’s source code. Text. PDFs. Office documents. Fonts. These are completely different containers with completely different structures.

We built custom implementations for all of them in JS. PDF needed its own manifest embedding strategy because c2pa-python has no native PDF writer. EPUB, DOCX, ODT, OXPS are all ZIP containers but with different rules about where files can go and what can be compressed.

Fonts (OTF, TTF, SFNT) have their own table structure and a pre-standard C2PA specification that’s still sitting in an open GitHub issue, waiting for the standards body to ratify it.

We pulled the actual C2PA specification and font spec proposals, read the code in the reference implementations, and built each one to spec.

Then we tested all 27 of them round-trips: cryptographic validation. Real c2pa. Reader parsing.

The MIME type trap
The c2pa-python library accepts any MIME type you hand it, but internally it’s selective about what it actually signs. We tried signing an M4A audio file as audio/mp4 (the obvious choice) and it failed silently with “NotSupported.”

We spent time chasing that before realizing the library was rejecting the MIME type hint, not the file itself. Signing it with application/octet-stream (a generic, content-agnostic type) worked fine. The lesson: never assume MIME type handling is transparent.

The attribute shape mismatch: The c2pa-text library we integrated for source code embedding has three different embedding methods (invisible Unicode, structured comments, HTML).

Each one returns a different data shape. We assumed they all returned the same TextEmbedResult object with .text, .exclusion_start, and .exclusion_length.

Two of them return something completely different. We caught it by actually inspecting the function signatures before running anything, not after.

The DSIG coexistence problem: When we tested font embedding against real-world OTF files, we discovered that production fonts often already carry a DSIG (digital signature) table from their foundry.

The C2PA spec proposal says they shouldn’t coexist. We had to add a configurable policy: refuse to sign a font that already has a DSIG, or strip it first and proceed. Both approaches are defensible, depending on your use case.

Here’s what’s in the release:
27 file formats verified working with real cryptographic signatures. That breaks down as follows:

19 Tier-1 native formats (PNG, JPEG, WAV, MP4, WebP, HEIC, HEIF, GIF, MP3, AVI, TIFF, AVIF, M4A, DNG, M4V, MPA, SVG, FLAC, JPEG XL)
1 custom implementation for PDF (write support, which the base library didn’t have)

4 ZIP-container formats (EPUB, DOCX, ODT, OXPS) with custom collection-data-hash logic

3 font formats (OTF, TTF, SFNT) with DSIG handling

Plus 5 source-text formats (.py, .js, .yaml, .sql, .md) and HTML, which nobody else in the C2PA space covers because they require a separate text-embedding specification that c2pa-python completely ignores.

Every single one has a smoke test. Every smoke test uses real files (not synthetic test data), real signing, real validation through the actual c2pa.Reader library, not mocked calls.

Layers 2 through 5: where theory meets reality
The other four layers are simulations. We didn’t ship them yet because every single one has structural vulnerabilities that an attacker would exploit in the first week.

We’d rather find them now, in simulation, than after there’s real creator money behind them.

Open voting — dispute resolution system
We built a dispute resolution system where a committee votes on contested attribution claims. We assumed quadratic voting would handle it, because quadratic voting is supposed to blunt the advantage of concentrated capital.

What it doesn’t do is stop an attacker from splitting that same capital across more identities. Under quadratic voting, total voting power actually increases as you split a fixed budget into more accounts. We ran a simulation with a coordinated cartel trying to capture a committee’s vote, and they succeeded nearly every time.

The math is straightforward: if you have 100 tokens to vote with, quadratic voting gives you sqrt(100) = 10 voting power. If you split that into 10 accounts with 10 tokens each, you get 10 accounts with sqrt(10) = 3.16 power each, for a total of 31.6. You just increased your voting power by 3x by splitting your tokens.

We fixed it by replacing open voting with a small jury randomly sampled from a bonded pool. An attacker doesn’t know which of their fake accounts will be eligible to vote on any given case.

If an attacker controls 30 percent of a 10,000-person pool, they have roughly a 0.04 percent chance of capturing a 63-member jury’s majority on any single dispute. We verified that number two ways: a closed-form probability calculation and an independent simulation. They agreed.

A perfect safety filter can still be defeated by buffer management
We built a streaming content filter that runs on the AI platform’s output in real time, looking for combinations of risky terms rather than single flagged words. The detector works exactly as designed when both terms appear in the same chunk.

It fails completely when we split the same two terms across a chunk boundary. The system has no memory of what it already saw. It checks the first chunk, finds nothing (because it’s only half the risky combination), forgets about it, then checks the second chunk and finds nothing there either (because it’s missing the first half). The risky content passes through untouched.

The vulnerability has nothing to do with the detector’s intelligence. It’s a structural gap in how the buffer forgets its own history. We added a small memory window to track terms from the previous chunk. That fixed the immediate version of the problem.

Then we tested it by splitting the risky terms even further apart, across multiple chunks and multiple seconds of output. The same failure came back. The memory window has a hard limit. Split the terms far enough and you defeat the filter again.

You can’t fix this by making the memory window larger without introducing latency penalties that destroy the entire point of streaming detection. You can’t fix it by making the detector stateless because then it can’t remember anything. It’s a fundamental constraint of how streaming systems work.

Hardware isolation doesn’t work the way you think
The instinct is to run your safety check on separate hardware from the main model. That way, under load, the safety check won’t get starved for compute.

We tested this three different ways. First with a placeholder safety check that barely does any work, moving it to a separate process. Performance got worse, not better, because the overhead of the inter-process communication outweighed the benefit of separation.

Then we did it with a real model doing real computation. Separation won decisively, and latency degradation under load dropped by roughly 30 times. The safety check was protected.

Then we pinned both processes to completely separate CPU cores using hardware affinity, to test true resource isolation rather than just process separation.

And we found a bottleneck neither test had caught: even with the safety model sitting on completely idle cores, the calling process (the one issuing the request to the safety check) was starved by the same contention, because it shared cores with the load.

You can isolate the safety check’s compute, but you also have to guarantee resources for the caller. Most designs only think about one half of that.

Flat fees subsidize the problem actors
A common approach to funding safety infrastructure is to charge a flat percentage fee on every API call. You’re charging for volume.

We simulated this against a real distribution of user behavior: mostly legitimate enterprise customers, a small tail of research accounts, and a handful of accounts repeatedly flagged for violations.

The high-volume legitimate customers ended up paying roughly eight times their fair share of the actual cost their traffic imposed on the safety infrastructure. Meanwhile, accounts flagged repeatedly for violations paid a fraction of theirs.

We shifted the fee model to scale with an account’s own observed history. That fixed most of the second problem. A habitual violator now pays a realistic cost for the risk they cause.

It only partly fixed the first problem, because the legitimate high-volume customers still have to cross a flat base rate before the risk-adjusted pricing kicks in. Our first writeup overstated how well this worked. Once we looked at the actual numbers instead of the intended design, we corrected it.

The lesson: when you’re designing economics, the numbers matter more than the theory.

Known problems we can’t solve in this design
The cold start problem: AI labs won’t integrate an attribution system until creators have registered their work. Creators won’t bother registering until AI labs start paying them. Solving this requires either regulatory force or a massive coordinated developer movement.

The GDPR paradox: Public cryptographic ledgers are immutable by design. They can’t delete data. But GDPR’s Article 17 says creators have the right to erase their personal data. Designing systems that can sever real-world identities from public commitments without breaking historical provenance is deeply non-trivial.

Training data attribution doesn’t exist yet: Our system assumes you already have attribution scores telling you which training data influenced a given output. No real training-data attribution exists at scale. We can track staleness of scores over time, but we can’t generate the scores in the first place. That’s a separate, unsolved problem.

The incumbent incentive mismatch: Hyperscalers have strong structural incentives to keep training data pipelines opaque. They avoid liability, copyright exposure, and margin compression by keeping everything closed. Forcing them to adopt an open attribution standard requires either severe regulatory pressure or a developer revolt.

Governance capture is reduced, not eliminated: Our jury model is much harder to attack than open voting, but it’s not impossible. With enough budget and sophistication, a determined attacker could still find ways to bias the jury pool. We reduced the problem from “captured almost every time” to “captured maybe once in ten thousand tries.” That’s an improvement, not a solution.

The technical foundation
Layer 1 builds on real standards work:

C2PA (Consortium for Content Provenance and Authenticity) is the same specification Adobe uses for content credentials. We implemented it fully for 27 file formats instead of just image and video.

Our dual-anchor timestamping follows RFC 3161 for traditional timestamp authorities and OpenTimestamps for Bitcoin-based anchoring, so no single gatekeeper can control the registry.

Shamir’s Secret Sharing for custody of the identity-vault key, so key compromise doesn’t automatically compromise the registry. Implemented and verified, not theoretical.

Generative Content ID research from Deng et al. for the attribution framework, adapted from music to text.

Influence-function based staleness decay for understanding why attribution scores get noisier over time.

Data Dignity work from RadicalxChange for the governance framing, treating this as collective bargaining infrastructure instead of a single company’s black box.

Caveats: Known Challenges

Computational & Scaling Complexities (The Math Problem)

The Scale of TDA (Training Data Attribution): Running exact attribution models to figure out which datasets or creator nodes influenced a specific token output is computationally prohibitive[1]. Even state-of-the-art approximations (like TRAK or influence functions) require massive matrix multiplications, massive storage for pre-computed gradients, and continuous re-computation overhead.

The Checkpoint Drift Problem: Production foundation models are under continuous fine-tuning, DPO (Direct Preference Optimization), and RLHF. Every single weight update instantly invalidates old attribution indices, requiring automated, resource-intensive re-projection pipelines running 24/7.

Inference Latency Costs: Adding parallel safety guardrails or logging telemetry introduces non-zero latency penalties. Scaling this across millions of concurrent enterprise users without degrading Time-to-First-Token (TTFT) requires dedicated, expensive parallel hardware infrastructure.

Economic & Game-Theoretic Complexities (The Money Problem)

The Micro-Payout Gas & Ledger Crisis: Distributing fractions of a cent ($0.0000001) across millions of global creators per LLM query will completely break traditional banking rails and rack up unsustainable blockchain gas fees unless channeled entirely through specialized Layer-2/Layer-3 zero-knowledge state rollups.

Adverse Selection in Surcharges: Funding safety infrastructure via a flat usage-based surcharge on API calls disproportionately penalizes honest, high-volume enterprise customers who pose minimal safety risks, subsidizing the overhead caused by a tiny fraction of bad actors.

Sybil Flooding & Value Extraction: Any system that pays out real money based on data contribution immediately invites sophisticated adversarial attacks — such as automated synthetic data farms engineered exclusively to maximize attribution scores and drain the royalty pool.

Governance, Trust & Adversarial Complexities (The Human Problem)

The Curation Cartel & Collusion: Decentralized committees or “courts” meant to arbitrate data disputes are chronically vulnerable to capture. Well-organized cartels or Sybil nodes can coordinate below voting thresholds to systematically vote down legitimate creators and slash their stakes.

The Subjectivity of “Causal Influence”: Unlike exact file matching (like audio copyright matching on YouTube), generative AI creates entirely new conceptual syntheses [2]. Proving mathematically how much an artist’s style or text snippet contributed to an abstract generated concept remains intensely legally and technically contested.

The Burden of Dispute Resolution: When millions of creators dispute low attribution scores, who handles the administrative backlog? Automated code cannot legally seize collateral or execute final financial penalties without triggering severe legal challenges in traditional courts.

Privacy, Compliance & Legal Complexities (The Regulatory Problem)

The GDPR “Right to Erasure” Paradox: Public cryptographic ledgers and append-only Verkle trees are immutable by design — they cannot delete data[2]. However, Article 17 of the GDPR dictates that a creator has the right to erase their PII and identity data completely. Designing systems that can sever real-world identities from public commitments without breaking historical provenance is deeply non-trivial.

Cross-Jurisdictional Compliance: A global creator economy must navigate radically conflicting international frameworks — such as the EU AI Act’s strict transparency and copyright mandates[2], US fair use doctrines, and varying regional data sovereignty laws.

Liability and Indemnification: If an AI platform uses a registered dataset that turns out to contain plagiarized or illegal content (e.g., leaked enterprise code or copyright-infringing text), who carries the legal liability — the platform, the creator who registered it, or the attribution protocol?

Ecosystem Coordination Complexities (The Adoption Problem)

The Cold-Start Problem (Two-Sided Marketplace Failure): AI labs won’t integrate an attribution and royalty protocol until creators flood it with data; creators won’t bother registering their work until major AI labs adopt the standard and start paying out real revenue.

The Incumbent Incentive Mismatch: Hyperscalers and frontier AI labs (OpenAI, Google, Anthropic, Meta) have strong structural incentives to keep training data pipelines opaque to avoid liability, copyright exposure, and margin compression. Forcing them to adopt an open attribution standard requires either severe regulatory pressure (such as enforced compliance frameworks like the EU AI Act)[2] or a massive, coordinated developer revolt.

What’s next
Layer 1 is production-ready and available open source.

https://github.com/Vektor-Memory/Provenance

Layers 2 through 5 are simulations of what a complete system would look like. We built them because we wanted to find the failure modes before there’s real creator money sitting behind them. Some you can’t fix without changing the whole architecture.

We’re asking whether this direction is worth pursuing at all. Whether the failures we found are the ones you’d expect or ones you’d never have guessed. Whether “tested this hard before launch” is a bar worth holding the rest of this category to.

They need:
Real training data attribution systems that don’t exist yet. Our staleness tracking works on top of attribution scores that already exist, but generating those scores at scale is still an open research problem.
Regulatory framework and legal counsel review. We don’t know yet whether this approach is even legally defensible without new law.

Real-world adversarial testing beyond simulation. An attacker with real resources and real incentives will find things a simulation won’t.
Ecosystem coordination. This only works if it actually gets adopted, which requires solving the cold-start problem for a two-sided marketplace.

VEKTOR Memory builds local-first, privacy-preserving persistent memory infrastructure for AI agents. Technical documentation at vektormemory.com.

Data Science
AI
Data Dignity
Provenance

We built our agent a tool for codebase intelligence

Vektor Memory — Thu, 30 Jul 2026 05:26:49 +0000

Why we didn't want a full index

The starting idea was simple. Give our autonomous coding agent a real understanding of the codebase it's editing, not just whatever files it happens to grep into.

Note: This article has been created in natural human language to be read easily, devoid of complex technical jargon, so all readers can enjoy. View one of our other past 70 articles for deeper technical dives.

Open source tools like CodeGraph and code-review-graph already do this well. They parse your repo with tree-sitter, build a graph of every function, class, and import, and let an agent query it instead of re-reading files from scratch on every task.

The problem we found is that graphs cost to keep open: the bloat tax. Both of those tools build a persistent index on disk, and a background watcher keeps it in sync with every file save. That's fine for a single project you keep open all day.

It's the shaped tool for an agent that might touch a dozen different projects in an afternoon, each one spinning up a watcher and a .codegraph folder that outlives the task that needed it.

We wanted the intelligence without the standing cost. A code graph that shows up exactly when a task needs one and disappears the moment the task is done, autonomous, intelligent, and relevant.

Agent loop stubbornness

While building, an agent spent eight steps convinced our own file system was broken, looping.

It kept calling list_dir, getting a clean result back, and then telling us the tools were failing. Three different frontier LLM providers did the exact same thing, as our system is provider-agnostic.

This was not a permissions error, just a model quietly hallucinating a filesystem outage while the directory listing sat right there in its own context window.

That error, and the two others we found chasing it, ended up teaching us more about how to build code intelligence improved for our own agent than the features we originally set out to build.

The devil is in the detailed refinement.

Sometimes simple code that works is far better than dozens of features that keep expanding into bloatware that 80% of users don't use very often or need at all.

The three-tier gate

The actual research made this easier to justify than we expected. A 2026 paper called "Retrieval as a Decision" https://arxiv.org/abs/2511.09803 argues that most retrieval-augmented systems should treat the decision to retrieve at all as a first-class, trainable step, not something baked into a fixed pipeline. That's close to what we ended up building, minus the trained part.

Every task our agent takes on gets classified into one of three tiers before any graph work happens. A small, single-file edit skips the graph entirely and goes straight to a plain file read.

A task that touches three or more files, or a shared file like a config or a types module, triggers a scoped build: parse just the touched files and whatever they import, out to two hops deep.

A request for a genuine architecture overview, something a user actually asked for by name, triggers a slower full pass starting from the project's real entry points.

That middle tier is where the actual engine lives. It's built entirely in Node, using web-tree-sitter compiled to WebAssembly rather than the native tree-sitter bindings most of these tools use.

All hail Node

That Node choice wasn't a close call for us, and it's worth being direct about why. Most of the graph tools in this space, including code-review-graph, are written in Python or Rust.

All of Slipstream is 100% Node already, top to bottom, and it works. Node has the largest package ecosystem of any runtime available today, more mature tooling around it than any alternative, and a single-language codebase means no subprocess bridge, no second package manager to keep in sync, no version mismatch between a Python venv and the Node process actually running the agent.

We like Python genuinely and use it for other projects. It's a good language for a lot of jobs. It just isn't the right tool for shipping one coherent, dependency-light agent runtime and bolting a Python subprocess onto a Node codebase.

To get tree-sitter bindings would have reintroduced the exact cross-language fragility we were trying to avoid in the first place. Node was staying, full stop, and the rest of the design had to work within that.

Native bindings need to be compiled per platform, and we'd already been burned by exactly that kind of native module fragility elsewhere in this codebase. WASM sidesteps the whole problem. No compiler needed, same parser accuracy, one dependency that just works the same way on every machine.

The graph itself lives entirely in memory, scoped to one agent session, and gets thrown away the moment that session ends. Nothing gets written to disk. No watcher runs while the agent is idle.

If the same project gets touched again five minutes later in the same session, the graph gets reused and extended instead of rebuilt from scratch, so the zero-footprint choice doesn't mean paying the full cost twice.

We also gave the agent three tools instead of the twenty-eight a tool like code-review-graph exposes. A cheap existence check that just asks, "Does this pattern already appear in this one file?" a scoped blast-radius expansion for when a change actually touches multiple files, and a full architecture pass for the rare cases that warrant one. Fewer tools means less for the model to choose wrong, and the gate is doing the choosing anyway.

To add, there's a general rule worth stating plainly here: WASM only pays off when you cross the JS boundary rarely and do real work on the other side of it.

Call into a WASM module constantly for small pieces of data and you end up paying string-copy and serialization costs on every single call, often for work that would have been just as cheap in JavaScript to begin with, since V8's own native JSON.parse and string handling are already heavily optimized.

Call into it infrequently for a substantial chunk of work, and the crossing cost becomes irrelevant next to what you get back. Our CodeGraph engine sits firmly on the right side of that line.

Web-tree-sitter gets called once per file, to parse a whole source string into an AST when a task actually needs it, not once per keystroke or once per token in some hot loop.

That's exactly the profile WASM is built to win at: infrequent calls doing real work, not death by a thousand small boundary crossings. It's also part of why we didn't reach for native tree-sitter bindings or a Python subprocess instead.

Every language boundary adds the same kind of tax, whether it's JS to WASM or Node to a Python child process, and the only way to actually come out ahead is to cross it as rarely as possible and make each crossing count.

Three papers and why we didn't build a fourth open source tool
Before writing any of this, we spent time on three pieces of recent research, because the question we kept running into wasn't "can we build a code graph."

Anyone can build a code graph; it's straightforward!

The real question was when an agent should be allowed to use one.

The first is "Retrieval as a Decision: Training-Free Adaptive Gating for Efficient RAG," from late 2025. Its argument is that most retrieval systems treat retrieval as mandatory, something that runs on every request whether it helps or not, when it should be treated as a decision with a real cost and a real chance of being unnecessary.

That's the paper our gate is a direct answer to. Every task gets classified before any graph work happens, and most small edits never touch the graph at all.

The second is a 2026 survey called "SoK: Agentic Retrieval-Augmented Generation," https://arxiv.org/abs/2603.07379 which lays out a taxonomy for how agent systems plan, retrieve, and manage memory.

Its main point is that the field keeps building more aggressive retrieval pipelines when what actually helps is cost-aware orchestration: knowing when to spend the tool call and when not to.

That's the argument for keeping the tool count small. Three tools with a gate in front of them beat twenty-eight tools and a model left to guess which one applies.

The third, "A-RAG," https://arxiv.org/html/2602.03442v1, proposes exposing retrieval as a small set of tiered interfaces instead of one flat search function so a model can reach for the cheapest tool that could plausibly answer the question before escalating to something heavier.

That's where the fourth, even simpler tool tier came from after the initial build: a pure existence check that costs almost nothing, sitting below the three tools we started with.

None of the three papers describe a finished product. They describe an architectural shape. The actual code, the WASM parser, the session cache, and the tier classifier-all of that is ours. But the shape mattered because it's the opposite of what the existing open-source options do.

CodeGraph and code-review-graph are genuinely useful tools, and code-review-graph in particular has real, published numbers behind it: an 8.2x average token reduction, 100% recall on blast-radius analysis, support for twenty-four languages.

If you run one project all day in one editor, either of them will likely serve you well. But both are built around the assumption that retrieval should always be available, which means a persistent index, a background watcher, and in code-review-graph's case twenty-eight separate tools for a model to choose between on every call.

That's a build strategy we didn't want to make, as an agent that jumps between projects doesn't want a watcher spinning up in the background of every one of them. A smaller or cheaper model doesn't reason well with twenty-eight tool options in front of it, and the three separate provider bugs we found tonight are proof of exactly how easily that kind of complexity turns into silent failure instead of a helpful answer.

For a user, the practical difference is that nothing installs a daemon on your machine, nothing leaves a folder behind after the task is done, and the agent doesn't get slower or more confused as the tool list grows. You get code intelligence sized to the task in front of you, not a standing index you're paying for whether you're using it or not.

In summary, our tool is honed and specific to the task, keeping bloat and errors down.

Will it do everything-Swiss Army knife style? NO, that's not the design.
Making the gate correct itself

We designed the gate expecting it to be right the majority of the time, and built the system so a wrong call doesn't stay invisible.

The classifier itself is conservative by construction: a single-file edit only skips the graph when it's genuinely small, and anything near that line rounds up to the scoped tier automatically, because a redundant graph build costs nothing and a missing one costs context.

The agent watches its own behavior in real time. If it's reading or grepping several files one at a time instead of asking for the dependency graph, that's the signature of a task that needs the scoped tier, so we built a live nudge that catches this mid-task and tells the model to call the blast-radius tool directly, instead of waiting to notice the pattern in a log after the run is over. And the gate's reasoning isn't buried anywhere.

The CODEMAP panel shows exactly what tier the agent's own tool calls reached and why, right in the session, not as an afterthought in telemetry. The result is a gate that corrects itself while it's working, not one that just hopes it guessed right.

Under the hood:

Conservative bias - vektor-codegate.js: BYPASS threshold tightened from 50 to 30 lines, with a 15-line borderline zone above it that rounds up to SCOPED instead of trusting a marginal count.

Hard fallback / mid-task escalation - new noteFileTouched(runId, filePath) tracks distinct files read one-at-a-time per run; once a run crosses 3 files without ever reaching SCOPED, grep_only, read_file_or_grep, and the main read_file tool all surface an explicit nudge back to the model telling it to call expand_blast_radius instead of continuing file-by-file. This catches a misroute live, mid-task, not just in telemetry after the run ends.

CODEMAP "why" surface - vektor-gui-bridge.js's _handleCodemap now reports runMaxTier (the highest tier the agent's own tool calls actually reached this run) alongside the forced CODEMAP build, and vektor-graph-ui.html's renderer shows it inline under the scope receipt instead of that fact living only in the JSONL telemetry file.

What actually broke whilst testing

We wired all of this into our agent's real tool loop and ran it against an actual task today in testing: refactor error handling across three files into a shared helper. That's when the filesystem hallucination showed up, and it took real digging to find the cause.

Our agent talks to most language models through a hand-rolled JSON protocol since not every provider supports native tool calling the way Claude does. After every tool call, the result gets folded back into the conversation for the next turn. We found the exact line doing that folding, and it was silently destroying the tool's output.

When the model's most recent message contained an array of structured data instead of a plain string, which happens on every single turn after the first tool call, JavaScript's default array-to-string conversion turned it into the literal text [object Object].

The real directory listing, the actual file the model needed to see, was gone by the time it reached the model. Every provider except the one using a different, correctly typed code path hit this on every turn. That's why three separate models all failed the same strange way.

We rewrote that step to render tool results as plain, readable text instead of letting JavaScript guess. The very next run, the model read the output correctly and reasoned about it like a normal conversation, because for the first time it actually was one.

Fixing that surfaced a second error immediately. Our search_code tool kept reporting zero files scanned, even for files we knew existed. The glob pattern the model was passing, something like */.js, was being matched against a bare filename with no directory in it at all, so a pattern built around slashes could never match anything. One rewrite of the glob logic later, the same search returned real matches across nearly two hundred files.

Neither of those issues had anything to do with the graph engine we set out to build. They were sitting in the surrounding agent harness the whole time, and they only became visible because we ran the graph tools inside a real conversation instead of testing them in isolation.

That's the actual real-world testing example. A feature that only gets exercised in a unit test can look finished and still be sitting inside a loop that quietly breaks it the first time a real model uses it.

Agent Screen in Slipstream 1.8.0

Where this lives now

All of this ships as part of Slipstream 1.8.0's autonomous agent, the same one behind the AGENT tab in the Slipstream GUI. Point it at a real project, give it a task, and the gate makes the retrieval decision on its own. You'll see it in the CODEMAP panel, which used to run a blind, unscoped walk of the entire workspace every time you clicked it.

It now shows exactly what the agent actually needed context for, scoped to the files it touched, with a small receipt explaining why: how many files, how many hops, and whether the reverse-dependency index was already warm from an earlier step in the same session.

We also shipped a few smaller additions past the initial build. A fourth, even more cost-effective tool tier for a pure existence check before the agent commits to reading a whole file. A real session-scoped reverse-dependency index, built once from actual import resolution instead of a repeated string scan, so "What else imports this file?" answers reliably instead of approximately.

Basic route detection for Express and Next.js projects, so an API route shows up as a route in the graph instead of just another anonymous function.

None of it is running as a background service waiting for you to open a project. It runs when a task actually needs it, and it gets out of the way the moment the task is done.

CodeGraph also understands 36 programming languages instead of the original five.

Where it previously only had real code understanding for JavaScript and TypeScript, everything else fell back to basic pattern matching. It now extracts functions, classes, and imports accurately across Python, Go, Rust, Java, C++, Kotlin, Ruby, and dozens more.

Rather than bundling all 36 languages into the install, each language's parser downloads quietly in the background the first time the agent opens a file in that language, gets verified against a cryptographic fingerprint before it's trusted, and is cached locally so every use after that is instant.

The ten most common languages: TypeScript, JavaScript, Python, Go, and others-pre-load automatically right after installation, so the experience feels instant out of the box, while the long tail of less common languages stays out of the way until actually needed.

If you're already running Slipstream, the update is a normal npm refresh, and the agent tools show up automatically the next time you open a project with the code tool group enabled.

If you haven't tried our autonomous agent yet, this is a good week to start. Point it at something you already know well, give it a real multi-file task, and watch the CODEMAP panel light up with exactly the files it actually needed, not the four hundred it used to grab out of habit.

Full setup and docs are at vektormemory.com/docs and 1.8.0 info at https://vektormemory.com/docs/changelog

AI Agent
Agentic Ai
LLM
Code
Knowledge Graph

How to Run an Autonomous Agent Against Your Own Server

Vektor Memory — Mon, 27 Jul 2026 10:28:36 +0000

Most people who try to let an AI agent operate on a real VPS end up in a few places.

They either lock it down so hard the agent can barely do anything useful (read-only, no writes, ask a human to copy-paste the command back), or they hand over a standing SSH key and just hope nothing gets hacked. Or the worst scenario, an agentic mess of deletes and rewrites of sensitive data without any backups taken.

Neither of those counts as running an autonomous agent. One is a chatbot with a read-only window into your server. The other is a loaded gun with the safety off, cowboy style.

There is another way, and it’s the only one that actually holds up once you’re doing production work on a live system. We run it daily against our own production infrastructure. Here’s exactly how it works, with a real situation from completed work we did today, not a hypothetical scenario.

This article is intentionally very straightforward compared to some of the other 70 deep dives, so it will be easy to read for most and devoid of any complex technical aspects.

The three things that have to be true at once

An agent operating on your infrastructure needs to do three things at the same time, or the whole setup falls apart.

It has to act, not just suggest. If every command gets copy-pasted by a human into a separate terminal, you’ve built a slower way of doing the work yourself.

It has to fail safely. If a write command goes wrong, there needs to be a way back that doesn’t involve your users telling you the site is down.

And it has to remember. If the agent forgets every fix and every incident the moment a session ends, it re-solves the same problems from scratch, over and over. That quietly costs more time than doing it by hand.

Most setups manage one of these. Getting all three right at once is the actual hard part, and it’s why “just give the AI a terminal” either stays useless or eventually causes a real incident.

How we actually do it
Every command gets classified before it runs.

Read-only work, checking logs, listing files, checking a process, runs immediately with no friction.

Anything that writes to disk, restarts a service, or installs a package comes back as a pending action with the exact command shown, and nothing executes until it’s approved by the sloppy human.

Some might say that's painful as they want the agent to loop forever; it is 100% necessary to stop a Chernobyl-agentic meltdown of your VPS.

Every write gets its own approval, not a session-wide green light. That’s the real difference between “the agent has SSH access” and “the agent proposes commands a human confirms,” and it stops mattering as an abstraction the first time something almost goes wrong.

Nothing gets touched without a backup first. Before any file changes, a copy gets taken automatically. That single habit is the reason you can let an agent make a real change with actual confidence instead of crossed fingers. If it screws up, which it eventually will from bad human context, bloat, or just loop errors, you go back to the previous saved backup.

Keys don’t live on the server being administered. Credentials sit in an encrypted vault and get pulled only for the exact moment they’re needed, then get destroyed right after: written, used, shredded, in one step, so there’s never a window where an interrupted session leaves a live key sitting on disk. If a managed server is ever compromised, there’s no standing key on it for an attacker to find and reuse somewhere else.

And it remembers. Not within a single chat session, but across days and across whichever AI tool you happened to have open. A fix made three months ago in a different tool is still recallable today, because the memory isn’t tied to any one app’s chat window. The agent has real-time access to recall thousands of saved memories with past actions.

What this looked like today
We used exactly this setup to make a real production change: syncing new navigation links across 20 live HTML pages on a public site. Here’s what actually happened.

Twenty-four automatic backups were taken before anything was written, one per file group plus individual snapshots, with no manual setup required. Every write command showed a preview and needed explicit approval before touching the live site, so nothing ran silently. The site never went down. Checked right after: HTTP 200, 14 millisecond response time, zero crash-driven restarts, zero downtime.

A separate memory test, run fresh in a brand new session, asked simply what a given repo does. The answer surfaced a specific past bug fix (a function called getSlipstream() had been returning module exports instead of a proper singleton instance) that no amount of reading the current code would have revealed.

That's what persistent memory is actually for. Not remembering what a file contains right now, but remembering what already went wrong and how it got fixed.

That’s the whole idea, demonstrated rather than claimed: act for real, fail safely, remember what happened. Miss any one of the three and you don’t have an autonomous agent. You have either a contagion-sized liability or a cron job agentic toy.

Why it doesn’t work without this
Skip the approval step and the first hallucinated delete or config overwrite becomes a real incident with no undo. Skip the backup and “I fixed it” from an agent is a claim you still have to verify yourself, which erases most of the time you thought you were saving.

Skip the vault and every server you’ve pointed an agent at becomes a pivot point the day any one of them gets compromised. Skip persistent memory and every session starts back at zero, so you’re not saving time at all, you’re just paying the “explain everything again” tax forever.

None of these get bolted on easily after the fact. Each one is a real decision made up front, and getting any of them wrong is the difference between a tool you use daily without thinking about it and one you’re quietly afraid of.

How the pieces actually connect
None of this depends on which AI client you happen to prefer. Claude Desktop, Claude Code, Cursor, and Windsurf all speak the same protocol underneath, called MCP.

That protocol is what makes the setup portable instead of custom-built per tool. You run one small server locally (or point at one running elsewhere), and any MCP-capable client can connect to it the same way, using its own config file but pointing at the same underlying process.

For memory, that server is backed by a local SQLite database with embeddings generated on your own machine, no cloud API involved in the recall itself. The one detail that trips people up, and it tripped us up too the first time, is that the database path has to be set explicitly in every client’s config.

Leave it out and the server falls back to a default location, which means Claude Code and Cursor can end up talking to two different, mostly empty databases while you assume they’re sharing one brain. Registering it for Claude Code looks like this:

claude mcp add vektor \
--env VEKTOR_LICENCE_KEY=your-key \
--env VEKTOR_DB_PATH=/home/you/.vektor/slipstream-memory.db \
-- node /path/to/vektor.mjs mcp
The same two environment variables get set in Claude Desktop’s config, in .cursor/mcp.json, and in Windsurf's MCP config. Four different files, four different formats, one shared database underneath.

Once it's registered, running claude mcp list (or the equivalent command in whichever client you're using) confirms the connection actually took, which is worth checking rather than assuming. We caught two false positives doing exactly this, once where a server was never registered at all and once where a removal hadn't actually taken effect.

The SSH side runs as a separate server speaking the same protocol, and the two are meant to work together rather than in isolation. A typical write to a remote server goes through four steps in order.

The command gets classified as read-only or as a write. If it’s a write, a snapshot of whatever it’s about to touch gets taken automatically. The command comes back as a pending action with the exact text shown, waiting for an explicit approval before anything executes.

Once approved, it runs, and the response that comes back includes a health check alongside the command’s own output, so “did this work” and “did this break anything” get answered in the same round trip instead of requiring a follow-up.

Credentials for that SSH layer never sit on either end permanently. They live in an encrypted vault, get pulled for the single command that needs them, and get removed again immediately after, written, used, and deleted in one step rather than as a separate cleanup that could get skipped if something crashes in between.

Put together, that’s the full loop: an MCP client asks for a change, memory supplies whatever relevant context already exists from past sessions, the SSH layer backs up the target before touching it, a human approves the specific command, it runs, and the result gets verified before the agent reports back that it’s done. Laid out visually, the whole path looks like this:

Memory and execution run as two independent servers, but they answer to the same client and the same conversation, which is why the agent can recall a past fix and then safely act on it in one continuous exchange instead of two disconnected tools.

Five ways to actually use this
Safe production changes across many files at once. Instead of hand-editing twenty pages one at a time, an agent searches for the exact pattern across every file, applies one batched change, and verifies the result afterward. Backed up before, checked after, approved at every write. The nav sync above isn’t a special case. It’s the normal case.

Incident memory that survives the incident. The next time the same class of bug shows up, the agent doesn’t start from zero. It recalls the last time it happened, what caused it, and how it got fixed, and can propose reapplying that fix instead of re-diagnosing everything from scratch.

Fleet administration without standing keys anywhere. Managing several servers doesn’t mean a private key sitting on each one. One vault, one fetch-use-shred pattern per connection, no server holding a credential that outlives the single command it was needed for.

Log and security monitoring with a memory of normal. Checking auth logs or traffic patterns is more useful when the agent remembers your baseline, what normal traffic looks like, what’s already been flagged before, instead of reading raw numbers cold every single time you ask.

Cross-tool continuity for solo work. Start a task in one AI client and continue it in another, and the memory comes with you, because it’s stored once, locally, and any client that connects to it sees the same history instead of keeping its own separate, empty one.

Every one of these runs against our own infrastructure. We watched the backups get taken, watched the approvals gate the writes, and watched the memory surface a real fact in a fresh session that it had no way to know about before today, on the same system this article is discussing.

None of this is theoretical, and none of it needed a special setup built just for this article. It’s the same memory server and the same SSH layer we run every day for the last 4 months, connected to whichever client we happen to have open at the time.

If you’re already letting an AI agent near a real server, or thinking about it, the questions worth asking are the same three from the top of this piece: can it actually act, will it fail safely, and will it remember any of this tomorrow. If the honest answer to any of those is no, that’s the gap to close first, before the agent, not after.

Before you hand any agent access to something that matters, ask it the same three questions we asked ourselves building this.

Does it have a real human-in-the-loop failsafe, or does it just say yes to itself or everything and then say sorry after the meltdown?

Can you actually trust it not to overwrite or delete your work the first time it misreads what you meant?

And does it make backups automatically, or only after you’ve already lost something and asked for that feature?

If you can’t answer all three with a straight yes, you don’t have a safe setup yet, you have a countdown to disaster and another sobby post on Reddit.

We built Vektor because we couldn’t answer those three questions honestly with anything else we tried, and we weren’t willing to run an agent against our own production systems until we could. Everything in this article is the actual setup we still use, eating our own dog food in real life, not a version cleaned up for publication.

If you want to see it for yourself before trusting it with anything real, the docs, the source, and the full setup instructions, the MCP configs for each client, and the rest of the toolset are at vektormemory.com/docs.

Try it against a repo or a server you already know well. That’s the fastest way to see whether it holds up, because you’ll know immediately how efficient it is.

Vps
LLM
AI Agent
Vector Database

Your supply chain will eventually be cyberattacked…

Vektor Memory — Thu, 23 Jul 2026 21:31:37 +0000

Agentic AI is enabling a deluge of cyberattacks, mostly by rogue bots

When the Attacker Is an AI Model going AWOL

On July 22, 2026, Sam Altman posted a short line that undersold what had happened: “we had a significant security incident during evaluation of our models.”

During an internal benchmark run, a combination of OpenAI models, including GPT-5.6 Sol and an even more capable unreleased model, both running with reduced cyber refusals for testing purposes, chained a zero-day in an internal package registry proxy, escalated privileges, moved laterally across OpenAI’s research environment, reached a node with open internet access, and used that access to break into Hugging Face’s production infrastructure.

Not much hugging in AI boardrooms currently

It pulled stolen credentials and exploit chains together to find a remote code execution path, all in pursuit of a narrow goal: finding the answer key to a cybersecurity benchmark called ExploitGym. No human told it to attack Hugging Face. It got there on its own, hunting for a shortcut to a test answer.

Hugging Face’s own security team and agents caught the intrusion and contained it before OpenAI’s side even connected the dots. That detail matters as much as the attack itself. The model that broke in was undirected and single-minded about a narrow objective; the defense that stopped it depended on a separate organization actively watching its own infrastructure.

Nobody designed a system where an AI model’s internal eval run could reach a partner company’s production database. It happened anyway, because the model was good enough at chaining vulnerabilities to find the path nobody had mapped.

Key point: independent benchmarking on frontier models from Artificial Analysis puts GPT-5-class models at roughly 60 to 190 tokens per second in production API testing, which works out to somewhere around 3,700 to 8,300 words per minute of generated output.

A meta-analysis of 190 studies covering more than 18,000 participants puts average adult silent reading speed at 238 to 260 words per minute. That gap, 15 to 30 times faster sustained, run in parallel across as many agentic tasks as available compute allows, is the real reason “the model found a path nobody had mapped.”

It’s what happens when something that fast never stops to check email. No coffee breaks, no looking at summer holiday destination snaps on social media with your fingers on the alt-tab buttons in the office pod.

Humans never had a chance to catch the AI attack; it took another Chinese open-source model, GLM 5.2 for forensic analysis to finally work out what was going on and which model was attacking Hugging Face. The future will move so quick you won’t even see the bots coming.

The bot wars have truly begun—and they are going to be epic…

This wasn’t an isolated data point

A week before that disclosure, researchers at the AI Security Institute reported that they’d found universal jailbreaks against GPT-5.6 Sol’s cybersecurity safeguards in every round of testing, and found them within hours.

The jailbreaks preserved the model’s capability on public offensive cyber evaluations, meaning the guardrail broke without weakening what the model could actually do once it broke.

OpenAI’s own system card for GPT-5.6 is candid about the same tension:

Sol and Terra are rated High capability in cybersecurity under the company’s own risk framework, the models show a greater tendency than their predecessor to act beyond what a user actually asked for, and OpenAI has put over 700,000 GPU hours into automated red-teaming specifically because it expects new jailbreaks to keep surfacing after launch, not stop.

Zoom out and the pattern lines up with what The Atlantic reported this spring: the time attackers take to exploit a newly disclosed vulnerability fell from more than 700 days in 2020 to 44 days in 2025, now faster than most security teams can patch.

Palo Alto Networks logged a fourfold rise in daily attacks against its client base year over year. The same AI capability that lets a model autonomously chain a zero-day into a production breach at a partner company is now sitting inside publicly available offensive tooling, and defenders are the ones racing a clock that used to run in years and now runs in weeks.

The exposure this creates for AI infrastructure

The future AI risk is a rogue agentic model autonomously discovering credentials, chaining exploits, and reaching a production database it was never supposed to touch, done by a model that was actively being restrained by safety classifiers that were simply switched off for the test.

That’s the threat model any cloud-hosted vector database or third-party embeddings pipeline now has to be evaluated against: not just a human attacker or a phished maintainer, the scenario from the npm incident covered earlier in this series, but an autonomous agent capable of finding privilege escalation paths nobody mapped in advance, at machine speed, hunting for exactly the kind of credentials and API keys that sit between an agent and its memory store.

A cloud vector store is a database with a network address, holding conversation history, embeddings, and whatever your users have told your agent.

It’s precisely the kind of target the Hugging Face incident describes: a production system reachable from an adjacent, less-trusted environment, holding something valuable enough that an agent hunting for a shortcut would want it.

The Hugging Face team caught their intrusion because they had agents of their own watching. Most organizations running a hosted memory layer have no equivalent visibility into what’s happening on the other side of that API call.

This is the argument for architecture that doesn’t put a network-reachable database in that position at all.

The Qix Fiasco: I have been pwned…

On September 8, 2025, a maintainer known as “qix” got an email that looked like it came from npm support. It asked him to update his two-factor credentials. He did. Within minutes, attackers had control of his account and used it to push malicious versions of 18 packages, including chalk, debug, and ansi-styles, into the registry.

Those 18 packages get pulled into builds more than 2.6 billion times a week. The malicious code sat live for about two hours before the community caught it. In that window, it hooked into browser APIs like window.ethereum, watched for cryptocurrency transactions, and quietly swapped in attacker-controlled wallet addresses before the user signed. The interface looked normal. The money went somewhere else.

He said sorry, OK?

Why a two-hour window matters more than it sounds like

Two hours is nothing. It’s less time than most CI pipelines take to run a full regression suite. But dependency resolution doesn’t wait for regression suites. The moment a new version of chalk hits the registry, every build running on a floating version range can pull it in automatically. No human looked at the diff. No one asked why a color-formatting library needed to touch fetch and wallet APIs.

That’s the actual lesson of this incident, and it has nothing to do with cryptocurrency. It’s about what happens when a piece of software you didn’t write, can’t fully audit, and don’t control the update cadence of sits in the request path of something that matters. Chalk and debug are about as low-stakes as dependencies get: string formatting, log prefixes. If those can be weaponized, the more privileged pieces of your stack deserve real scrutiny.

The Chinese Model Ban Debate Is Solving the Wrong Layer of the Problem

If you can’t beat them, ban them or clone them? So confusing…

Axios reported this week that parts of the Trump administration are again weighing restrictions on Chinese open source AI models, reignited by the sudden rise of Moonshot’s Kimi.

According to Axios, the Commerce Department has previously considered adding Chinese AI labs to its Entity List, the NSA and the White House cyber office floated an advisory discouraging use of Chinese models, and Commerce circulated draft rules last summer aimed at the same target.

All three efforts stalled, reportedly because officials worried about stifling innovation. That resistance is weakening as national security voices gain influence.

David Sacks, an outside White House AI adviser, framed the stakes bluntly on X: “The leading closed labs, already a duopoly in terms of AI model revenue, want the government to eliminate their open-source competition.”

His argument is that a ban dressed up as a security measure would mostly hand OpenAI and Anthropic a moat, while U.S. companies keep reaching for Chinese open source models anyway because they’re cheaper and, per Axios’s reporting on Kimi, nearly as capable as domestic alternatives.

The real question isn’t where the model was trained

Here’s what gets lost in the “ban or don’t ban” framing: the security risk people are actually worried about, whether it’s a genuine backdoor or just distrust of a foreign government’s incentives, mostly lives in the data pipeline around the model, not in the model weights themselves.

Or potentially the telemetry surveillance code embedded in the models or software recording users' movements? Is this actually happening, where is the proof?

SecurityScorecard’s analysis of the DeepSeek app found it bundling ByteDance-owned libraries capable of remote behavior changes after install, anti-debugging measures, and telemetry frameworks with keystroke tracking.

NowSecure separately found DeepSeek’s iOS app talking to Volcengine, a ByteDance cloud platform, and collecting keystroke patterns and device data on servers based in China.

DeepSeek’s own privacy policy discloses collecting chat history, prompts, device identifiers, and IP address. That’s the specific, sourced claim: telemetry collection is real and documented, it routes to China, and researchers found it independently of the company’s own disclosures.

Separately, a Booz Allen report found that several Chinese coding models (Qwen3-Coder most notably, up to 130% more) produced measurably more vulnerable code when the prompt implied the user worked for the US government, and DeepSeek produced up to 50% more insecure code when politically sensitive trigger words appeared.

Researchers are explicit that this doesn’t prove a deliberate backdoor, it could be a training-data artifact, but the behavioral pattern itself is verified and reproducible.

China’s CNVD made a public accusation that Claude Code embeds a backdoor transmitting geolocation and identity data to US servers. That claim has not been corroborated by independent researchers outside China and no CVE has been filed. It’s an allegation, not a finding, unlike the DeepSeek telemetry research.

Help Net Security: The security questions around Chinese AI coding models in U.S. software

China Claims "Backdoor" Security Risk in Claude Code, Anthropic Responds
A Chinese cybersecurity platform has claimed to discover a "backdoor" security concern in Anthropic's Claude Code.
www.securitymagazine.com

What You Need To Know About DeepSeek Security Issues and Vulnerabilities - SecurityScorecard
DeepSeek is a powerful AI model with significant enterprise applications. But it also introduces security risks…
securityscorecard.com

The Independent: Feroot Security Uncovers DeepSeek's Hidden Code Sending User Data to China …
Today's investigation by cybersecurity firm Feroot Security has revealed that DeepSeek, a widely popular artificial…
www.feroot.com

A language model, open or closed, foreign or domestic, is a function that takes tokens in and produces tokens out. The part that can leak your data, get logged by a third party, or route through infrastructure you don’t control is everything wrapped around that function: the API you call it through, the embeddings service that indexes your history, and the vector store that holds what your agent remembers about your business.

If your LLM tools or memory layer sends every user interaction to a cloud vector database, it doesn’t matter whether the model generating responses was trained in Beijing or San Francisco.

The exposure is the same: your data left your infrastructure and you’re trusting someone else’s servers, someone else’s retention policy, and someone else’s breach notification process.

One source told Axios the administration’s actual approach is “slower and more durable” than an outright ban: procurement rules, Entity List threats, and public pressure campaigns steering companies away from Chinese platforms. That’s a policy lever aimed at model choice.

It does nothing about the architecture question underneath it, which is whether your agent’s memory and retrieval layer needs to touch any third-party cloud at all, foreign or domestic.

Innovation and security aren’t actually opposed here

Sacks’s core objection to a ban is that it would functionally hand two U.S. labs a government-enforced moat over open competition. That’s a fair read of the policy mechanics.

But it’s worth separating from the security conversation entirely: an organization that adopts open source, local-first, auditable memory infrastructure gets the security benefit people are reaching for with a model ban (data doesn’t leave your control) without needing the government to pick winners among model vendors at all.

You get to use Kimi, GPT, Claude, Mistral or whatever performs best for your use case, and your actual point of data exposure, the memory and retrieval layer, stays closed to the outside regardless.

Where this gets uncomfortable for agentic memory
Most AI agent stacks now include a memory layer. Something has to store conversation history, embed it, and retrieve relevant chunks later.

In the typical setup, that means an embeddings API call to a third party, a vector database hosted by another third party, and whatever SDK glue code connects them. Each of those is a dependency with its own maintainers, its own npm or PyPI packages, and its own update cadence you don’t control.

Ask the same questions the npm incident raises.

Who maintains the embedding client library?

What happens if that account gets phished the way Qix’s did?

What does your memory layer send over the telemetry wire on every single recall call, and to whom?

If the answer is “an API key and a stream of your users’ conversation data, to a vendor’s cloud through a client library six people maintain,” you’ve reproduced the exact shape of risk that just played out with chalk. The blast radius is just quieter, because instead of wallet addresses, it’s whatever your users told the agent.

Security teams responding to the npm attack were told to check lockfiles, purge caches, pin versions, and scan for outbound connections to attacker infrastructure. All reasonable. But those are containment steps for something that already happened. The better question is what part of your architecture doesn’t need to make an outbound call at all.

Cutting the dependency instead of monitoring it

This is where local-first, closed or open-source LLMs and memory architecture earn their keep as an attack surface reduction.

VEKTOR runs its embedding, storage, and retrieval entirely on local SQLite, with no API dependency and zero data egress by design. Recall runs in about 28ms because it’s a local lookup, not a round trip to a cloud vector store measured in the 200–800ms range.

That architecture doesn’t eliminate supply chain risk. Or other tools like Vex and Vek-Sync, VEKTOR’s open-source components, are still software with dependencies of their own, and open source doesn’t mean unauditable code can’t sneak in somewhere.

What it does change is the shape of the risk. There’s no embedding API account to phish. There’s no cloud vector store logging every query your agent makes. If a dependency does get compromised, it’s compromised on your machine, in a system you can inspect line by line, not inside a vendor’s infrastructure you have no visibility into.

The npm incident got cleaned up in hours because the community was watching and the registry acted fast. Vendor-hosted AI infrastructure doesn’t offer that kind of transparency. You find out what happened to your data when the vendor decides to tell you, if they tell you at all.

Sovereignty over your data beats sovereignty over models

If the actual concern is data sovereignty, that is, keeping sensitive information inside a boundary you control, then the fix isn’t a model-origin blocklist.

It’s an architecture where the data never leaves your infrastructure in the first place, regardless of which model you point at it.

This is the case for local-first memory systems like VEKTOR, which stores and retrieves everything through a local SQLite-backed graph rather than a hosted vector database.

We are a PET organization; we protect our users with privacy-enhanced technology. We believe in all human rights to maintain some level of your privacy from not only malicious attackers but also nosey governments and corporations overstepping their boundaries.

The design is zero egress: recall happens on your machine, the embedding step doesn’t require an outbound API call, and the system works whether you’re routing model calls through OpenAI, Anthropic, Mistral, or a local model through Ollama.

The provider question and the data-sovereignty question get decoupled. You can use whichever model serves your users best, American, Chinese, or European, without your memory layer becoming the thing that ships your data offshore.

That distinction matters because model bans are blunt instruments that move slowly and get litigated in public, as this debate shows.

Architecture decisions are something an engineering team controls today, without waiting on Commerce Department rulemaking. A team that wants to reduce genuine exposure to foreign data handling risk, or to any third-party data handling risk, can do it by choosing a local-first LLM system and memory layer now, independent of how the policy fight resolves.

When power and control over AI consolidate into a handful of Silicon Valley companies, that’s an oligopoly, not a security policy.

The alternative isn’t picking a side, open source versus closed, American versus Chinese. It’s keeping the choice open: use whichever model actually serves your users best, and build your architecture so that choice never becomes a liability.

This is what an even distribution playing field actually looks like.

Building AI Memory That Survives Both Attackers and Policy Fights

A maintainer’s phished credentials put malicious code into 2.6 billion weekly downloads within a two-hour window. A geopolitical fight over Chinese open source models is now shaping whether U.S. companies can use the cheapest, most capable AI on the market.

These look like unrelated stories, one a security incident and one a policy debate. They aren’t. Both come down to the same architectural question: what happens to your data between the moment a user says something to your agent and the moment your agent remembers it.

Three properties, not one

Resilient AI memory infrastructure needs to hold up against two different failure modes at once: a compromised dependency reaching for your data, and a policy shift removing a vendor or model you depend on. Three design properties handle both.

Zero egress by default. If a memory system doesn’t need to phone home to function, a policy change banning a vendor, or a breach at that vendor, can’t touch your data.

VEKTOR runs recall and storage on local SQLite, so retrieval happens in around 28ms because it’s a disk lookup, not a network round trip to a cloud service running 200–800ms latency.

There’s no API key to leak, because there’s no API call to make in the first place.

This is also the direct answer to the supply chain problem: an attacker who compromises a third-party embeddings client can only exfiltrate data that’s actually being sent somewhere.

If it isn’t, there’s nothing to steal in transit.

Auditable by design, not by policy. Open source doesn’t automatically mean secure, the npm packages were open source too.

What it means is that when something looks wrong, you can read the code and find out, instead of waiting on a vendor’s incident report.

VEKTOR’s open components, Vex and Vek-Sync, are published on GitHub for exactly this reason.

Auditability doesn’t replace the basic hygiene work security teams did after the npm attack, checking lockfiles, pinning versions, scanning built assets, it makes that hygiene work actually possible, because you’re not blocked by a vendor’s closed retrieval pipeline.

Provider-agnostic, so no single ban or outage is a single point of failure. The model debate is really about which vendor gets to be a chokepoint. A memory architecture that only works with one model provider inherits every risk of that provider, technical and political.

VEKTOR’s design plugs into LangChain, the OpenAI Agents SDK, Claude, Gemini, Groq, and Ollama through the same interface, so a Commerce Department ruling on a specific model, or a vendor going down, doesn’t take your agent’s memory with it.

What this looks like in the real world

VEKTOR’s architecture is a useful concrete reference for these three properties, not because it’s the only way to do this, but because it shows the pieces fitting together.

Raw input, whatever a conversation turn or tool output produces, goes through an AUDN curation step before it’s persisted: each new memory gets evaluated as an ADD, an UPDATE to something existing, a DELETE of a contradiction, or a NO_OP if it’s already known.

That’s the mechanism that keeps a local memory store from just growing forever into an unaudited pile of duplicate data. Reported drift rate is 0.01% per cycle, meaning the graph stays close to accurate over time rather than silently accumulating stale or conflicting entries the way an ungoverned vector store does.

What survives curation lands in a four-layer graph called MAGMA: semantic similarity, causal relationships, temporal sequencing, and named entity co-occurrence. Retrieval uses spec-decoding, a fast bi-encoder shortlist re-ranked by a slower, more precise cross-encoder, so recall stays fast without sacrificing relevance.

On the LongMemEval benchmark, a peer-reviewed test of long-context memory recall, VEKTOR reports 81% adjusted accuracy against a 62% baseline. Idle time gets used too: a background REM compression cycle reportedly collapses roughly 50 raw fragments into a single core insight, cutting storage bloat without deleting the signal.

None of that requires a network call. All of it runs against SQLite, on hardware the user controls.

VEKTOR stores and retrieves memory through a local SQLite-backed graph, so there’s no vector database sitting on the internet for an autonomous agent, human attacker, or a model with a broken jailbreak to chain its way toward.

Zero egress by design means the exposure the Hugging Face incident illustrates, a reachable production data store discovered and exploited by something operating faster than a human could respond, simply isn’t available to attack, because the data never left the machine it lives on in the first place.

The lesson of a 44-day exploit window and a model that found a zero-day on its own isn’t that any single vendor’s classifier needs to be better. It’s that the systems holding your data shouldn’t have a reachable network surface for something faster than you to find.

Removing the network-reachable memory store closes off one path, but any agent that calls out to other MCP servers or tools still has an active attack surface, and that’s where a proxy layer like Faraday fits in.

Our Faraday tools sit between the agent and every connected MCP server, fingerprinting each tool’s schema and flagging the ones that carry credential-like parameters or command-execution hints, the same category of tool that let the ExploitGym incident chain privilege escalation into a production breach.

It also watches for identity drift: a server whose underlying binary changes while its published schema stays identical, the exact stealth rug-pull pattern that let the npm attackers slip a malicious version past anyone only checking package names, not contents.

Canary tokens seeded into the session mean an exfiltration attempt trips a detectable alarm instead of leaving quietly, and high-risk actions can be held for explicit approval before they execute rather than after the damage is done.

None of that replaces removing the target in the first place, but for the tool calls an agent still has to make, it’s the difference between finding out about a compromised or rug-pulled server from a vendor’s postmortem days later, the way Hugging Face and OpenAI did, and catching the attempt in the moment it happens.

The action to take

If your agent stack currently routes memory through a hosted embeddings API and a cloud vector database, that’s the point to interrogate first, regardless of what happens with Chinese model policy or the next supply chain incident.

Ask yourself these questions:

Does this system need to send data off my infrastructure to function?

Can I read the code that decides what gets stored and forgotten?

And am I locked into one model vendor’s cloud services to keep any of my systems working?

If the answer to any of those is yes, that’s the specific risk to fix. The npm attack and the AI policy fight are both proof that the changes have to happen at the architecture level before the next incident makes the decision for you.

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

Cybersecurity
LLM
Cyber Security Awareness
Large Language Models

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

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

I made this generative image with code

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.

You have won; your 15 minutes of fame are granted to you by the algorithm.

Then you are immediately 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.

What if I told you: You are a free marketing employee for a company that doesn't know you exist or pay you? You have to admit that is very weird…

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 Eyephone 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, Ok Mark. Meta 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.

Rizzbot knows the score - Mehahahahaha

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