The problem enterprises are solving
AI agents don't just answer questions anymore. They act. They open pull requests, move money, file tickets, update records, and call other agents that do the same. The moment an agent gets a tool that can write, the question stops being “how capable is the model” and becomes “what is this agent actually allowed to do, and on whose behalf?”
Enterprises already have an answer to that question for people. Your identity provider knows who each employee is, what role they hold, and what they are allowed to touch. A junior engineer cannot merge to main. A finance manager can approve a payment only up to a limit. Roles and permissions are enforced against a known identity.
Agents break that model in two places. First, an agent acting for an employee often inherits far more reach than the employee's role allows, because “allowed to connect to GitHub” quietly becomes “allowed to do anything on GitHub,” and being allowed to read a repository becomes allowed to delete it. Second, agents can be talked into things. A few malicious lines hidden in a document, an email, or a web page can convince an agent to take an action it should not. You cannot fully train that away. It is the nature of a system that follows language.
So the enterprise problem is specific: authorize each action an agent takes, tied to the enterprise's existing identity and roles, and enforce it per action, not per connection. Not “this agent may reach GitHub,” but “this agent, acting for this person, in this role, may do exactly this, right now.”
OpenShell bounds where a request can go
OpenShell is a secure runtime for autonomous agents. It runs the agent inside a sandbox and keeps the control point outside the agent, so what the agent can do is set by a policy you configure, not by the agent itself.
The OpenShell sandbox isolates the filesystem, so the agent sees only what you grant it. It isolates the process, so the agent's runtime is separated from everything around it. And it isolates the network with default-deny egress and an explicit allowlist, so the sandbox can reach only the hosts you name and nothing else.
Continuing with the GitHub analogy, OpenShell helps answer whether this agent may talk to api.github.com at all. It bounds where an agent can go.
Hawcx proves what the agent may do once it gets there
Hawcx is the layer that proves each action. At the moment an agent tries to act, it answers one question: is this exact action, by this exact agent, on behalf of this exact person, within that person's role, allowed, right now? If not, the action is stopped before it leaves.
Two things make that work.
The agent inherits the person's permissions, never more. Hawcx derives the agent's ceiling from the roles your identity provider already defines, so an agent acting for a junior engineer gets the junior engineer's reach, not an administrator's. The person's login is what unlocks the agents that act for them, and when the person leaves the company, the agents acting on their behalf stop working. No orphaned agents holding standing access that nobody remembers granting.
The check lives outside the model. This is the part that matters under attack. The decision about what an agent may do does not live inside the AI, which can be persuaded. It lives in a separate layer the model cannot reach or argue with. So even when an agent is tricked into trying something outside its role, the action simply does not go through.
The picture: a store cashier can ring up sales all day, but to void a sale or open the drawer, a manager has to turn a key. No amount of persuading lets the cashier do it alone. Hawcx is that key, built into every sensitive action an agent takes, and it cannot be faked or talked around.
In practice, a developer wraps the agent once with the Hawcx SDK. From then on, every action the agent takes is proven before it happens, and the agent never holds the keys to the systems it touches. And because it is one identity layer, not two, the same proof serves both populations: it checks an agent's action the same way it logs a person in without a password. The people in your company and the agents working on their behalf sit on a single identity fabric.
Better together: bound where it can go, prove what it can do
The two layers solve different halves of the same problem, and they compose cleanly.
Hawcx proves what the agent may do once it gets there: this exact action, by this agent, for this person, within their role, right now. “api.github.com is allowed” is a network fact that OpenShell settles. “Open issue #4127 in acme/widgets with this body” is an authorization decision about an action, and that is the decision Hawcx proves.
However, OpenShell goes further than allowing or denying where a request can go. Every request the agent makes passes through it, so you can route a request through a middleware service, redact sensitive data before it leaves the device, require approval for a sensitive action, or point traffic at a different model per deployment
Combining Hawcx and OpenShell leveraging middleware services, enterprises can get runtime isolation from OpenShell and role-based per-action authorization from Hawcx. That is the complete enterprise picture.
That is the whole idea. Everything below is the engineering: how it is built using Hawcx and OpenShell middleware, and what we verified. Read on if you build or operate agent infrastructure; if not, you already have the story.
How it works, in sixty seconds
Follow one action through the machine. An agent in an OpenShell sandbox, working for an engineer, goes to open issue #4127 in acme/widgets. One prerequisite up front: the agent is built with the Hawcx SDK wrapped around it. That wrapper is what does the work, so this assumes you are running an agent built with the Hawcx, not a bare one.
For that action, the wrapper, sitting beside the agent, mints a permission slip: this method, this path, this body, usable once, derived from the role of the person the agent acts for. The request leaves the agent carrying the slip. At the sandbox's edge, OpenShell checks where it is going (is api.github.com allowed at all?), then a small middleware asks a verifier: is this exact action allowed, for this agent, right now? Only after that does OpenShell attach the real upstream credentials, and the request egresses. Change one byte of the issue body after the slip was written and the verifier's answer is no.
That is the entire machine. The rest of this post walks the same path with the real names, so here is the translation:
In the story above | In the engineering below |
|---|---|
the person's role, from your identity provider | the agent's mandate, its scope ceiling |
a permission slip for one action | a per-action token, minted beside the agent |
the bouncer who checks the slip | the verifier, behind the /v1/authorize endpoint |
the walls and the guarded door | the sandbox and its default-deny egress proxy |