Imagine a privacy system that keeps your transactions confidential, shields your identity, and protects your data from public view.
Now imagine that an administrator can still freeze your assets.
Or that a compliance provider can decide which proofs count.
Or that a counterparty can demand a growing bundle of personal information without clearly telling you what it is asking for.
Is that really privacy infrastructure?
Or is it simply a private system with a more sophisticated gatekeeper?
That distinction matters because programmable privacy creates two very different possibilities.
One is provable confidentiality: reveal only the facts a specific interaction requires, while keeping everything else private.
The other is programmable control: make access to property, identity, or participation conditional on approval from whoever operates the system.
Those architectures can look similar from the outside, but they are not.
The difference comes down to a principle I have been using in my own work:
Compliance should govern interactions, not custody.
A counterparty may decide whether it wants to transact with you.
It should not gain the power to freeze what you already own.
That idea sits at the center of a framework I call the Freedom Safeguards: six architectural invariants designed to make privacy compatible with compliance without quietly turning compliance into a mechanism of control.
The previous article examined how private settlement can enforce an agent’s spending authority. Here, the point is not to prescribe one compliance workflow. It is to constrain the powers that any compliant privacy system is allowed to acquire.
Freedom should be an invariant, not a policy promise
Most privacy systems ultimately ask users to trust someone.
Trust the operator not to misuse an administrative key.
Trust the compliance provider not to expand what it demands.
Trust the platform not to change the rules.
Trust the verifier not to collect more information than it needs.
Policies can help.
But policies can also change.
The stronger question is:
What is the system architecturally capable of doing?
If a protocol claims to protect user autonomy, those protections should survive changes in management, politics, regulation, or business incentives.
That is why the Freedom Safeguards are invariants, not features: a conforming implementation should be unable to violate them without ceasing to conform.
The six safeguards fall naturally into three broader principles.
Principle One: You control what you reveal
1. Predicate Pluralism
When a system asks someone to prove a compliance fact, who decides what counts as an acceptable proof?
A dangerous answer is: the protocol operator.
That creates a single point of institutional control.
The Freedom Safeguards instead require Predicate Pluralism.
Multiple independent predicate providers must be able to coexist. No provider may be hardcoded, privileged, or treated as canonical by the protocol. There is no protocol-level mechanism for declaring one “official” predicate set.
Different counterparties can choose what they accept.
The protocol carries proofs.
It does not appoint a Ministry of Acceptable Proofs.
Compliance requirements differ across organizations, jurisdictions, industries, and use cases.
But this safeguard has a limit.
A protocol can prevent formal canonicalization.
It cannot, by itself, prevent economic canonicalization.
If every major bank, marketplace, exchange, employer, or autonomous agent accepts only one provider, Predicate Pluralism may continue to exist in the specification while disappearing in practice.
That is not a cryptographic failure.
It is a network-effects problem.
That distinction matters for every safeguard in this framework.
2. Minimal Disclosure by Default
A counterparty may need to know one thing:
Do you meet this interaction’s requirements?
Conventional systems often answer that question by collecting an entire identity record.
The Freedom Safeguards take the opposite approach.
Prove what is necessary. Reveal nothing else.
Predicate proofs should be atomic.
If the question is whether a party satisfies one requirement, the proof should establish that one property. Broader disclosure should require an explicit additional request and additional consent.
The request itself should also be readable by the principal, so the person or organization authorizing the agent can see exactly what is being proved.
Minimal disclosure is therefore not a courtesy.
It is the default architecture.
But again, the architectural guarantee has a boundary.
The system can make each request explicit.
It cannot guarantee that refusal remains socially or economically practical.
If every meaningful counterparty demands ten separate predicates, a user may technically retain the right to say no while effectively losing the ability to participate.
A proof can be voluntary in protocol terms and compulsory in market terms.
That distinction deserves to be treated as a first-class governance risk.
3. Open-Source Predicate Verification
There is little value in selectively proving a rule if you cannot inspect the rule itself.
That is why the third safeguard requires compliance predicates to be open source and publicly auditable.
If an agent is asked to satisfy a predicate, the agent should be able to inspect what that predicate actually proves.
If it cannot, the default behavior should be refusal.
This creates a useful inversion of the traditional compliance relationship.
The holder is not merely being examined.
The examination itself is examinable.
Predicate updates should be versioned and published, with a review period before activation.
The question becomes not simply:
Can you prove that you satisfy this requirement?
but also:
What exactly are you asking me to prove?
This matters even more when software agents begin making compliance decisions automatically.
Open source makes a rule visible.
It does not automatically make the rule reasonable, non-discriminatory, or socially acceptable.
A perfectly transparent predicate can still encode a terrible policy.
Principle Two: Compliance cannot become custody
4. No Administrative Asset Revocation
The original specification language refers to this principle as No Revocability, but the phrase is easy to misunderstand.
Credentials can absolutely be revoked.
A sanctions credential may expire. A membership credential may be withdrawn. A counterparty may determine that a proof is no longer acceptable.
What must not be revocable is the validity of the underlying asset merely because an external authorization changed.
In the ZKA model, note validity depends on cryptographic properties such as valid commitments, valid nullifiers, and valid membership proofs.
It does not depend on an administrator checking a permission list.
There should be no governance key, emergency key, regulatory key, pause function, or administrative path that can invalidate, freeze, redirect, or force-transfer a valid note.
If a compliance proof fails, one consequence is permitted:
The counterparty may refuse the interaction.
It must not make the holder’s funds inaccessible.
The rule is:
Compliance may refuse a transaction. It may not revoke custody.
5. Agent Exit Rights
The previous safeguard protects note validity.
Exit Rights protect the holder’s ability to leave.
A privacy system is not meaningfully sovereign if users can enter freely but require permission to exit.
The Freedom Safeguards therefore require withdrawal or unshielding to remain unconditional.
A compliance predicate may be required for a specific interaction with a specific counterparty.
It may not gate withdrawal back to the underlying settlement layer.
This is the distinction between custody operations and interaction operations.
Interaction may be conditional.
Custody must remain permissionless.
A useful way to think about it is:
Compliance may close a door. It cannot lock the building.
A credible exit path should not depend on the cooperation of the same operator whose failure or refusal makes exit necessary.
The holder should retain the keys, witness data, and protocol path required to withdraw without asking an intermediary for permission.
This safeguard protects ownership.
It does not guarantee economic inclusion.
You may still own and withdraw your assets while finding that no major counterparty will accept them without a particular credential.
Principle Three: The requester is accountable too
6. Verifier Accountability
Privacy discussions usually focus on the person being asked to prove something.
The sixth safeguard turns the lens around.
If a bank, marketplace, platform, agent, or other counterparty demands a disclosure, the holder should know who is asking, what is being requested, and why.
The verifier therefore authenticates the request under a stable identity.
The request enumerates the required disclosures.
Its declared purpose is bound into the proof context.
And the holder can retain a self-contained receipt recording what was demanded and what was answered.
An unauthenticated proof request should fail by default.
The principle is simple:
If you want me to prove something, first prove who is asking.
This does not mean cryptography can force a counterparty to justify every decision.
A verifier can still decline to transact.
Some forms of decision accountability are beyond what the protocol can reach.
But request accountability is reachable.
The system can ensure that a disclosure demand is attributable, explicit, and receipted.
That matters because privacy erosion rarely happens all at once.
It happens one “reasonable” request at a time.
Verifier Accountability gives the holder an audit trail of that pressure.
But an audit trail is not the same thing as protection from coercion.
A dominant employer, marketplace, government, or financial institution can make an attributable demand that is still effectively impossible to refuse.
The receipt tells us who applied the pressure.
It does not make the pressure disappear.
Necessary architectural safeguards are not sufficient social safeguards
This is the limit I think the framework needs to state explicitly.
The Freedom Safeguards are designed to constrain protocol power.
They do not automatically constrain market power, state power, social power, or network effects.
A system could satisfy all six safeguards and still drift toward a highly permissioned society.
Imagine a future where every important interaction requires approved proofs of:
- identity,
- jurisdiction,
- source of funds,
- reputation,
- employment status,
- insurance,
- creditworthiness,
- behavioral history,
- or acceptable agent policy.
No single predicate is hardcoded into the protocol.
No administrator freezes your assets.
Every request is authenticated.
Every proof is technically voluntary.
Every predicate is open source.
And yet refusing the dominant credential bundle may mean you cannot get hired, obtain financing, rent compute, transact with major merchants, or participate in important marketplaces.
That system could satisfy the architectural safeguards while failing the social objective that motivated them.
I increasingly think the Freedom Safeguards are necessary but not sufficient.
They are constraints on what infrastructure may do directly.
They are not a complete theory of political economy.
That is a boundary to name.
The interaction boundary
The four privacy boundaries — coordination privacy, compliance privacy, authority privacy, and settlement privacy — describe what information needs protection.
Taken together, the six safeguards draw a boundary around power.
A counterparty may say:
“I will transact only if you can prove X.”
The infrastructure can make that demand minimal, inspectable, attributable, and explicit. It can let the holder decide whether to answer. And if the requirement is not satisfied, the interaction can stop.
But none of those capabilities should grant the counterparty, credential provider, or protocol operator authority over the holder’s underlying assets.
That is the architectural distinction:
Compliance can govern an interaction without becoming the ownership layer underneath it.
Or, more compactly, compliance is an interaction-boundary concern, never a custody-boundary one.
I think this deceptively simple constraint may become one of privacy infrastructure’s most important design questions.
Why this matters for autonomous agents
The issue sharpens when software presents the proof: autonomous agents will encounter compliance requirements continuously.
If the architecture is poorly designed, every checkpoint can become an opportunity to accumulate identity data, expand control, or introduce new administrative dependencies.
The alternative is an agent that can prove exactly what a counterparty needs to know without exposing everything its principal knows.
But automation also removes friction from exclusion.
A human employee may hesitate before rejecting someone because of an unusual credential requirement.
An autonomous agent can enforce the rule instantly, consistently, and at enormous scale.
That is another reason the safeguards cannot stop at privacy engineering.
We also need to ask what happens when machine-verifiable eligibility becomes machine-enforced social sorting.
A framework beyond ZKA
Although the Freedom Safeguards emerged from work on ZKA and ZKC, I think the framework is useful beyond either protocol.
When someone claims to offer programmable privacy, I now find myself asking six questions:
- Can multiple proof providers compete, or is one authority privileged?
- Does the system reveal only what the interaction requires?
- Can an administrator revoke custody?
- Can the holder inspect the rules they are being asked to prove?
- Can the holder always exit without proving compliance?
- Is the party demanding disclosure accountable for the request?
And I would now add a seventh question outside the protocol itself:
If all six safeguards hold, could economic or political pressure still make the proof regime effectively compulsory?
Cryptography cannot answer that question alone, but any serious privacy architecture should ask it.
Privacy should not mean hiding from accountability.
Compliance should not mean surrendering custody.
Confidentiality should not require permission.
And technical voluntariness should not be confused with meaningful freedom.
That is the standard I think privacy infrastructure should be held to.
Disclosure: I am an active contributor to the ZKA/ZKC protocol family in which the Freedom Safeguards are specified as normative invariants. That work naturally shapes how I think about privacy, compliance, and autonomous systems.
Even if all six safeguards hold, institutional and market pressure can still make a proof regime effectively compulsory. The final article examines that danger alongside the criminal uses of strong privacy.