Most compliance systems begin with a familiar assumption: to prove something about yourself, hand over the underlying data.

A bank needs to know you passed KYC?

Send your identity documents.

A platform needs to know you are in an allowed jurisdiction?

Send your address.

A counterparty needs to know you are not sanctioned?

Reveal enough identity information for them to screen you.

That model works, but it also exposes far more data than necessary.

The result is a strange bargain:

To prove that you satisfy one requirement, you often reveal everything needed to evaluate many others.

I keep asking:

Can we satisfy legitimate compliance requirements without turning compliance itself into a surveillance system?

That is compliance privacy: proving that the parties satisfy a specific interaction’s regulatory or organizational requirements while limiting disclosure to the facts that interaction requires.

Zero-knowledge proofs give us a credible path, but only if we are disciplined about what the system is allowed to ask for.

The previous article asked how an agent proves it is authorized to act. This one asks how parties prove that they meet an interaction’s requirements without disclosing more than it needs.

Prove the fact, not the file

Suppose a counterparty needs to know only one thing:

Are you currently outside the applicable sanctions list?

The conventional approach may require learning who you are in order to perform the check.

A zero-knowledge approach can instead prove the result of the check.

The counterparty learns:

sanctions requirement satisfied

without necessarily learning your legal name, date of birth, home address, passport number, or the rest of your KYC file.

The same model can apply to other compliance facts.

You might prove:

  • that you completed an acceptable KYC process,
  • that you are resident in an allowed jurisdiction,
  • that your funds were reviewed as coming from an acceptable source,
  • that you meet an accreditation requirement,
  • or that a tax-related predicate is satisfied.

The principle is simple:

Prove what the interaction requires. Reveal nothing else.

That is not the same as anonymity.

It is selective accountability.

Atomic predicates matter

Selective disclosure can fail even when the cryptography is excellent.

Suppose a counterparty really needs only sanctions clearance.

A compliance provider could offer a single “compliant person” proof that silently bundles:

  • KYC status,
  • jurisdiction,
  • tax residency,
  • source of funds,
  • accreditation,
  • sanctions status,
  • and several other attributes.

Very little raw data may be revealed.

But the holder has still lost control over what is being proved.

That is why minimal disclosure needs to be structural.

A proof should ideally establish one predicate.

If a verifier needs five predicates, it should ask for five.

The principal should be able to see exactly what each one means before deciding whether to provide it.

The system is no longer asking, “Are you compliant?” It is asking:

“Can you prove these specific facts for this specific purpose?”

That difference matters because broad compliance bundles tend to grow.

One reasonable request becomes three.

Three become ten.

Eventually the privacy system can reproduce the same all-or-nothing identity regime it was meant to replace, only with cleaner cryptography.

The verifier should have to identify itself too

Most compliance architecture focuses entirely on the person being examined.

Who are you?

Where do you live?

What credentials do you have?

But there is another party: the entity demanding the disclosure.

Why should that side be anonymous?

If a bank, marketplace, AI agent, exchange, employer, or other counterparty wants a cryptographic proof, the holder should know:

  • who is asking,
  • what they are asking for,
  • why they say they need it,
  • and which proof policy they expect to apply.

That is the idea behind an Authenticated Proof Request.

The verifier signs the request under a stable identity.

The request enumerates the predicates.

The declared purpose can be bound into the proof context.

And the holder retains a receipt of what was demanded and what was answered.

The principle becomes:

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

Cryptography cannot force a company to make every commercial judgment fair or explain every rejection.

But it can make the request attributable.

Purpose matters

Imagine providing identity information to a service for billing.

Later, the same company uses it to determine whether you qualify for a different product.

Technically, the data was already available.

But the purpose changed.

Traditional systems rely heavily on policy and law to govern that reuse.

A purpose-bound proof can make the distinction cryptographically visible.

The request says what the evidence is for.

The proof is generated for that context.

A proof produced for one purpose should not silently replay into another.

