I have worked in data security for many years.
What I've done all these years can be summed up in one sentence: watch the customer's data, and don't let anything happen to it. Classification and grading, access control, perimeter defense, audit logs, nothing leaving the jurisdiction, nothing landing on an external network.
But recently I've realized that the thing I've been guarding may no longer be the most valuable thing there is.
This is the second article of Part II. The previous one was about who owns the thinking process — that was from the angle of power. This one is about this: when the object being protected changes shape, the meaning of security changes with it.
1. What we have been guarding
Let's set out the old approach first.
Old security guards what has been stored. The core questions are just a few:
Does this database hold ID numbers, phone numbers, passwords?
Does it hold design drawings, customer lists, financial records?
Who has access? Is it encrypted? Can it be dumped?
Can it leave the country?
The corresponding actions are mature too: classification and grading, access control, perimeter defense, audit logs, data that doesn't leave the jurisdiction.
In one sentence: where the data sits, who can touch it, and whether it is sensitive.
None of this is obsolete. It is still useful today. The problem is that it only answers "static" questions.
2. The shape of the danger has changed
After AI arrived, the genuinely dangerous things became something else.
Which of these is "the table in the database"?
The requirements, context, and debugging thinking you described to an AI.
The architectural details you let slip when you asked "why is our system designed this way?"
The "who fears whom, who decides, who's coasting" that the AI summarized after you had it go through meeting minutes.
The call chain left behind when an agent calls tools, reads files, sends requests, hits APIs.
The context window the model assembles on the fly during inference.
These share one property: they are not necessarily stored long-term, but they have already given the secret away while in use.
And they reconstruct the truth better than a customer table does.
A customer table tells you which customers this company has. A debugging conversation tells you how this company's system is built, where it is stuck, and where it intends to go next.
The former is an asset. The latter is intent.
3. The five "in"s
Data security has used a three-way split for years: at rest, in transit, in use. The first two are old battlefields, long since settled. The third was always the hardest, until confidential computing provided an answer.
I want to add two layers on top of that.
Inference-time security — the segment where data enters the model's context window and is processed on someone else's GPU memory. The more common industry term is "privacy-preserving inference," and the techniques are confidential computing and trusted execution environments.
Call-chain security — an agent calling tools, reading files, and sending requests in sequence, where every individual action is legitimate and the whole chain reconstructs the entire business. In OWASP's Top 10 for agentic applications, this is ASI02, "Tool Misuse." In MITRE's adversarial tactics knowledge base it is AML.T0086. The industry calls this compositional pattern tool call chaining.
So the full chain looks like this — the first three layers are the standard division; the last two are mine:
data at rest → data in transit → data in use → inference-time security → call-chain security
The questions on this new battlefield look like this:
What was in the context when this request went out?
While the model was doing inference, whose GPU memory was our data in?
The third tool the agent called — which file did it read?
Put that whole call chain together — does it add up to handing over our business logic?
That last question is not hypothetical. A study in August 2026 recovered 704 credentials from 6,708 public agent traces on GitHub and Hugging Face — 62 API keys, 33 passwords, 24 access tokens, 7 private keys. And 64 of them never appeared in any visible conversation record. Conventional conversation redaction cannot remove them.
Every individual action looks harmless. Assemble the whole chain and it is a complete reconstruction of the business.
And the object being governed is growing a layer too:
What used to be governed was databases, files, servers — things you can see, touch, and assign an owner to.
What is governed now is compute flows, context flows, the right to train, the right to deploy — things you can see but cannot hold, things that have a direction but no owner.
That growth drags players onto the table who were never at it. Nvidia sells "the engine of compute," but once an engine becomes strategic infrastructure, it gets re-examined under the logic of sovereignty. The underlying infrastructure is being hollowed out by "process information."
That is where the irony from the previous article has its root: you supply the hardest resource, but what decides who holds power is the stream that flows through your hands and that you cannot see.
4. Governance is turning too
It is not only the rhetoric. The point of leverage in the rules is shifting.
From "whoever stores the data is responsible" to "whoever is calling, inferring, and lending out capability is responsible."
From "notice and consent" to "observable, traceable, revocable, auditable across the whole process."
From "encrypt the data and lock it up" to confidential computing, trusted execution environments, local inference, zero data retention.
Behind all three sentences is one thing: the point of protection has moved earlier, from after storage to the moment of use.
It used to be accountability after the fact. Now it is compliance at runtime.
5. Put it in a programmer's terms
If it has to be one line:
What we used to defend against was a file being copied out.
What we defend against now is context being fed away, inference being borrowed, and intent being learned.
The first is a file-system problem. The second is a cognitive problem.
And for a cognitive problem, there is no "encrypt" option — you cannot encrypt a piece of context and then feed it to a model, because the entire point of feeding it in is to have it understood.
This is the first time data security has faced an object that has to be handed over in order to be used.
6. The ledger sits exactly on that seam
Writing this, I looked back at what I've been building.
What does ai-tracedoc guard?
Not the static assets in a database — the dynamic flow of one person's thinking process.
What it records is your questions and answers with the AI: how a requirement was broken apart step by step, how a plan was torn down and rebuilt, how a problem finally converged. Business logic, system architecture, customer information, technical roadmaps may all be mixed into that.
But when it is written down, it exists in the form of a "thinking process" — an asset form that did not exist before, and therefore was never brought inside any scope of protection.
In the old security system, no cell was ever prepared for it.
7. What this means for people who do security
My industry has one characteristic: the demand is always there; the answer keeps changing.
Ten years ago customers needed firewalls and antivirus. Five years ago they needed data-loss prevention and compliance auditing. Now they need conversation auditing and inference-process protection. Three years from now they will want something else.
That is what makes it hard for vendors: the technology iterates too fast, customers cannot articulate what they want, and by the time you've built the product the wave may already have passed.
But looked at from the other side, this is exactly the opening for small companies. Large vendors have bulk and turn slowly, with a product line feeding hundreds of people, and they dare not bet on a new direction. A small company turns on a dime, and can try and iterate fast.
As for entry points, I see at least a few:
Enterprise process-information recording — record employees' conversations with AI inside the enterprise's own environment, with ownership belonging to the enterprise and never passing through the model vendor.
Meeting process-information management — in finance, healthcare, and government, meeting content needs to be recorded and audited without leaking, and the decision trail inside a meeting is itself the company's most valuable dynamic knowledge.
An internal AI gateway — every AI request passes through it first, for redaction, auditing, permission control, and local caching of common questions; only redacted requests go out to external services, and all process information stays inside.
Or, be the person who explains all this clearly first. That has the lowest barrier to entry, and not many people are saying it yet.
8. The old and the new
Back to the sentence.
Old security guards the vault. New security guards the stream.
Old sovereignty fights over where data is stored. New sovereignty fights over where thinking happens.
The four layers of sovereignty from the previous article repeat the same sentence at four scales — individual, company, nation, infrastructure. What this article wants to say is that the "thing" in that sentence has already changed from a static asset into a flowing process.
And a stream cannot be locked.
There is only one thing to do — before it flows, say clearly who it belongs to.
This is the second article of The AI Thought Quartet, Part II: Sovereignty and Practice, and the close of the Sovereignty half. The Practice half turns a different direction: now that process information exists, what do I do with it.
Top comments (0)