There was a time when managing a network of Unix machines meant managing user credentials on every machine.
Accounts were created, passwords were changed, and users were removed one system at a time. Whether credentials were maintained in /etc/passwd, /etc/shadow, or some other operating system’s equivalent, the underlying problem was the same.
Every machine maintained its own understanding of who was allowed to access it.
If you managed enough machines, keeping everything synchronized could become a full-time job. It wasn’t just an administrative headache. Every additional system managing credentials was another place where something could go wrong.
Operating system vendors recognized this wasn’t going to scale and developed their own solutions for centralizing user and credential management.
Over time, directory services, Kerberos, and eventually federated Single Sign-On changed the architecture. Today, standards allow us to authenticate users across different operating systems, applications, organizations, and administrative domains without every service maintaining its own collection of passwords.
We didn’t eliminate authentication. We changed where it happened and how systems participated in it.
More importantly, we changed what information an application needed to possess to do its job.
An application didn’t necessarily need your password anymore. It needed a trustworthy way to establish that you had authenticated.
That was an enormous architectural improvement.
I wonder if we’re ready to make a similar change for everything else.
We’ve Seen This Movie Before
Think about how much information we distribute across the internet.
Every service wants our name, address, date of birth, financial information, employment history, preferences, and increasingly our behavioral history.
We upload tax returns to verify income. We provide medical records to establish eligibility for services. We share calendars so someone can schedule an appointment. We connect entire email accounts so an application can find a handful of reservations.
Each service collects another copy of our information, builds another database, and assumes responsibility for protecting it.
And each one becomes another opportunity for that information to escape.
We’ve essentially recreated the old credential-management problem, except this time it’s not just passwords. It’s practically everything we know about ourselves.
We’ve gotten very good at protecting these databases. We encrypt them, monitor them, audit them, and surround them with increasingly sophisticated security controls.
But I think we’re overlooking a more fundamental question.
Why do these services need to possess so much of our information in the first place?
Consider a bank that needs to establish whether your income exceeds some threshold.
Today, you might be asked to upload pay stubs, employment records, or tax returns. The bank now has sensitive information it needs to store, protect, manage, and eventually delete.
But for that particular decision, the bank may only need to know whether you satisfy the income requirement.
It doesn’t necessarily need your entire financial history.
What if the bank could request a verifiable answer rather than your underlying records?
What if a trusted computation could evaluate your information where it already resides and produce an authorized result?
The bank gets what it needs. You retain custody of the underlying information. And we haven’t created another database full of personal details waiting for someone to steal them.
We’ve already established that something resembling this is possible with identity.
Why stop there?
Zero Possession
Zero Trust challenged one of the fundamental assumptions of network security. Being inside the network shouldn’t automatically make someone trustworthy.
It changed the way we thought about boundaries, identity, and authorization.
I think we need a similar change in how we think about software and information.
I’m calling it Zero Possession.
The central idea is that software should be able to accomplish useful work without automatically acquiring custody of the information it operates on.
A service should request the specific result it needs, not an unrestricted copy of the information required to produce that result.
This doesn’t mean information can never be shared. Sometimes transferring information is the purpose of a transaction. Nor does it mean everyone has to operate their own data center. Individuals and organizations could delegate custody to trusted providers, just as they delegate identity management today.
What matters is that custody, computation, and disclosure become separate architectural concerns.
Imagine a service requesting proof that you’re eligible for something. Rather than providing all the supporting documents, an authorized function executes within the environment governing those documents.
The function evaluates the necessary information, produces a result that the recipient can verify, and disappears.
The requesting service receives the artifact, not the underlying corpus.
This is where the rapidly falling cost of software creation becomes interesting.
Historically, building a piece of software was expensive. Developers had to anticipate what people might need, create the functionality, distribute it, and maintain it.
Agentic AI is changing those economics.
We’re approaching a world where software can be created for a specific purpose, used briefly, and discarded. A tiny function that exists for thirty seconds might be perfectly reasonable if generating it costs almost nothing.
But imagine pairing that capability with information that remains under the control of its owner.
Instead of moving information to applications, we could increasingly move computation to information.
The function becomes temporary. The information remains governed. Only the authorized result crosses the boundary.
That seems like a very different way to build software.
Organizationally Closed, Informationally Open
There’s a concept from biology that I think helps explain what we’re trying to accomplish.
Humberto Maturana and Francisco Varela explored how living systems maintain their own organization while continuously interacting with their environments. One important idea is organizational closure.
A living organism isn’t isolated from the world. It exchanges energy, matter, and information with its surroundings. But those interactions don’t mean the environment takes over the organism’s internal organization.
Consider a cell.
Its membrane isn’t simply a wall designed to keep everything out. It is part of a system that regulates interactions with the environment while preserving the organization necessary for the cell to function.
I find that a useful way to think about information systems.
Organizationally closed, but informationally open.
An organization should be able to participate in a rich information ecosystem without surrendering control of its internal information.
A hospital could establish that a patient satisfies a particular eligibility requirement without distributing the patient’s entire medical history.
A business could demonstrate compliance with a contractual requirement without exposing its internal financial records.
An individual could authorize an agent to coordinate activities across several services without giving any one service permanent access to every aspect of their digital life.
The goal isn’t to eliminate boundaries. It’s to make those boundaries more useful.
We don’t need every application to know everything. We need systems capable of exchanging precisely what is necessary to accomplish an authorized purpose.
We’ve spent decades making information available by copying it into more places.
Perhaps it’s time to become better at making information useful without moving it.
The Problem With What We’ve Already Seen
This becomes especially important with AI.
There’s an old observation that what has been seen cannot be unseen.
That’s a pretty good description of the information problem we’re creating with increasingly capable AI agents.
Once information enters an external AI system, we may lose practical control over what happens next. It may remain in a conversation context, be included in logs, passed to another tool, or influence an output that gets stored somewhere else.
That doesn’t necessarily mean the model permanently learns everything it encounters. But revoking access after the fact cannot reliably undo everything that happened while access existed.
And the more useful we want these agents to become, the more information we tend to give them.
Want an agent to organize your travel? Give it email and calendar access.
Want it to help manage your finances? Connect your accounts.
Want it to coordinate work across your organization? Give it access to documents, conversations, projects, and internal systems.
We’re building increasingly capable intelligence and then encouraging it to ingest as much information as possible.
I’m not convinced that’s the right direction.
Under Zero Possession, an agent wouldn’t necessarily need to examine all that underlying information. It could request particular computations or authorized artifacts from the environments responsible for governing the data.
Instead of asking an agent to read every calendar entry to find a meeting time, a scheduling service could return suitable availability.
Instead of letting an agent browse every financial transaction, a governed function could answer a specific question about spending.
The important distinction is between what the agent needs to accomplish and what it needs to know.
Those are often very different things.
Of course, this doesn’t make the problem disappear. Even a yes-or-no answer can disclose sensitive information. Repeated questions can reveal details never intended to be shared.
And a dynamically generated function isn’t inherently trustworthy just because it’s temporary.
A real Zero Possession environment would need to control which computations can execute, what information they can access, and what results they are permitted to disclose.
The agent shouldn’t get to decide its own permissions. Neither should the ephemeral function.
That’s the responsibility of the security architecture.
There are difficult engineering problems to solve, but I think the starting point is recognizing that we may have been asking the wrong question.
Rather than asking how to safely give an agent all our information, perhaps we should ask how little information the agent actually needs to receive.
The Value Is in the Artifact
Today, we often treat information as a collection of documents, records, and databases. But what another party needs may actually be a property of that information.
A document has metadata. A financial history can support a derived claim. A collection of records can establish eligibility. A workflow can produce an artifact that another system needs to continue its work.
We could make those properties explicit, a process sometimes described as reification, and exchange the resulting artifacts rather than the underlying records.
But we’d need to know more than simply what the artifact says.
Where did it come from? What information contributed to it? Was the computation trustworthy? Was the disclosure authorized? Can the recipient verify the result without receiving the source material?
Provenance becomes essential.
So does the distinction between data, metadata, and behavioral data.
Metadata can be sensitive. Behavioral patterns can reveal things that aren’t obvious from any individual transaction. And a small derived artifact can sometimes disclose more than its size would suggest.
Zero Possession isn’t about exchanging fewer bytes.
It’s about exchanging only the information necessary for an authorized purpose.
This is where security policy becomes much more interesting than the familiar question of whether an application has permission to read a database.
The question becomes what the application is authorized to learn, prove, change, or disclose.
That’s a much richer security model.
A Different Kind of Internet
Think about the enormous amount of effort we spend protecting information that organizations may never have needed to collect.
We build databases of personal information and then spend years worrying about how to secure them.
We establish retention schedules, build deletion workflows, implement access controls, monitor privileged users, conduct audits, and prepare for the possibility of a breach.
Regulations like GDPR attempt to address these problems through principles such as data minimization, purpose limitation, and restrictions on retention.
Those are reasonable objectives.
But what if we could satisfy much more of their intent through architecture rather than relying on every organization to independently manage another mountain of personal information?
An organization that never receives your tax returns doesn’t have to protect its copy of them.
A service that receives a narrowly scoped eligibility claim rather than a detailed medical history has far less information to expose in a breach.
A company that doesn’t retain years of unnecessary personal records has less sensitive data to manage, secure, and eventually delete.
This wouldn’t eliminate privacy regulation or compliance obligations. The results of computations may still contain personal information, and organizations still have responsibilities for how they use it.
Nor would it eliminate the need to trust custodians. Concentrating information in a governed environment creates its own security challenges.
But it could dramatically change the amount of information distributed throughout the economy.
And that means fewer opportunities for information to be stolen, misused, or retained long after anyone remembers why it was collected.
There’s also a compelling economic argument here.
Every company wouldn’t need to become a sophisticated operator of sensitive personal databases simply to deliver a relatively simple service.
Security becomes a shared architectural capability rather than something every new application must independently reinvent.
That’s not just a benefit for users.
It’s potentially a better way to build businesses.
Cybersecurity as an Enabler
I’ve long believed that security is at its best when it makes things possible. You have heard this before, but it is worth repeating.
When engineers design a bridge, structural engineering isn’t there to prevent people from crossing the river. It’s what allows them to cross safely.
Cybersecurity plays the same role in computing.
Imagine a world where software can be generated almost on demand, where services cooperate across organizational boundaries, and where useful information can be exchanged without continually surrendering the underlying records.
A world where applications don’t automatically become permanent custodians of everything they touch.
Where a function can exist for a few moments, produce something valuable, and disappear.
Where individuals and organizations maintain control over their information while participating in an increasingly connected ecosystem.
That is what I mean by organizationally closed but informationally open.
It isn’t a world without trust, without data sharing, or without security boundaries.
It’s a world where we become far more deliberate about what crosses those boundaries.
I’m not suggesting Zero Possession is already a solved architecture. Some of the underlying technologies exist today, and others will need substantial work. Verifiable credentials, constrained execution, cryptographic proofs, information-flow controls, and federated systems all provide pieces of the puzzle.
But architectural changes begin when we challenge an assumption that everyone has stopped questioning.
Zero Trust asked why being inside a network should make something trustworthy.
Zero Possession asks why using information should require taking possession of it.
We solved a version of this problem when we stopped expecting every application to maintain its own password database.
Perhaps it’s time to solve the much larger version.
Because the most interesting future of AI isn’t one where every service knows everything about us.
It’s one where software can do far more for us while needing to know far less about us.
