Policy Workflow

Policy workflow turns build-time evidence into reviewed runtime policy.

The goal is simple:

evaluate risk -> draft policy -> review -> compile -> deploy

Where Policy Starts

Policy starts from evidence collected during build-time review:

• tool and MCP inventory,
• capability labels,
• observed trajectories,
• use-case context,
• organization presets or review guidance.

That evidence helps create a candidate policy draft. The draft should be reviewed before it becomes active runtime enforcement.

Review Inputs

The policy workflow combines machine-generated evidence with human-owned context:

Input	Who usually owns it	Why it matters
Evaluation results	Security or platform team	Shows tools, capabilities, static exposure, observed exposure, and remediation priorities.
Risk classification	Use-case owner, reviewed under security policy	Sets the strictness level and explains why this use case needs that level.
Organization presets	Security team	Defines default control strength, effect choices, and review expectations.
Use-case context	Use-case owner	Explains expected behavior, sensitive data, trusted destinations, and business exceptions.

Draft

Draft creates a candidate policy from the evaluation results and review context.

Each proposed control should answer:

• What risk is this control addressing?
• Which tool or action does it apply to?
• What check should run?
• What should happen when the check fires?
• When should the control apply?
• Can the target runtime enforce it?
• Why was this control proposed?

Draft output is not the same thing as a live policy. It is the review point.

Policy Anatomy

A reviewed policy is easier to reason about as a set of controls. Each control has:

Part	Meaning
Risk	The tool-level risk or capability pattern the control addresses.
Control	The check AgentWarden should run, such as a deterministic rule, classifier, or approval gate.
Effect	The decision AgentWarden can return, such as allow, block, request approval, replace content, or return a safer response.
Activation	The condition for when the control should apply. Broad controls may apply always; narrower controls apply only to matching tool fields, destinations, or contexts.
Timing	Whether the control runs before an action, after a tool output, or before the final response.
Coverage	Whether the selected runtime exposes the boundary needed to enforce the control.
Lineage	The evidence and review context explaining why the control exists.

Review and Edit

Review is where a team confirms whether the proposed controls match the use case. It is also where a reviewer can edit the draft before compile and deploy.

Typical review questions are:

• Is this tool expected for the agent?
• Is the risk acceptable for this use case?
• Should the control allow, block, replace content, return a safer response, or request approval?
• Is the control too broad or too narrow?
• Can the target runtime enforce it?

Typical edits include:

• changing an effect from allow to block, approval, replacement, or a safer response,
• disabling a proposed control that does not apply to the use case,
• tightening when a control applies,
• adjusting context or exceptions,
• sending the edited draft back through compile.

This review step is important because policy is not only a technical artifact. It is also the approved policy for a specific use case.

Compile

Compile converts the reviewed draft into a runtime-specific policy package.

The selected runtime matters because different runtimes expose different enforcement boundaries. A policy that depends on a tool-call boundary can only run where that boundary is observable.

Compile also helps surface whether the reviewed policy is deployable for the target runtime. It can surface unsupported-capability warnings when a control cannot be enforced by the selected runtime.

In the CLI flow, compile can start from a completed draft job or from a reviewed draft file. The file path is useful when a team wants to inspect or edit the draft before compiling it.

Deploy

Deploy activates the reviewed policy for runtime enforcement.

For each use case, AgentWarden keeps one active policy at a time. Deploying a new approved policy replaces the active version for that use case and preserves the audit trail of what changed.

After deploy, runtime integrations use the active policy to decide whether to allow, block, request approval, replace content, or return a safer response.

Deploy can also be previewed first. A dry run shows what would change before the active policy is replaced.

Impact and Lineage

Where enabled, recorded trajectories can help preview how a policy would have behaved on past runs.

Lineage helps explain why a control exists:

evaluation finding -> review context -> policy draft -> deployed policy

That evidence trail matters for review, audit, and future policy updates.

CLI Commands

The CLI exposes the workflow as three policy commands:

• agentwarden policy draft submit
• agentwarden policy compile submit
• agentwarden policy deploy

At a high level, each stage reads different inputs:

Stage	Main inputs
Draft	Completed evaluation job, risk classification, presets, and use-case context.
Compile	Reviewed draft or draft job, plus the target runtime.
Deploy	Completed compile job, optional dry-run, and explicit confirmation for activation.

For command examples, see CLI.

After a policy is deployed, runtime integrations emit events and apply the returned decisions. See Runtime Integrations.