CAPABILITY SECURITY FOR MACHINES
Most authorization systems check credentials. Hessra proves them.
Capability tokens encode policy directly: both the permission and an unforgeable reference to the object. The verifier confirms the context matches. If it doesn't, it fails closed.
TWO MODELS
In one model, you issue a token and trust that every system receiving it will verify it correctly. Authorization is a property of how the token is checked.
In the other, you issue a token that already encodes what correct verification looks like. Authorization is a property of the token itself.
Hessra is the second model.
HOW CAPABILITY TOKENS WORK
AUTHORITY IN THE TOKEN
The capability token encodes the authorization decision directly. Subject, resource, operation: all three are in the token as a cryptographic proof derived from explicit policy. Not a hint for something else to evaluate or a token stuffed with everything under the sun that a huge ACL needs to check.
DESIGNATION WITHOUT A CENTRAL REGISTRY
A capability names the exact object it authorizes access to. The root authority grants the permission. Designators (your apps, your services, your jobs) control their own naming, down to the tenant, the user, the specific resource. The two halves compose without either needing to know what the other knows.
VERIFIED ANYWHERE, FAIL CLOSED
Verification requires a public key, the token, and the context about the current request. Nothing else. No service call, no network dependency. Works in a microservice, a Postgres extension, an edge function, an embedded device. If the verifier cannot satisfy every check in the token, it fails closed. It isn't possible to forget to check a "scope".
WHERE IT FITS
AI AGENT ORCHESTRATION
An agent that acts under your credentials is an agent with your blast radius. Hessra lets you delegate a constrained identity to each agent and sub-agent in the hierarchy, offline, without a central service. Each agent requests capabilities scoped to exactly the operations it needs. A compromised agent has authority over one operation on one object. Nothing more.
CI/CD PIPELINES
Your pipeline does not need access to everything it might ever touch. It needs to do its job. Delegate scoped identities to each job from a root identity at pipeline start. Each job requests capabilities for the operations it actually runs. When the job ends, the identities evaporate. No secrets left behind. No rotation backlog to maintain.
MULTI-TENANT APIS
Your root authority does not need to know every tenant in your system. Each service controls designation for its own namespace, so new tenants do not require updates to a central policy server. Capabilities are cryptographically bound to their tenant context and cannot be used anywhere else. Authorization that scales with your product, not with your database.
SERVICE-TO-SERVICE AUTH
Zero trust between services should not mean every service calls a policy engine on every request. Capability tokens verify locally with a public key. No sidecar, no service mesh, no latency on every hop. Each service verifies the token at its own boundary, exactly where enforcement should happen.
GET STARTED
OPEN CORE
The capability engine and token primitives are open source, written in Rust. Build directly with the model, use as much or as little of the stack as your system needs.
GitHub →DEVELOPER
A managed root authority, ready to connect. You configure policy and Hessra handles key management, token issuance, and the authority service itself. The fastest path from curiosity to running capability security in production.
ENTERPRISE
The governance layer the compositional model requires. Policy aggregation, audit surface, telemetry, and fine-grained revocation across a system where verification is intentionally distributed. Capability security legible at organizational scale.
Schedule a call →Capability security for the machine age.
Schedule a call or join the waitlist.