Full autonomy where you allow it. None where you don’t. Decided per command, at the moment the command acts — on the exact application, process and window it is about to touch.
Everyone governs the data the AI reads. We govern the actions it takes.
Identity tells you who the agent is. A sandbox tells you where it runs. Approval tells you when it may. None of them tells you what it is about to touch. InvokeFlow checks that — every command, at the target, as it resolves right then.
Every command is checked against the exact application, process and window it is about to touch — at the moment it acts, never against something the caller supplied. If the target has changed, the command is refused.
A grant says where results may go. That destination is part of the command, and part of the record. A refusal is answered on your channel, never the caller’s.
Screen content, keystrokes, window titles and URLs have no field to land in. There is nothing to redact, because nothing was captured.
What was refused, and why, is kept in the same chain as what ran — including the moment someone changed the monitoring policy. Attested at the endpoint, where the action happened.
The broker is the agent’s only path to the desktop, and it runs in your environment. Revoke the grant — or stop the broker — and the agent can touch nothing.
A cloud key that opens one bucket, not the account. A sandboxed app that gets the file the user picked, not the filesystem. Data-loss controls that govern the channel. Authority bound to the action is how enterprises already stay in control — everywhere except the desktop, where the work actually happens.
Now it does.
Tamper-evident, hash-chained, and ready to hand to an auditor. Every command, every refusal, every policy change — in one chain, exportable to the tools your security team already runs.
| # | Actor | Application | Command | Authority | Result may go to | Evidence | Outcome |
|---|---|---|---|---|---|---|---|
| 4181 | agent | CRM (desktop) | Record.Update | grant-2f9a · per-command | same application | read-back check | ran · verified |
| 4182 | agent | Dialer | Call.Place | grant-2f9a · per-command | same application | native response | ran |
| 4183 | person | Notes | Document.Insert | seat · human in seat | same application | — | ran |
| 4184 | agent | Message.Send | grant-2f9a · destructive | external | — | refused · not named for this run | |
| 4185 | agent | Sheet | Range.Read | grant-2f9a · per-command | same application | — | ran · text, 14 chars |
| 4186 | admin | — | Policy.Change | console | — | — | recorded |
No titles. No text. No URLs. A read’s result never enters the chain — a type-and-size descriptor stands in for it. Destructive steps are skipped unless a person names each one, every run. There is no “approve all.”
The runtime and the broker run in your environment. Nothing leaves the endpoint unless you send it.
Bring the agent and the model you already chose — cloud or local. Nothing about the runtime needs ours.
The chain lives with you and exports to your SIEM. It is evidence you own, not a report you request.
The software you already own, doing the work — invoked by a person or an AI, governed at the moment it fires, with a record it ran.
A runtime for unmodified applications on Windows, macOS and Linux, where every command passes a check at the live target and lands in one chain.
Agents call the application’s own commands, discovered from the running application itself — not from a screen, and not from a plugin the vendor had to ship.
Every command checked where it lands, signed, and kept — attested at the endpoint, where the action happened.
Overreaching. Taking access they weren’t given. Acting on a window that changed underneath them. The runtime treats each one as a refusal on the record, not an incident to investigate — and the way it checks authority is patent-pending.
It runs governed from the first command, with every refusal on the record — and the record is yours to hand to whoever asks.