Skip to main content

​
Migrate warranty.md from 1.x through 2.3

Policy formats 2.0 through 2.3 keep the 1.x EVM, tool-call, custom, and execution-limit semantics. The version line opts into the new grammar. Policy 2.2 adds inbound inspection for exact covered MCP tool results. Policy 2.3 adds local redaction, operator-hosted scanner evidence, and time-bounded observe mode. Neither version adds result inspection to ## tool_calls. Operators must review the new boundaries, sign the resulting file again, and redeploy it before the new controls take effect.

​
Migration sequence

  1. Copy the signed 1.x policy into a working file.
  2. Remove the old ## signature block and change the root line to version: 2.0.0, version: 2.1.0, or version: 2.2.0.
  3. Add only the v2 sections the agent actually uses.
  4. Parse and test approved, denied, and pending intents against the new policy.
  5. Sign the complete body with Sigil Warrant and deploy the new file.
  6. Verify the returned policyHash and the first audit records before switching traffic.
For destructive repository, Git, provider, or production database actions, choose Policy 2.1. Configure the repository and resource profiles, then use an adapter that attests the complete effect manifest and owns the final mutation. A preflight-only hook must fail closed and must not be described as final mutation enforcement. Manual Warrant Advanced Mode can import, validate, preserve, and deploy every Policy 2.1 field that Sign accepts. Use it for filesystem profiles, per-method HTTP rules, EVM calldata enrichment, or any policy that exceeds the structured Form or Builder matrix. It keeps the source bytes intact until you edit them. Any edit detaches the old signature, so sign the complete policy again before deployment. Warrant Builder supports the repository profile, Git controls, the 28 supported database operations, and exact Policy 2.3 response controls through its guided controls. It rejects filesystem profiles, per-method HTTP rules, EVM calldata enrichment, and other unsupported fields before changing any Builder state. The structured Manual Form follows its own limits. Check the current generated capability matrix before choosing a guided surface. Manual Warrant’s Migration flow uses a strict Version 1 rollback bundle when preparing a migration or rollback. It validates the bundle before use. The bundle contains policy material, not a deployment receipt, and does not prove that either policy was deployed.

​
Field mapping

​
Example

The exact connector server ID, tool names, and metadata schema must come from the installed connector. Do not promote illustrative names into production without capturing those values from the adapter. For Policy 2.2 or 2.3, map only exact serverId.toolName values that are also exact members of allowed_tools. Do not copy a ## tool_calls web or HTTP action into these mappings: those actions remain outside inbound inspection. Follow the Policy 2.3 response controls guide before activating a re-signed 2.3 Warrant. Roll back semantically by stopping 2.3 issuance first, rejecting new 2.3 activation, and keeping signed 2.2 policies on format 1 until every remaining consumer is compatible.

​
Compatibility and rollback

Existing signed 1.x policies remain valid and keep their original soft-limit behavior. A rollback means restoring the previously signed file and restarting the signer. Keep the old policy hash and deployment record with the migration review. Use the conformance vectors to cover the base decision, approval hold, cap behavior, provenance requirement, and public error code before changing the active policy.