Your Contractor Has the CEO's Keycard: The Broken State of Machine Identity

Imagine you hire a contractor for a one-day job: painting an office on the 3rd floor. To give them access, you head to security and clone the first keycard you can find: the CEO's master badge.

The contractor can now not only get to the 3rd floor, but they can also walk into the server room, the finance department, and the R&D lab.

This sounds absurd in the physical world. You'd issue a temporary badge with tightly restricted access. Yet, in the digital world, we hand out the CEO's master keycard every single day.

This is the state of machine identity today. We're using credentials designed for humans. It’s time for a new model, one purpose-built for the machines.

> The Problem: Monolithic Tokens and Ambient Authority

Traditional tokens, like the JWTs we all use, bundle two distinct concepts together:

1. Identity: Who is this actor?
2. Permissions: What can this actor do?

This bundling is the source of the problem. To give a CI/CD job the ability to do one small thing, we often have to create a token with a wide range of permissions that are valid for its entire lifetime. This is called ambient authority. The credentials carry power that is always "on," just waiting to be misused.

Either that or we go hard the other way: static API keys that get copy-pasted everywhere. yuck.

When a dependency in your build script is compromised, the attacker inherits this full blast radius of ambient authority. Enjoy the next few weeks scrambling to figure out what damage was done and how much it'll disappoint your customers.

> The Hessra Model: Separating 'Who' from 'What'

Our approach at Hessra is built on a simple but powerful principle: separate the identity from the authorization. We accomplish this with a two-token system that provides both flexibility and control.

1. The Identity Token: A Verifiable, Delegatable "ID Card"

Think of our Identity Token as a cryptographically verifiable ID card. It proves who an entity is, but it carries no inherent permissions. Its superpower, however, is offline delegation.

An entity can take its own Identity Token and create a new, more constrained one for a sub-task without talking to a central service. A pipeline can create a specific identity for its test-job. An AI agent can create a unique identity for a summarization-sub-agent. This creates a verifiable chain of identity, shrinking the scope at every step.

The Technical Magic: Biscuits and Cryptographic Delegation

Under the hood, we use Biscuit tokens - a modern capability-based token format that enables something remarkable: offline attenuation. Unlike traditional tokens that require round-trips to a central authority for every delegation, Biscuits let you create more restricted versions locally using cryptographic proofs.

Here's how it works. When we create an identity token for urn:hessra:alice, the base token contains this Datalog rule:

// Facts about the token holder
subject("urn:hessra:alice");

// Authorization check - allows alice OR any sub-identity
check if actor($a), $a == "urn:hessra:alice" ||
         $a.starts_with("urn:hessra:alice:");

// Time-based expiration
check if time($time), $time < {now + 8 hours};

The magic happens when Alice wants to delegate to her agent. She can create an attenuation block that adds another layer of checks:

// Additional restriction for the delegated identity
check if actor($a), $a == "urn:hessra:alice:agent" ||
         $a.starts_with("urn:hessra:alice:agent:");

// Can add shorter expiration
check if time($time), $time < {now + 5 min};

Here's the crucial part: in Biscuit, all checks must pass. The token now only works for urn:hessra:alice:agent because that's the intersection of both rules. Alice herself can no longer use this attenuated token - it's been narrowed to just the agent's identity.

This delegation uses Biscuit's third-party blocks, which are cryptographically signed. The agent can prove it has Alice's delegated authority without Alice's private key and without contacting any server. The colon delimiter (:) creates clear hierarchical boundaries, preventing prefix attacks where alice2 might try to impersonate alice.

2. The Authorization Token: A Single-Use, Just-in-Time "Ticket"

This is the valet's ticket. It is a short-lived, single-use token that grants permission for one specific action.

How Authorization Tokens Encode Permissions

While identity tokens prove who you are, authorization tokens grant specific what you can do. They're also built on Biscuits, but with a fundamentally different structure. Here's what an authorization token contains:

