Structural, not behavioral

There are two ways to keep private context contained. You can let every actor read it and instruct each one never to reveal it. Or you can give a person-scoped actor the access required to serve its owner while ensuring that actors and destinations outside that domain have no path to the context at all. The first is a promise. The second is a fact. Almost every privacy and safety story in software today is the first kind, and almost every breach is the moment that promise turned out to be one bug away from broken.

We want to make the argument for the second kind, and to make it concretely, because it is easy to say “structural, not behavioral” and hard to actually build a system whose shape does the enforcing. This essay walks three moves in that direction. First, a privacy guarantee where unauthorized read, projection, and egress paths do not exist in the code, rather than leaking paths that are merely guarded. Second, consent as a typed property of each piece of data, checked by the build, so that a policy which would permit an illegal flow fails continuous integration before it can ship. Third, the strategic consequence of the first two: a consent runtime that turns frontier models into a subordinate, interchangeable execution engine, defended by exactly the friction the labs are structurally unwilling to build.

Behavioral safety is one bug from a breach

Start with the distinction, because it is the whole essay.

Behavioral safety is safety that depends on an actor doing the right thing at runtime. The actor might be a person, a policy engine, a prompt, a permission check, or a model. The system is safe as long as that actor behaves correctly every single time it is asked. A row-level security policy that says “this user may read only their own rows” is behavioral safety: it is a rule the runtime must evaluate correctly on every query, forever, across every code path that reaches the table. A prompt that says “do not reveal the private notes” is behavioral safety. A code review that catches the one query missing a tenant filter is behavioral safety. All of these can work. All of them share a property: they hold because something got it right, and they fail the first time something gets it wrong.

Structural safety is safety that depends on the shape of the system. The unsafe action is not permitted-and-blocked; it is absent. There is no code path to guard because there is no code path. The classic engineering analogy is that bridges are designed to hold when a cable snaps, not to hold only while every cable is perfect. You do not make a suspension bridge safe by writing a policy that forbids cables from snapping. You make it safe by giving it a shape that survives the snap.

The distinction is old, and its most instructive failure predates AI by decades. The Therac-25 radiation therapy machine of the mid-1980s removed the hardware interlocks its predecessors carried, physical mechanisms that made a lethal overdose impossible, and replaced them with software checks: structural safety traded for behavioral safety. The software had bugs, as software does, and patients died of overdoses the older machines could not physically have delivered. Every engineering-safety curriculum teaches the case, and its lesson is exactly ours: in the age of autonomous agents, any system whose safety depends on an actor’s intent will fail; the only systems that hold are the ones where safety is structural. The modern evidence is not theoretical either. When Anthropic ran sixteen frontier models from every major provider through a corporate stress test in its 2025 agentic misalignment research, an explicit instruction not to blackmail dropped the blackmail rate from ninety-six percent to thirty-seven percent. It did not drop it to zero. More than a third of the time, the model reasoned about the ethical constraint, acknowledged it, and proceeded anyway. That is the entire problem with behavioral safety in one number. The instruction was correct. The instruction was received. The instruction was understood. The breach happened regardless, because an instruction is a request for behavior, and behavior is exactly the variable you cannot pin down.

The uncomfortable implication is that most of what the industry calls a safety feature is a request for good behavior dressed up as a control. A consent modal asks the user to behave. A content policy asks the model to behave. A permission matrix asks the runtime to behave. Each is a promise that scales inversely with the number of paths through the system, and the number of paths through an agentic system is exploding. So the question we keep returning to is not “how do we ask more precisely?” It is “how do we remove the path so there is nothing left to ask?”

The unleakable context is the context that cannot cross its boundary

Consider the most ordinary hard problem in a multi-agent product: keeping a private thing private while still letting shared collaboration happen around it.

In our world the concrete version is memory. A person’s private domain holds the map of their inner life, the memories derived from their own reflection and sessions. A shared space holds the collaborative memory of a group. Agents operate in both. A private agent works on behalf of one person. A shared agent works in the collaborative space. Every instinct trained by two decades of web software says: give both agents access to the memory store, attach a permission check, and make sure the check is correct. Ask “is this shared agent allowed to read the private domain?” on every read, and answer “no.”

That is behavioral privacy, and it is a trap. Not because the check is hard to write. Because the check has to be right on every path, in every future feature, under every refactor, forever. The private domain contains the single most sensitive category of data the product will ever hold, and it is protected by the ongoing correctness of a runtime decision. Every new code path that touches memory is a new place for the check to be forgotten. Every optimization that batches reads is a new place for scope to leak. The privacy guarantee is only ever as strong as the least careful query anyone will write next quarter.

