Today, most systems start from authentication and treat identity as a byproduct. Hessra flips this: we start with strong, composable machine identity and then layer authentication and authorization on top.
At a high level, you pick a secure root in your system—like a CI/CD runner, an orchestrator, or a trusted control-plane service—and provision it with a credential, either an mTLS certificate or a manually generated Hessra identity token. From there, that root can mint new identities or delegate its own identity to sub-identities that represent the actual workloads doing work.
You integrate with Hessra using a small auth service you run and our CLI and SDKs to request, delegate, and verify tokens from your code and automation.
For the theoretical foundations behind our approach, see our blog post on The Missing Foundation of Non-Human Identity.
How Hessra fits into your systems
Here are a few example patterns.
CI/CD runner
A CI/CD runner is configured with an mTLS certificate in its environment. It uses that certificate to authenticate to the Hessra auth service and gets a delegatable identity token, yourco:cicd-runner. When it spawns a job foo, it delegates that identity to create a new sub-identity yourco:cicd-runner:foo and starts the job with that token. The foo job can then use its own identity to get authorization tokens in line with the access policy you have decided it should have. The job can delegate further to sub-jobs like bar, or the runner can delegate to baz directly.
CI/CD deploy and webapp user management
A CI/CD job deploys your webapp to production. That job is provisioned with an identity (either via mTLS or delegation as above). As part of the deployment, it issues an identity for the webapp, for example yourco:prod:mywebapp. The webapp then uses that identity to request access tokens to talk to your internal microservices. You can also configure the webapp's identity to mint domain-restricted tokens, so it can issue short-lived session or API tokens for its users that are only valid for that webapp and only within the permissions you have decided are safe.
Internal AI Agent
You build and distribute an AI assistant agent for other engineers in your company. Each engineer gets a self-signed mTLS certificate and puts it in their local environment. At startup, the agent uses this to get an identity token representing the engineer, then delegates it to a top-level agent identity like yourco:eng-user123:agent. The agent operates with a constrained subset of the engineer's permissions, and can delegate further to sub-agents it spawns for specific tasks.
SaaS API keys
Your webapp is a SaaS product and you want to issue API keys to your customers. Using the webapp's Hessra identity, you configure it to mint domain-restricted identities that act as API keys. These come with built-in expiration and don't need to be stored in your database—your API just validates them. Later, you can distribute a client or SDK that uses those same identities to get fine-grained authorization tokens, giving you an easy step-up path from "just an API key" to strong, scoped access control.
Brownfield auth
You build and sell an agent that does document processing. The documents are found at brownfield locations like government or healthcare websites guarded by just a username and password. You already have a secure service that safely stores the username and password and exposes an API to use it, but you want your agents to have fine-grained access control for them.
You provision each agent with a Hessra identity using the mechanisms above, and configure policy so that only specific agent identities can get minted authorization tokens scoped to specific credential sets or operations (for example: "can use creds for portal-A to fetch documents, but not update anything"). The credential service requires a valid Hessra access token on every call and enforces those constraints before it ever touches the underlying username and password.
This lets you keep the ugly brownfield authentication model at the edge, while enforcing modern, fine-grained, identity-based control over which agents can actually use those credentials.
Our tech
Our identity and authorization primitives are built on Biscuit, a capability-based token format. The Hessra auth service mints Biscuit tokens that compile down to URL-safe base64 strings, but under the hood are signed blocks of identity and/or authorization logic.
You define identity and access control policy centrally, and we issue tokens that convey that policy. Once issued, tokens can be verified locally using the service's public key—no callback to Hessra is required. Our CLI and SDKs handle the heavy lifting of requesting, delegating, attenuating, and verifying these tokens from your services, jobs, and agents.
Where we want to go
Right now, we support mTLS and Hessra identity tokens as primary authentication mechanisms. We intend to keep adding mechanisms—especially the human-facing ones (OAuth, OIDC, SAML)—so you can manually provision machine identities from the same systems you already use for people.
We also want to add an authorization interoperability layer, allowing single-scope, fine-grained Hessra authorization tokens to be exchanged with a Security Token Service (STS) or password manager for other credentials (coarser JWTs, usernames/passwords, etc.). This would let you put a managed, fine-grained access layer in front of third-party or older, hard-to-change systems without having to refactor them all at once.
What are we hoping to achieve?
We want to make creating true zero-trust systems possible. A system where every request is authenticated and authorized, and every request is verified. A system that doesn't need costly gateways, network rules, VPNs, or service meshes. One that is reduced down to just your services and their underlying environment.
We can't see a world where AI Agents are effective without this. In a true zero-trust system, AI Agents should be able to run free, easily restricted to what they actually need to do their work.
Interested?
If you are interested in trying Hessra for CI/CD, APIs, internal services, or agents, the easiest way to start is:
- >Join the waitlist and describe your use case
- >Or email us at hello@hessra.net with a few details about your stack
- >Or schedule some time with our CEO/co-founder Jake