About Hessra

Hessra started with a conviction about machines, not agents. Deciding exactly which machine may talk to which, and what it may do once it gets there, was hard even in mature organizations. The available tools were built for people in browsers or for machines inside a perimeter. Neither described the thing we actually wanted to control: a specific action on a specific resource by a specific caller, with no permission implied by where that caller happened to be running.

That was the state of machine-to-machine security before agents. It was shaky, and most teams lived with it because the callers were code they had written and could read.

Agents changed the terms. The caller is now a model that reads untrusted input and acts on what it reads, at a volume no review process can follow. You can stack controls on the old foundation and hope they hold. We think the foundation is the problem.

We set out to make machine-to-machine authorization simpler, more scalable, and more secure, and that work led us to capability security: a model in which authority is something you hold, not something you are checked against. A capability names exactly what it permits and verifies anywhere without a round trip. Nothing is implied. We built that model into Hessra’s engine and tokens and learned, in real systems, what it takes to make it practical.

Then we put it to work on the hardest case. Pairing capability security with information flow control gives an agent runtime two properties nothing else offers together. Every action is authorized by a capability the agent actually holds, and every action is judged against what the agent has already been exposed to. Individually safe tools stop composing into a breach. That runtime, and the control plane for operating a fleet of them, is what Hessra is today.

It is the same conviction we started with, applied where it finally stops being optional.

Want the details? Read how we arrived at capability security.