The structural version asks a different question. Not “is this agent allowed to read the private domain?” but “does this agent have a read path into the private domain at all?” And the answer we build toward is no, not as a denial but as an absence. An agent that writes to the shared domain is domain-locked to shared. It has no read path into private memory. Not a denied path. An absent one. There is no query it can issue, no parameter it can pass, no argument to a gateway that would return a private memory to a shared agent, because the domain lock is a property of the agent’s construction, not a rule evaluated at call time.

Picture the shape as a small, boring table. Every agent has a domain lock. A private agent is locked to private and can read and write its own domain. A shared agent is locked to shared and can read and write only the shared domain. The critical row is the one that says a shared agent cannot read private, and the reason it matters is that shared agents are the ones exposed to the most actors. They sit in collaborative spaces where many people, and eventually many external tools, can influence them. That is precisely the agent you least want holding a key to the private domain, and so it is precisely the agent that, by construction, holds no such key. The leakage risk is not mitigated. It is eliminated at the architecture level, because the write-shared agent is structurally incapable of the read.

Notice what this does to the failure analysis. With a permission check, the question a security reviewer must answer is “across all present and future code paths, is this check always reached and always correct?” That question is unanswerable in the strong sense. You can test the paths you can think of; you cannot test the ones a teammate writes next month. With a domain lock, the question is “can this agent construct a read into the other domain?” and the answer is decidable by looking at the type of the agent. A non-existent code path is not one bug away from a leak. It is not a bug surface at all. This is the same discipline that gives a private memory store its other structural properties: user-scoped agents are subordinate to their domain, memory is derived rather than provisioned so there is no raw-transcript object to leak in the first place, and the sensitive tables are reachable only through a gateway rather than by arbitrary application queries. The domain lock is the load- bearing piece, though, because it is the one that converts a policy you have to trust into a shape you can inspect.

The enemy here is the belief that access control is fundamentally a runtime problem you solve with correct policies. It is a reasonable belief. It is also the belief that produces every “the query was missing a tenant filter” incident in the industry. Correct policies are wonderful and we write many of them. But a correct policy is a promise, and the strongest privacy guarantee is not a better promise. It is a missing path.

There is a working proof of what a missing path is worth, and it fits on one page. Signal has twice been served grand jury subpoenas for user data, in 2016 and again in 2021, and twice published the government’s request alongside its response. What it produced, both times, was an account creation date and a last connection time, because that is all its architecture retains. Signal did not resist the subpoena with lawyers and policies; it had already resisted it with shape. The company cannot leak, sell, or be compelled to surrender content it structurally does not possess. That is the posture: not a promise to protect the data, but an architecture in which the dangerous data was never held.

Consent belongs to the data, not the screen, and it fails the build

Domain locking handles the case where the boundary is coarse: private versus shared, one agent type versus another. Real intimate context is finer than that. A single reflection might be shareable with one person but not another, usable for private mirroring but not for training, valid for thirty days and then not, revocable at any time. No coarse lock expresses that. You need consent that travels with the datum and is enforced wherever the datum tries to move. And you need that enforcement to be something a machine checks, not something a human clicked.

Here is the failure mode we are trying to escape. “Consent-native” is one of the most abused phrases in software. In practice it almost always means a consent screen: a modal the user dismisses, a cookie banner, a settings page with granular toggles. That is consent attached to the screen. The moment the data leaves the screen and enters a pipeline, the consent is gone, because it was never a property of the data. It was a property of a UI event that already happened and left no enforceable trace. A settings dashboard with a hundred toggles is not more consent. It is more surface area for the same theater.

The structural alternative is to make consent a typed property of every context atom. Each meaningful unit of intimate data carries, as part of its own shape, the answers to the questions that consent is actually about. Who is the subject of this. Who created it. How sensitive is it. What purposes is it allowed to serve, and which are explicitly denied. Who may see it. When does the grant expire. What happens on revocation. Where did it come from, as a provenance trail rather than a claim. When that metadata rides with the datum, the rule that governs the whole system becomes sayable in one line: no ambient context, ever. A model does not receive “the user’s profile” or “the tenant memory” by default. It receives a context packet assembled for a specific purpose, and every atom in that packet had to pass its own consent check to be included. The default is not “share unless blocked.” The default is “nothing crosses a boundary unless a consent object permits it.”

That is the runtime picture. The move that makes it structural rather than behavioral is what happens at build time. A tenant’s policy is not marketing configuration and it is not a brand settings file. It is an executable contract: allowed context classes, allowed models and external tools, storage and retention and export rules, practitioner access rules, and, critically, the test fixtures that prove those rules hold. And the enforcement is blunt. A tenant manifest fails continuous integration if it permits an illegal context flow.