This cannot stop an organization from misusing plaintext it already holds; no cryptographic system can erase someone’s memory.

But it can prevent the proof itself from becoming a reusable credential blob detached from the context in which it was requested.

The goal is not perfect enforcement, but reducing invisible power.

When a proof fails

A compliance interaction also needs a clear rule for failure.

A credential may be revoked. A verifier may stop accepting an issuer. A sanctions-screening result may be stale. Or the holder may simply decline to provide the requested evidence.

In any of those cases, the verifier can refuse the transaction or relationship.

What should not follow automatically is a new power to seize, freeze, redirect, or invalidate assets the holder already owns.

For the interaction itself, the rule is straightforward:

A failed proof may close the interaction. It should not rewrite ownership.

The Freedom Safeguards framework addresses how to make that boundary durable across the whole system.

Autonomous agents make this problem much larger

Humans may encounter a compliance request a few times a year.

Autonomous agents could encounter them constantly.

Imagine software agents negotiating with suppliers, buying compute, opening commercial relationships, paying other agents, or interacting with regulated financial systems.

If every interaction requires a full identity disclosure, the machine economy becomes a gigantic identity replication engine.

Agents will spray credentials across counterparties at machine speed.

That is exactly the wrong direction.

Instead, an agent should be able to answer narrow questions programmatically:

Do you satisfy this interaction’s jurisdiction requirement?

Have you passed the required sanctions screen?

Do you hold acceptable KYC?

Is this source of funds acceptable under my policy?

And the agent should be able to answer those questions without disclosing the rest of its principal’s identity dossier.

Zero-knowledge compliance is therefore more than a privacy feature; it is a scalability feature.

The proof still has to belong to the actor

There is an obvious attack on any compliance-proof system.

Borrow someone else’s proof.

If Alice has excellent KYC and Bob does not, Bob should not be able to attach Alice’s compliance proof to his transaction.

The system therefore sometimes needs to prove that:

the subject satisfying the compliance requirement is the same subject controlling the relevant action.

Within the protocol family I am working on, that binding can occur at different layers depending on the interaction.

The mechanism varies, but the principle does not:

A valid proof from the wrong person is not a valid compliance result.

There is an important limit to the argument.

Some regulated interactions may require an institution to actually obtain and retain identifying information.

Certain rules may require originator or beneficiary information.

A bank may need records that can later be produced under lawful process.

A ZK proof should not be marketed as satisfying an obligation that legally requires the verifier to possess the underlying data.

But even there, the architectural discipline still helps.

If plaintext information must be disclosed, the request can still be authenticated, purpose-bound, minimized, delivered only to the counterparty, and receipted.

The objective is not:

Never disclose anything.

It is:

Disclose deliberately, to the party entitled to receive it, for a defined reason.

The question ahead

Privacy debates often collapse into two positions:

“Everything should be transparent so bad actors can be detected.”

or:

“Everything should be private so nobody can interfere.”

Neither is a particularly satisfying foundation for enterprise systems.

Legitimate commerce needs privacy.

Legitimate institutions also need compliance.

The interesting question is whether we can provide both without building one giant database of everyone’s identity and financial behavior.

I think the better model is:

Prove the requirement.
Authenticate the requester.
Bind the purpose.
Reveal the minimum.
Preserve evidence where it belongs.
And keep compliance out of custody.

That leaves a question for compliance, privacy, and enterprise architecture:

If a counterparty only needs to know that you satisfy a rule, why should it automatically be entitled to all of the data used to prove it?

Disclosure: I am an active contributor to the ZKC/ZKA/ZKM/AFP protocol family discussed here. ZKC remains draft-stage protocol work, and the architecture described above should be evaluated as a proposal rather than a claim that zero-knowledge proofs eliminate legal, operational, or regulatory obligations.

With private authority and compliance in view, the next article turns to settlement: how to move value confidentially while consuming delegated authority in the same transition.