Solution
The agent can hold the session.
It cannot hold the signature.
Everything an agent needs to act, it can already get: a session, a token, a permission. Releasing the signature takes the person, on their own phone.
The problem
Every control in the path is looking at the session.
An agent operating inside a valid session issues a privileged call. Each control it passes returns the same verdict it would return for the person who owns that session, because each of them is evaluating the session rather than what is about to happen.
Session tokens and granted scopes
Issued once, then carried on every call after it. What the token settles is that a session was opened. It does not distinguish the person it was issued to from the automation now holding it.
An approval dialog in the agent's own UI
A dialog is a rendering the agent's own process draws. Whatever reaches the model reaches the screen, and nothing leaves that screen that anyone downstream can check.
How it works
The action waits until a person signs for it.
A verification step in your own API, between deciding to execute and executing. The agent calls the same endpoint and gets a pending state back until the approval arrives.
Your policy marks the action
You decide which operations need a person: by action type, by amount, by counterparty, by scope. Everything under the line runs on the agent's own session, untouched.
The action waits for the person
Your backend holds execution and the request goes to the enrolled person's own device, showing the action the agent is asking to run rather than a generic approve prompt.
Your backend checks, then runs it
The approval comes back carrying the action it was made for. Your server verifies it against the action it originally sent, and your handler runs only if it verifies.
Where the authority lives
In the phone's secure hardware, not in anything the agent can reach.
The signing key is generated inside Android's StrongBox or the TEE, or inside the iOS Secure Enclave, and there is no export path out of it. It is released by the person's own fingerprint or face. Nothing in a prompt, a model or a tool output reaches it, because it is not in the software at all — and nothing on our servers holds it either.
The boundary of the guarantee
Where this stops.
Stated here rather than discovered later.
Your gate is the enforcement point
The check runs in your backend, by design, because that is where the action actually happens. A second path that reaches the same operation without that check will reach it. What is not required is not controlled.
It does not say which agent asked
The record keeps each human decision bound to the action it authorized, so what a person approved and what ran under it stay separable. Which piece of software composed the request is not something this answers.
A person can approve the wrong thing
Somebody persuaded to approve an action will approve it, and the approval will be perfectly valid. No amount of cryptography closes that, and the security page says so at length.
Keep reading
See it on your own flow.
Your app, your call, our SDK.