// The permission grant - this is the key difference
right("alice:agent", "database:prod", "read");

// Time-based expiration (much shorter - 5 minutes, or seconds if you want)
check if time($time), $time < {now + 5 minutes};

The right() fact is the heart of the authorization token. It explicitly grants a specific permission: the subject alice:agent can perform the read operation on database:prod. No more, no less.

When a service needs to verify this token, it uses an authorizer that checks for this exact permission:

// The service adds facts about the current request
time(1735603200);
subject("alice:agent");
resource("database:prod");
operation("read");

// Authorization succeeds only if the token grants this exact right and the "checks", like the time-based expiry, pass
allow if subject($sub), resource($res), operation($op),
         right($sub, $res, $op);

Notice the precision here. Unlike traditional JWTs that might grant broad "database access," this token grants exactly one permission triple. If alice:agent tries to write instead of read, or access database:staging instead of database:prod, the authorization fails immediately.

This is how we eliminate ambient authority. The token doesn't carry dormant permissions waiting to be exploited. It grants one specific action, expires quickly, and becomes useless afterward.

To get an Authorization Token, an entity presents its Identity Token to our central service. The service inspects the identity ("I am pipeline-123:test-job") and checks it against a centralized policy engine. If the policy allows it, the service issues an Authorization Token to perform that one action.

This just-in-time model eliminates ambient authority. Your systems only ever have the exact permission they need, for the exact moment they need it. Further, the authorization token is still a capabily token meaning that the identity it grants access for is encoded. So you still only need to send the authorization token when the time comes to take its action. Plus, you don't need to worry about the datalog. We've figured that out for you, so just use our SDK.

> Putting it to Work: From Theory to Practice

This isn't just a theoretical exercise. This model solves acute, expensive problems that engineering teams are facing right now.

Use Case #1: Securing the CI/CD Pipeline

• The Pain: Your build pipeline is a prime target. You're running third-party code, and you need to grant it access to artifact registries, cloud resources, and secret stores. A single compromised NPM package can exfiltrate keys and wreak havoc.
• The Hessra Solution: Your pipeline authenticates once to get a root Identity Token. For each subsequent step, it delegates a new, unique identity (:build, :test, :deploy). When the test job needs database access, it uses its unique identity to request a single-use Authorization Token. An attacker who compromises the test job now only has a worthless identity. They don't have a powerful JWT that grants access to your container registry.

Use Case #2: Building Trustworthy AI Agents

• The Pain: How do you grant an AI agent access to your data? If you give it your own credentials, you've created a clone with all of your permissions. You have no way to enforce least privilege or create an audit trail that distinguishes your actions from the agent's.
• The Hessra Solution: You delegate a constrained Identity Token to your primary agent (user:jane-doe:main-agent). The agent can now act verifiably on your behalf, not as you. When it spawns a sub-agent to summarize a document, it can delegate an even more constrained identity (...:main-agent:summarize-doc-456). Every action is traceable to a specific, unique actor in the chain.

Use Case #3: Empowering Multi-Tenant SaaS Customers

• The Pain: Your SaaS customers want to integrate their other tools with your product, but building a secure, fine-grained API key and permissions system is a massive engineering effort.
• The Hessra Solution: Use our model to let your customers manage identity delegation themselves. They can create unique identities for their different integrations. You, the SaaS provider, simply enforce the policies at the edge. You retain central control over authorization while offloading the complexity of credential management to your customers.

> The Future is Delegated

The era of monolithic services and static credentials is over. We're moving towards a world of ephemeral infrastructure, autonomous agents, and complex distributed systems. In this world, trust cannot be static; it must be dynamic, explicit, and delegatable.

By separating identity from authorization, we provide a primitive that is flexible enough for developers and secure enough for the most demanding enterprise environments.

If you're tired of treating your machines like users and want to build a true zero-trust foundation for your infrastructure, let's talk.

— Jacob Valentic, Co-founder of Hessra