Embedded governance.
Governance that is part of the work rather than a record kept beside it — carried inside every exchange, and travelling with the data wherever it goes. The authority and the measured conditions arrive with the information, so the system about to act can check them before it acts.
Embedded, not added on.
Almost all governance sits beside the work. A policy document. A control catalogue. A log somebody reads afterwards. An audit, on a sample, months later. Every one of them describes what should have happened, and every one of them is read after it already did.
That was workable while the work moved at human speed and a person signed each consequential step. Software takes the step now. It takes thousands of them in the time it takes to read this paragraph, using credentials that are entirely valid, and each one looks exactly like the one before it.
Added-on governance can tell you what happened. It cannot be present when it happens. That is not a failure of rigour — a well-run control environment is genuinely rigorous. It is a failure of position. The control is in the wrong place, and no amount of care moves it closer to the moment that matters.
Built-in governance is in the right place. The authority and the evidence ride inside the exchange itself, so the system about to act tests them first — not afterwards, not on a sample, but on every exchange, as a condition of proceeding.
And it travels. That is the part nobody is building.
Ask almost anyone what governance looks like and they will describe a record: a log, an audit trail, a register. Something written down about the work and kept somewhere safe.
A log is a statement about data, stored apart from it. And data does not stay where it was produced. It is forwarded to another agency, cached by a model, pulled into a report, handed to an agent three systems away. The moment it leaves, the log stays behind. A log file is governance that stays home. Your data does not.
Built in means the evidence goes where the data goes. Wherever it travels and however many systems later, the authority and the measured conditions are still attached — and still checkable by someone who has no access to your logs, no account on your system, and no reason to take your word for it. That last part is the whole test.
Rootz does not enforce your policy. You do, and so does whoever receives your data. What changes is that the evidence needed to apply that policy arrives with the work, while there is still time for it to matter.
The message is a unit of security.
A signed message can retain evidence of its origin and integrity beyond the connection that carried it. Its context can identify the intended recipient, purpose, time and preceding request.
A receiving system checks that evidence against the action it is about to take. The result becomes part of the next exchange. This is the foundation of Rootz’s message-based security model.
A checkable account of agentic state
What the system may do
The principal, delegated authority, task and constraints establish the permitted action.
What it is using
Source records, transformations and explicit quality checks establish the evidence available to the task.
Under what conditions it acts
Measurements and signed assertions describe the covered processing environment at their stated depth and time.
What it produced
A request-bound signed result preserves the relationship between instruction, evidence and output.
What happens next
The recipient applies its policy to the verified evidence. Missing or failed checks have defined outcomes.
AI makes repeated verification practical.
Agents can invoke deterministic verification tools on each exchange. They can also perform task-specific validation and numerical checks, preserving the method and the result.
The workflow must make those checks required and retain their outcomes. That turns evidence into a condition of action and gives human governance a concrete implementation.
The guidance names the mechanisms.
The April 2026 Five Eyes guidance calls for signing authorized instructions, integrity checks on task constraints and attestation where expected code must be established. Its design guidance also recommends message integrity and freshness checks before use.
The NSA’s May 2026 MCP guidance specifically recommends message signing and verification, time and context binding, and replay protection. These are recommendations within broader security guidance, rather than a certification of any vendor.
Government authority and machine verification work together.
The agency determines the rule and who may make the decision. The system checks the evidence required to carry that rule into each exchange. The resulting record supports subsequent verification and review.
Driver licensing example