The Authorization Problem
When a human clicks "Deploy" in a CI/CD pipeline, there's an implicit authorization chain: they logged in (authentication), they have the right role (authorization), and the action is logged (audit). If something goes wrong, you know who did what and when.
When an AI agent deploys code, that entire chain breaks. The agent authenticated as... itself? Who authorized the deployment? Where's the proof?
Introducing Execution Warrants
A warrant is a cryptographically signed authorization token with four properties:
1. Scope — exactly what the agent is allowed to do
2. Time-to-live — when the warrant expires
3. Issuer — who or what approved the action
4. Constraints — parameter bounds the execution must respect
Here's what one looks like:
{
"warrant_id": "wrt-7f3a2b1c-...",
"scope": {
"action": "deploy_service",
"target": "api-gateway-prod",
"parameters": {
"version": "2.4.1",
"strategy": "rolling"
}
},
"ttl": 300,
"issued_at": "2026-03-25T14:00:00Z",
"expires_at": "2026-03-25T14:05:00Z",
"issuer": {
"type": "operator",
"id": "jane.smith"
},
"constraints": {
"max_retries": 1,
"rollback_on_failure": true,
"affected_services": ["api-gateway"]
},
"signature": "0x7f3a...b2c1"
}
How It Works in Practice
Step 1: Agent proposes an action. The agent submits an intent (e.g., "restart the API gateway") to the Intent Gateway.
Step 2: Policy Engine evaluates. Is this action allowed? What risk tier is it? Does it require approval?
Step 3: Approval (if required). T1/T2 actions wait for operator approval. T0 actions auto-approve.
Step 4: Warrant issued. The Warrant Authority creates a signed warrant with specific scope and TTL.
Step 5: Execution. The Execution Router uses the warrant to authorize the action. No valid warrant = no execution.
Step 6: Verification. Post-execution, the Verification Engine confirms the actual execution matched the warrant scope. Did the agent restart *only* the API gateway? Did it use rolling deployment? Any deviation flags an alert.
Step 7: Audit. Everything — the intent, policy decision, warrant, execution result, and verification — is recorded in the append-only ledger.
Why Not Just Use RBAC?
Role-based access control (RBAC) tells you *what an agent can do in general*. Warrants tell you *what an agent is authorized to do right now, for this specific action*.
An agent might have the *capability* to restart services (RBAC). But for each restart, it still needs a *warrant* — a specific, time-limited, auditable authorization. This is the difference between "you have a driver's license" and "you are authorized to drive this specific car, on this route, for the next 30 minutes."
The Legal Analogy
This isn't accidental. The warrant concept borrows from legal systems intentionally. A police warrant must be:
AI execution warrants follow the same principles. This isn't just good engineering — it's the kind of framework regulators understand and trust.
What This Enables
Learn more about Vienna OS warrants in our documentation →