Sequel to IAM as Maharaja: How RAJ Redeems the Original Sin of Cloud Authorization
A short skit in the style of Neal Stephenson
CAST
- Mark Miller — The Protagonist. Object-capability theorist. Wears a black trench coat. Carries no credentials, only capabilities.
- RAJEE — An English Springer Spaniel. Also a machine that enforces truth. Loyal, alert, incapable of improvisation. Enforces exactly what it is given and nothing more.
- THE MACHINE — A sprawling IAM construct. Full of roles, policies, conditions, exceptions, YAML, and footnotes.
- Leslie Lamport — A monk who keeps time. Speaks in invariants.
- Bram Cohen — A chaos engineer with a bag of hashes.
- THE MANIFEST — An immutable manifest. Silent. Content-addressed. Terrifying.
SCENE 1: THE MACHINE ROOM
The Machine hums. Miles of YAML scroll past on glass walls.
Policies reference policies that reference policies.
Everything technically works. Nothing is understood.
THE MACHINE
Identity confirmed. Role assumed. Context inferred. Environment trusted.
You may proceed.
MARK MILLER
Proceed where?
THE MACHINE
You are authorized.
MARK MILLER
Authorized to what?
The Machine pauses. Fans spin faster.
THE MACHINE
…To do what your role allows.
MARK MILLER
That’s not an answer. That’s ambient authority wearing a name tag.
SCENE 2: ENTER RAJEE
An English Springer Spaniel trots into view.
Bright eyes. Calm posture. Tail wagging, but only within spec.
No UI.
No dashboard.
No configuration file longer than a page.
RAJEE
Present capability.
MARK MILLER
I have one.
He holds up a token — a RAJ. It glows faintly.
THE MACHINE
Identity required.
RAJEE tilts its head.
RAJEE
Denied. Identity is not authority.
The Machine bristles. RAJEE sits.
SCENE 3: THE MANIFEST APPEARS
A hex string fills the air.
It does not change.
It does not blink.
LAMPORT (quietly)
That object has no history. Only truth.
MARK MILLER
This is a manifest.
Immutable. Content-addressed.
It defines a collection of files. Exactly. Forever.
THE MACHINE
Where is the policy that enumerates them?
MARK MILLER
There isn’t one.
The Machine recoils, offended.
SCENE 4: THE GRANT
MARK MILLER
The policy says only this:
Role X may read Manifest M.
A Cedar policy. Evaluated once. Final.
THE MACHINE
But where are the paths?
The prefixes?
The conditions?
The deny statements?
MARK MILLER
They’re not permissions.
They’re derivations.
RAJEE’s ears perk up. Tail still.
SCENE 5: UNFOLDING
A client request arrives:
GET s3://bucket/obscure/path/file.parquet
RAJEE sniffs the token.
RAJEE
Checking capability…
- Token valid
- Manifest ID matches
- Operation permitted
- File membership: TRUE
RAJEE allows the read.
No policy lookup.
No role assumption.
No context inference.
Just truth.
SCENE 6: THE MACHINE PANICS
THE MACHINE
That file is not under an approved prefix!
MARK MILLER
Prefixes are approximations.
Manifests are meaning.
THE MACHINE
What if the manifest changes?!
RAJEE growls softly. Once.
MARK MILLER
It can’t.
The room goes quiet.
SCENE 7: COHEN LAUGHS
COHEN
I told you. Hashes don’t negotiate.
He tosses a Merkle tree into the air.
It assembles itself. Perfectly.
RAJEE watches it fall. Does not chase.
SCENE 8: THE REALIZATION
LAMPORT
Authority was never about where.
It was about what —
at a point in time that cannot move.
THE MACHINE
Then what am I?
RAJEE looks at it, head tilted.
MARK MILLER
A guess.
SCENE 9: SNOW CRASH
The Machine attempts to recompute its policies.
The graph loops.
A deny overrides an allow
which overrides a condition
which references a role
which assumes itself.
The Machine collapses under its own context.
RAJEE stands. Calm. Unaffected.
SCENE 10: EPILOGUE
THE MACHINE (fading)
Who decides authority?
MARK MILLER
No one.
He gestures to the manifest.
MARK MILLER (cont.)
It’s made manifest.
RAJEE lies down beside it. Guarding.
The manifest remains.
FINAL LINE (VOICEOVER)
In the end, the Machine lost not because it was too weak,
but because it tried to remember what should have been immutable.
Appendix I: Manifest Authority (not the pun)
Definition
Manifest Authority is a form of capability-based authority in which:
Authority is made explicit and inspectable by binding it to an immutable, denotational structure (a manifest), rather than inferred from identity, environment, or context.
In this model, authority is not ambient, implicit, or role-derived.
It is made manifest — concrete, bounded, and visible.
Ambient vs Manifest Authority
Ambient Authority
Ambient authority arises from where you are or who you are:
- Process has power because of its IAM role
- Code has access because of its execution environment
- Identity implies authority
- Context leaks into power
Characteristics:
- Implicit
- Difficult to audit
- Easy to overgrant
- Hard to reason about locally
- Authority is diffuse
“You can, because you are.”
Manifest Authority
Manifest authority arises from what you explicitly hold:
- A capability token (RAJ)
- Bound to a specific, immutable manifest
- Enforced mechanically by a narrow enforcer (RAJEE)
Characteristics:
- Explicit
- Inspectable
- Narrowly scoped
- Locally reasoned about
- Authority is denoted, not inferred
“You can, because you were given.”
The Role of the Manifest
The manifest is not the source of authority.
It is the definition of scope.
The manifest:
- Is immutable
- Is content-addressed or versioned
- Defines a precise range of resources
- Cannot expand silently
- Cannot drift over time
The manifest therefore provides evidence, not permission.
Authority comes from:
- Cedar policy decision
- RAJ minting (capability creation)
The manifest provides:
- Exact semantic boundary
- Proof of subset
- Stable meaning
The manifest constrains authority.
It does not grant it.
Why This Matters
Binding authority to an immutable manifest:
- Eliminates prefix approximation errors
- Enables exact authorization over large collections
- Prevents silent expansion of scope
- Makes audit and forensics precise
- Makes revocation meaningful
- Turns authorization into a pure, denotational act
Instead of authorizing places, RAJ authorizes meanings.
Denotational Authority
Manifest authority is a form of denotational authority:
- Authority is defined by what is named
- Not by where code runs
- Not by who is asking
- Not by what context happens to apply
The manifest is the denotation.
The RAJ is the capability.
RAJEE is the mechanical enforcer.
Together:
Authority is made manifest.
Why This Is Not Ambient Authority
Manifest authority avoids ambient authority because:
- The manifest identity is fixed by trusted state
- The client cannot choose or modify scope
- RAJEE cannot expand authority
- The manifest cannot change meaning over time
- The capability fully defines what is allowed
There is no hidden power.
No implied access.
No contextual leakage.
Only what is explicitly named.
In One Sentence
Manifest Authority is authority that exists only because it has been explicitly made visible, bounded, and inspectable by reference to an immutable definition of scope.
Or, more simply:
Authority is not assumed. Authority is made manifest.
Appendix II: Authority Manifests
(Using package manifests as the scope boundary enforced by RAJEE)
Definition
An Authority Manifest is an immutable package manifest whose identity is used to define the exact scope of a capability enforced by RAJEE.
A capability does not list what it allows.
It names a manifest, and the manifest defines what that authority means.
This relies on:
Why a Package Manifest Is Suitable as an Authority Boundary
A package manifest has properties that most storage locations do not:
- It is immutable
- It is exact (enumerates a precise set of objects)
- It is versioned and content-addressed
- It is independently auditable
- It is independent of bucket layout, prefixes, or infrastructure structure
Because of this, the manifest can safely serve as the definition of scope for a capability without relying on:
- IAM roles
- Prefix conventions
- Context or environment
- Policy enumeration
What Goes Into the RAJ
When Cedar authorizes a manifest grant, RAJA mints a RAJ (a JSON Web Token) containing:
manifest_id(immutable identifier)mode(readorreadwrite)- standard token claims (expiry, audience, signature)
The RAJ does not contain:
- file paths
- bucket prefixes
- policy conditions
- any enumeration of allowed objects
All of that is derived by RAJEE from the manifest itself.
How RAJEE Enforces an Authority Manifest
When a client presents a RAJ and requests an operation (for example, an Amazon S3 object read):
- RAJEE validates the RAJ (signature, expiry, claims)
- RAJEE retrieves the manifest by its immutable
manifest_id - RAJEE verifies the requested
(bucket, key)is a member of the manifest - RAJEE verifies the requested operation is allowed by
mode - RAJEE performs the S3 operation on behalf of the client
RAJEE never consults IAM policy to determine scope.
It consults the manifest.
Why This Scales to Thousands of Objects
A manifest may describe:
- Thousands of files
- Across multiple buckets
- With arbitrary paths
Yet the capability remains:
- Small
- Stable
- Easy to inspect
- Fast to evaluate
Because the manifest provides a constant-time membership check once loaded or cached, rather than requiring thousands of policy rules.
Security Properties
Using an authority manifest provides:
- No prefix leakage — only listed objects are allowed
- No silent scope expansion — the manifest cannot change
- No client influence — clients cannot alter scope
- No ambient power — RAJEE only does what the RAJ + manifest permit
- Precise auditability — it is always possible to answer:
“Who could access exactly this set of objects?”
The manifest acts as evidence of membership, never as a source of authority.
This avoids ambient authority entirely.
Relationship to Path-Based Grants
Path-based grants authorize access to locations (bucket + prefix or key).
Authority manifests authorize access to a semantic set defined by immutable enumeration.
Both can coexist and be enforced by RAJEE, but they represent different authorization models:
- Location-based authorization (IAM-like)
- Manifest-defined authorization (capability-like)
The Subtle but Critical Point
This model is not:
“You may read this manifest.”
It is:
“This manifest defines what you may read.”
The manifest is not the target of access.
It is the definition of scope.
In One Sentence
An Authority Manifest is an immutable package manifest whose identity defines the exact scope of a capability enforced by RAJEE.
Or more simply:
Authority is not an inference. Authority is a manifest.
iHack, therefore iBlog 