Reading Trust Claims

Why these get conflated

Some cynicism is warranted here, but not much. Mostly this is structural.

Confidentiality is easy to sell. "Encrypted" is a word buyers recognise. "Attenuated capability delegation with per-transaction caps" is not.

Some properties have no visible benefit until failure. Accountability produces nothing until an incident. Hard to feature on a landing page.

The vocabulary genuinely overlaps. "Secure" reasonably describes at least four of the seven. Using it is not lying; it is just uninformative.

Buyers reward the conflation. Procurement checklists ask "is data encrypted?" far more often than "who is answerable when the agent acts incorrectly?"

The practical skill is not detecting deception. It is asking better questions.

When a vendor says "trusted," respond with: which of these seven, and by what mechanism?

A good engineer on their side is usually relieved to be asked. That reaction — relief rather than defensiveness — is one of the more reliable signals about whether a vendor knows what they are doing.

Private, confidential, anonymous

Three words used interchangeably, meaning three different things.

Confidential — the contents cannot be read by unauthorized parties. Encryption provides this.

Private — information about a person cannot be inferred, even from data you are allowed to see. A dataset can be fully confidential and still leak private facts through aggregate statistics, because inference does not require reading the record.

Anonymous — the data cannot be linked back to an individual at all.

The relationship is one-directional: confidential does not imply private, and private does not imply anonymous.

Encryption gives you the first, not the second. And anonymity has a long history of failing under linkage attacks against data confidently declared anonymous — the 2006 de-anonymization of the Netflix Prize dataset by Narayanan and Shmatikov is the canonical example.

When someone says "private," find out which of the three they mean.

A map of mechanisms to properties

| Mechanism | Primary property | Notably does not provide | | --- | --- | --- | | TLS / encryption at rest | Confidentiality in transit, at rest | Anything about the host, or about actions | | Hardware enclave | Confidentiality + integrity | Authorization, accountability | | Zero-knowledge proof of inference | Integrity | Confidentiality from the prover | | Optimistic verification | Integrity (economic) | Confidentiality — inputs may surface in a dispute | | Differential privacy | Privacy of individuals in a dataset | Confidentiality of the dataset itself | | Capability tokens | Authorization | Confidentiality, integrity | | Digital signatures | Authenticity, identity, non-repudiation | Correctness of what was signed | | Content provenance manifests | Provenance | Truthfulness of the content | | Tamper-evident logs | Accountability | Prevention of anything | | Reputation registries | Reputation | Any guarantee about the next interaction |

Look at the right-hand column. Every one of these mechanisms is sound. Every one is routinely deployed in the belief that it provides something it does not.

Working through real claims

"All customer data is encrypted with AES-256."

Claimed: confidentiality at rest. If the concern is a stolen disk, appropriate. If the concern is the agent revealing data to the wrong user, irrelevant — the data will be decrypted and handed over correctly, to the wrong person. Needed: authorization.

"Our inference runs in a secure enclave, so your prompts are never exposed."

Claimed: confidentiality against the host. Says nothing about whether the correct model ran, or what the agent may do with the answer. Needed additionally: integrity, authorization.

"Every agent action is logged for full auditability."

Claimed: accountability. Whether it delivers depends on a question the claim does not answer — can the operator modify the logs? If yes, this is telemetry, not evidence.

"Our agents are verified on-chain."

Claimed: something in the identity/integrity region. Verified by whom? Asserting what? Is the on-chain record a proof of computation, a hardware attestation, or simply a registration entry anyone may create? Three very different things, described with the same sentence.

Common misconceptions

"If the data is encrypted, the system is secure." Encryption addresses one property out of seven. The most common agent compromises — injection leading to unauthorized action — are unaffected by it.

"Private and confidential mean the same thing." Confidential means unreadable. Private means un-inferable.

"If we know who the agent is, we can trust it." Identity is not honesty.

"We have logs, so we have accountability." Not if the operator can edit them. Evidence requires that modification be detectable.

"A cryptographic proof means the output is correct." A proof establishes that a specified computation produced a specified output. If the model hallucinates, the proof certifies the hallucination with full mathematical rigour.

"Compliance certification means the seven properties are covered." Certifications largely assess organisational process and confidentiality controls. They were not designed for systems that take autonomous action.

Knowledge check

1. Name the seven components of trust. 2. A system encrypts everything and runs in an enclave, and an attacker still causes it to transfer money. Which property failed? 3. What is the difference between authentication and authorization? 4. Why is a cryptographic proof of inference not evidence that the answer is correct? 5. Give an example of a system that is confidential but not private. 6. Why does reputation depend on identity and accountability?

Key takeaways

• Conflation is mostly structural, not dishonest. Ask better questions rather than hunting for lies.
• Confidential, private, and anonymous are three different properties, in a one-directional relationship.
• Every sound mechanism has a right-hand column — the properties it does not provide.
• The standing question: which of the seven, and by what mechanism?