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, that a compliance provider decides which proofs count, or that a counterparty can demand a growing bundle of personal information without clearly saying what it is asking for. Is that privacy infrastructure, or a private system with a more sophisticated gatekeeper?

The question matters because programmable privacy makes two very different architectures possible. One is provable confidentiality: reveal only the facts a specific interaction requires, and keep everything else private. The other is programmable control: make access to property, identity, or participation conditional on approval from whoever operates the system. From the outside, the two can look alike.

What separates them is 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. This one sets limits on the powers any compliant privacy system is allowed to acquire, whatever compliance workflow it uses.

Freedom should be an invariant, not a policy promise

Most privacy systems ultimately ask users to trust someone: the operator not to misuse an administrative key, the compliance provider not to expand what it demands, the platform not to change the rules, the verifier not to collect more than it needs. Policies can help, but policies can 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 rather than features: a conforming implementation should be unable to violate them without ceasing to conform. The six safeguards fall 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? The dangerous answer is the protocol operator, because 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, and there is no protocol-level mechanism for declaring one “official” predicate set. Compliance requirements differ across organizations, jurisdictions, industries, and use cases, so different counterparties can choose what they accept. The protocol carries proofs. It does not appoint a Ministry of Acceptable Proofs.

This safeguard has a limit. A protocol can prevent formal canonicalization, but it cannot, by itself, prevent economic canonicalization. If every major bank, marketplace, exchange, employer, or autonomous agent accepts only one provider, Predicate Pluralism may survive in the specification while disappearing in practice. That would be a network-effects problem rather than a cryptographic failure, and the same distinction applies to every safeguard in this framework.

2. Minimal Disclosure by Default

A counterparty may need to know only 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, and broader disclosure should require an explicit additional request and additional consent. The request itself should be readable by the principal, so the person or organization authorizing the agent can see exactly what is being proved. Minimal disclosure is the default architecture, not a courtesy.

Again, the architectural guarantee has a boundary. The system can make each request explicit, but it cannot guarantee that refusal remains socially or economically practical. If every meaningful counterparty demands ten separate predicates, a user may keep the right to say no while losing the ability to participate. A proof can be voluntary in protocol terms and compulsory in market terms, and that 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. The third safeguard therefore requires compliance predicates to be open source and publicly auditable. An agent asked to satisfy a predicate should be able to inspect what that predicate actually proves, and if it cannot, the default behavior should be refusal. Predicate updates should be versioned and published, with a review period before activation.

This inverts the traditional compliance relationship. The holder is not merely being examined:

The examination itself is examinable.

The question becomes not simply:

Can you prove that you satisfy this requirement?

but also:

What exactly are you asking me to prove?

That matters even more once software agents make compliance decisions automatically. Still, open source makes a rule visible; it does not 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 calls this principle 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, and a counterparty may decide 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, not 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, the only permitted consequence is that the counterparty may refuse the interaction. It must not make the holder’s funds inaccessible.

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 need permission to exit, so the Freedom Safeguards require withdrawal or unshielding to remain unconditional.

A compliance predicate may be required for a specific interaction with a specific counterparty, but it may not gate withdrawal back to the underlying settlement layer. This is the distinction between interaction operations, which may be conditional, and custody operations, which must remain permissionless.

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, not 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.

If you want me to prove something, first prove who is asking.

Cryptography cannot force a counterparty to justify every decision. A verifier can still decline to transact, and some forms of decision accountability are beyond what the protocol can reach. 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, and Verifier Accountability gives the holder an audit trail of that pressure.

An audit trail is not protection from coercion, though. 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, and a system could satisfy all six safeguards while drifting 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, and 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. So I increasingly think the Freedom Safeguards are necessary but not sufficient. They constrain what infrastructure may do directly. They are not a complete theory of political economy, and that boundary is worth naming.

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.

Compliance can govern an interaction without becoming the ownership layer underneath it.

Put 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, because 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:

  1. Can multiple proof providers compete, or is one authority privileged?
  2. Does the system reveal only what the interaction requires?
  3. Can the holder inspect the rules they are being asked to prove?
  4. Can an administrator revoke custody?
  5. Can the holder always exit without proving compliance?
  6. 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.