Technology
Identity tells you who an agent is. It does not tell you whether the action in front of it should run. Here is how Hawcx roots every agent in a verified human and authorizes each action against live intent, on top of the standards you already use.
Across the industry, vendors are shipping agent identity. Microsoft brought Entra Agent ID to general availability. Okta is building its version. This is good, and it is necessary.
But identity answers only one question: who is this agent? It does not answer the harder one. When an agent resolves a plain instruction into a sequence of real actions, is each of those actions, right now, something the agent should be allowed to take?
That second question is the half almost no one ships, and it is the half Hawcx is built around. Hawcx is an agent identity, authentication, and authorization platform. It gives every agent a verifiable identity, roots that identity in a verified human, and checks each action against live intent before it runs. It does this on top of the standards the ecosystem is converging on, including OAuth 2.1, the Model Context Protocol, and the same key agreement Signal uses. It is not a replacement for any of them.
This briefing walks through the whole picture: why identity alone is not enough, how Hawcx roots agents in a human, and what happens, step by step, when an agent goes to use a tool.
Why a session token breaks for agents
Give an agent a verified identity and you have answered who it is. Now picture how it actually gets work done. Alice logs in, receives a token scoped to her session, and hands it to her agent. The agent presents that one token at every service it touches. Three things go wrong, and all three are structural, not bugs you can patch.
The token over-grants
A single instruction such as “book my flight, pay from savings, update my calendar, email my manager” fans out into many tool calls across many services. The session token authorizes all of it at once. So when the agent only needs to read a calendar, the same token in its memory also authorizes moving money and deleting files. A verified identity does nothing to narrow that.
The token is replayable
Possession is authority. An attacker who captures one request captures everything in it and can replay it from anywhere, until it expires. In June 2025 the EchoLeak vulnerability (CVE-2025-32711) showed exactly this shape. A crafted email steered Microsoft 365 Copilot into searching internal stores with its full OAuth scope. A token bound to one task would have refused the injected instruction.
The decision is made once, at login
Nothing in the bearer model re-checks whether this specific action is the thing the user actually wanted. The authorization happened minutes ago, for the whole session, and is never revisited. Bolting confirmation prompts onto a session credential does not fix the foundation, because those layers fall over under prompt injection too. Identity is necessary. It is not the authorization.
Root the agent in a verified human
Hawcx starts from a different premise. Instead of giving an agent a copy of the human’s authority, it makes the human’s verified identity the cryptographic root from which every agent’s identity is derived, then keeps the two strictly separate at runtime.
Two things hold at once. The agent has its own cryptographic identity, derived from the verified human’s root, and no human credential ever enters the agent’s process. And human authority enters only through policy and intent. The human’s role and the human’s instruction shape what each action is allowed to be, rather than the agent holding a copy of the human’s token.
The human’s intent travels a trusted channel the agent cannot tamper with. The agent acts inside what that root unsealed for it, and nothing beyond.
Other vendors give the agent a human to point at. Hawcx gives the agent a human it cannot act without.
Revoke the human, and every agent they own is locked out at once, because the whole chain begins with that one verified identity.
How it works, step by step
The full lifecycle runs in four steps, from first enrollment to a single tool call. The first two happen rarely. The last two happen on every action, and are engineered so that, to the agent, using a tool feels like attaching a static API key, with none of the risk.
1 · Register, human-involved, one-time. A human proves who they are, through the organization’s identity provider for enterprise, or document plus liveness verification for consumers. That act authorizes enrolling agents, and the platform binds each agent’s public key to the human’s identity, organizational role, and scope.
2 · Authenticate, agent-only, per session. When an agent starts a session, it performs a mutually authenticated key agreement using its own key. This is the same X3DH exchange Signal uses, giving forward secrecy and involving no human credentials at all. Nothing secret is ever transmitted. Sessions renew by full re-authentication rather than refresh tokens, so no long-lived credential sits in agent memory waiting to be stolen.
3 · Authorize, intent-bound, local. Each action the agent resolves is matched against the human’s live intent, inside a scope ceiling the human’s role set. This check happens locally and ahead of the call, so there is no per-action trip to a central server. That is what lets the model hold up at fleet scale.
4 · Use, every action. On each tool call, the agent presents one single-use token. The service verifies it locally, in the order of a few hundred microseconds, with no network hop, then tears the stub. A captured request is worthless, because there is nothing left to replay.
What you can do, not who you are
This is the half identity does not cover. The human gives an instruction, which is intent. The agent resolves it into concrete actions. Hawcx judges each action on its own, by matching it against that intent within the scope ceiling, and decides per action whether it runs, waits, or stops. Seniority does not clear an action. The action does, or it does not.
What an authorized action carries
When an action is allowed, it is carried by a token that is the authorization decision itself, sealed at the moment it is made, bound to exactly one operation, consumable once. Where a session credential is an all-access pass for the day, this is a single-entry ticket to one event at one time, and once you walk through, the stub is torn.
The high-stakes gate and the audit trail
For actions above a configurable risk threshold, a wire transfer or an irreversible deletion, the agent cannot proceed without a cryptographic approval from a second, independently enrolled device. The owner approves with biometrics on that device, and the approval is a signature, not a tap on a notification. An attacker who controls the primary device and has coerced the user still cannot clear this gate without the second device physically present.
After every action, both sides sign a bilateral receipt: the human’s authorization and the service’s execution, each independently verifiable by a third party without access to any session key. When an agent action is disputed, the receipt settles it.
Identity is necessary. It is not the authorization.
Hawcx is not a walled garden, and it does not ask anyone to abandon the direction the ecosystem is already heading. It builds on OAuth 2.1, the Model Context Protocol, and the same key agreement used by Signal. Agent identity from vendors like Microsoft and Okta is complementary, and it is a real step forward. The gap Hawcx fills is the layer those identity systems do not provide: a human-rooted, per-action authorization that reads live intent.
Vendor | Agent identity | Human principal | Per-action intent |
|---|---|---|---|
Hawcx | Yes | Cryptographic root | Bound to intent |
Entra Agent ID | GA | Sponsor, accountability | No, standing token |
Okta | Building | Admin owner | No, standing credential |
Their human is a sponsor to call. Hawcx’s human is a root the agent cannot act without.
What you actually deploy
For all the cryptographic machinery underneath, the integration surface is deliberately small. Hawcx operates the control plane. On your side, you add two small libraries.
Why it matters
The industry signal is consistent. The overwhelming majority of organizations are already running AI agents, a large share have seen unintended agent behavior, and a meaningful fraction report credential exposure through agents. Identity platforms tell you which agents exist. They do not stop a stolen credential from being replayed, and they do not judge whether the action in front of an agent matches what the human actually asked for.
The human authenticates once. Every agent inherits a precise, revocable slice of that authority, and nothing more.
That is the position in one line. Identity is necessary, but it is not the authorization. The most secure way to run agents is to root them in a verified human and authorize each action against live intent, working with the standards you already have rather than around them.