Enforced before the action. Recorded after it.

When an agent is configured, its policy defines what it is allowed to do: whether it can call external systems, write to a database, run code, or move money. Each capability the agent might use declares the permissions it requires.

Before any action runs, the runtime checks the capability against that policy. If the action needs a permission the policy has not granted, it is denied and never executes. This gate runs on every action, not as a periodic review.

Every capability is classified by how consequential it is. Actions marked blocked are always denied. Actions that reach outside the platform, such as sending an email or writing to a business system, are draft-gated: the agent prepares the action and it waits in your approval queue. Nothing leaves until a person approves it.

Consequential actions are approval-gated by default. This is the behavior a new agent starts with, and it is the behavior a kill switch returns any agent to instantly.

Agents begin fully supervised. Through a run of verified successes, an agent can earn a more autonomous posture for a class of work: first proceeding with a notification, and only later proceeding on its own. A single rejection or a failed or unverifiable result demotes it back down.

How far any agent is allowed to go is a limit you set. The maximum autonomy level is configured on your side, and a kill switch, organization-wide or global, returns every agent to fully supervised operation immediately.

When a consequential action runs, the runtime checks its result against a verifier for that capability: a returned message identifier, a success status, the number of records affected. An action that cannot be verified is treated as an anomaly and counts against the agent’s earned autonomy rather than being assumed successful.

Every enforcement decision is written to an append-only, hash-chained evidence record. Each entry is linked to the one before it, so the sequence cannot be altered or a gap hidden after the fact. Usage caps are checked before each model call, so a run cannot quietly exceed the budget set for it.

The two layers fail in opposite directions, on purpose. The policy decision fails closed: if the rules that govern an action cannot be read, the run stops rather than proceeding ungoverned.

The evidence writer fails open by design: if the evidence record cannot be written, the approved action still proceeds and a degraded-evidence marker is recorded instead, so the logging layer can never block legitimate, already-approved work.

Two records are kept. The first is an access-controlled activity history of what happened: every agent run, every approval decision, every configuration change, scoped to your organization so only your team can read it. The second is the append-only, hash-chained evidence record of enforcement decisions described above.

Activity-history retention is configured per engagement and stated in your agreement, and the history is exportable as CSV or JSON for your own review or compliance records.

This is not a content-moderation system. The runtime governs what an agent is permitted to do and records what it did. It does not screen text for tone or style, and it does not claim to.

It is also not a substitute for your approval. Governance constrains and records; the approval queue is where a person decides. No automated layer removes that step for consequential work.