Authenticity, Identity, and Authorization

Authenticity and provenance

Related to integrity, but distinct.

Integrity asks whether the computation was correct. Provenance asks where the artifact came from.

Your travel agent emails you a confirmation with an itinerary and a photograph of the hotel. Both could be fabricated — the itinerary hallucinated, the image generated.

The recipient of content wants to know: which system produced this, which version, under whose operation, and has it been modified since?

Mechanisms include cryptographic signatures over content, provenance manifests that travel with a media file, and statistical watermarks embedded in generated output. Stage 5 covers these — including the part usually left out: how well they survive contact with an actual adversary.

Identity — is this the agent I think it is?

Another agent contacts yours, claiming to be a booking service. How do you know?

Identity means a globally unique, cryptographically verifiable name bound to specific key material, such that an impostor cannot claim it. The mechanisms are cryptographic: keypairs, decentralized identifiers, verifiable credentials, on-chain registries.

Notice a subtlety that catches people out. Identity tells you who you are talking to. It tells you nothing about whether they are honest.

A verified identity attached to a malicious agent is a verified malicious agent. Identity is a prerequisite for accountability and reputation, not a substitute for them.

Authorization — was it allowed to do that?

The property that fails most often, and receives the least attention.

Authorization asks: given that we know who is acting, was this specific action within what they were permitted to do?

Our travel agent was authorized to spend up to $2,000 on travel. It was not authorized to:

Transfer $2,000 to an arbitrary address
Spend $2,000 forty times
Book travel next year
Read your email for any purpose beyond finding conference dates

Expressing all of that precisely — and enforcing it somewhere the agent cannot argue with — is the substance of Stage 3.

The pattern to watch for: most agent systems delegate authority as a single blunt grant — an API key, a broad OAuth scope, a wallet. The system then relies on the agent choosing to stay inside its intended bounds.

That is not authorization. That is hope.

Authorization is enforced by something other than the entity being authorized.

If the only thing preventing an overspend is the model's judgement, you do not have a control. You have a suggestion.

Authentication is not authorization

A terminology point that causes real incidents.

Authentication answers: who are you?

Authorization answers: what may you do?

They are often implemented by the same system, which is why people run them together. But they fail independently, and one is much more commonly broken.

The confused deputy problem — which we meet in Stage 2 — is precisely an authorization failure in a system with perfect authentication. Everyone knows exactly who everyone is. The agent still does something on behalf of a caller who should not have been able to trigger it, because the agent's own authority, not the caller's, is what gets checked.

When someone says "we use OAuth, so access is controlled," ask which of the two they mean.

Key takeaways

Provenance answers where an artifact came from, not whether the content is true.
Identity is not honesty. A verified malicious agent is still malicious.
Authorization must be enforced by something other than the agent. Model judgement is not a control.
Authentication and authorization fail independently. Knowing who is acting does not constrain what they do.