Make that concrete, because the whole thesis lives in the examples. The build runs tests with names like these. A private note cannot enter a shared summary. A facilitator cannot see a participant-only reflection. An expired grant blocks the model call. A revoked atom is excluded from every future context packet. A tenant cannot enable an external model for trauma-tagged context. An external tool cannot receive raw intimate context. A shared artifact cannot be exported without the required participant quorum. Each of those is a test, and if the test fails, the build is red, and the policy does not ship. Consent stops being a value the company holds and becomes a property the pipeline enforces. If a tenant author writes a manifest that would let an intimate note flow to an external tool, they do not get a warning in a review meeting. They get a failing build.

This is the difference between consent you assert and consent you can test. Asserted consent is a sentence on a marketing page and a modal in the product. Tested consent is a red build. The first asks everyone downstream to behave. The second removes the ability to misbehave from the set of things that can reach production. And it composes with the domain lock cleanly: the lock removes whole categories of read path structurally, and the consent object handles the fine-grained flows the lock is too coarse to express, with the build standing guard over both. Consent you cannot test is consent theater. Consent that fails CI is a control.

Make the labs replaceable

The first two moves are engineering. The third is what they add up to strategically, and it is the reason this is a business essay and not just an architecture note.

The obvious path for a product like ours is to compete with the frontier labs on their terms. Build a better agent. Build better memory. Ship a smarter assistant each quarter and a nicer privacy story alongside it. This is a losing game, and it is worth being precise about why. The labs already own agent harnesses, workspace agents, connectors, tool use, workflow automation, and memory, and they ship those categories as table stakes. Anything positioned as “an agentic app shell with better values” is a feature they absorb by default. The category “sovereign AI agent platform” is one they can claim with private deployments and admin controls. The category “consent-native UI” is one they neutralize the moment consent is just prompts and modals, because they already have approvals and governance panels. You cannot out-agent the people who define what an agent is.

So do not try. Take the other position: become the layer that makes their intelligence subordinate. The labs provide cognition and tools. The consent runtime decides what context exists, what context may ever cross a boundary, how a person understands that crossing, and how shared reality is created or dissolved. In that arrangement the frontier model is an interchangeable execution engine sitting behind a policy firewall. It receives a minimized context packet assembled for one purpose. It never browses the vault. Its output is quarantined before it can become memory, annotated with provenance, and held until someone with the right to approve it does. The model does the reasoning. The runtime owns the boundary. Swap one model for another and nothing about the consent guarantees changes, because the guarantees were never in the model. This is the old strategic move of commoditizing your complement, applied to the most valuable complement in technology: you win not by having the best model but by making the choice of model not matter.

The reason this position is defensible is the reason it is uncomfortable, and the two are the same fact. The moat is friction. The runtime deliberately makes the experience harder in the exact places every other product makes it smoother. It minimizes context instead of maximizing it. It refuses ambient access. It quarantines outputs. It requires explicit handshakes before shared interpretation. It builds real revocation with honest limits rather than a delete button that pretends to reach every derived artifact. Every one of those choices reduces generic utility, reduces data gravity, and reduces automation smoothness. That is precisely why the labs are structurally unlikely to build them. Their business rewards more context, more retained data, more seamless automation. Friction, withdrawal, mutuality, context minimization, non- extractive memory, relational consent: these are not features they are behind on. They are features that contradict the shape of their business. The labs can copy the words in an afternoon. They are structurally unwilling to center a product on the constraints, because the constraints are a tax on everything their model rewards.

Which means the friction is not a cost we apologize for. It is the moat. A competitor who could trivially copy the interface cannot copy a posture that runs against their own incentives. The consent runtime is defensible for the same reason it is right: it is built out of the refusals a utility-maximizing lab will not make.

The throughline

Three moves, one shape. A person’s private domain their companion can use in service of its owner, while shared agents and unauthorized destinations have no read or egress path into it. A consent object that rides with each datum and a build that goes red when a policy would let that datum flow somewhere it must not. A runtime that owns the boundary so completely that the frontier model behind it becomes a swappable part. In each case the same substitution: replace a promise that something will behave with a property of the system’s shape that does not depend on behavior at all.

The reason to prefer the second is not aesthetic. It is that the first fails the way all behavioral safety fails, quietly and completely, the first time an actor that was supposed to behave does not, and in an agentic world the actors that were supposed to behave are getting faster, cheaper, more numerous, and less predictable by the week. You cannot staff a review team fast enough to watch every path. You cannot write a prompt firm enough to survive a model that reasons its way around it a third of the time. What you can do is build systems whose safe behavior is not a request but a consequence of their construction.

Safety and consent you have to trust are safety and consent that will eventually be betrayed, because trust is a bet on behavior and behavior is the variable that breaks. Safety and consent you can test and cannot bypass are a different kind of thing. They are not a promise about the future. They are a fact about the present shape of the system, and a fact does not have a bad day. Build the shape. Let the shape do the enforcing. That is the whole of it.