Policy as Code with Intended

Policies Belong in Git

Governance policies are critical infrastructure. They determine what your AI agents can and cannot do in production. They define the boundaries of autonomous operation. They are the rules that protect your systems, your data, and your customers.

And yet, most organizations manage policies through web consoles. Click here to add a rule. Check this box to enable a constraint. Copy and paste from a spreadsheet someone emailed around.

This is how we managed application configuration in 2005. We know it does not work. Configuration drift, undocumented changes, no rollback capability, no review process. The industry solved this problem for application code with version control, code review, and CI/CD. Governance policies deserve the same treatment.

Intended supports policy-as-code: policies are defined in structured files, stored in Git repositories, reviewed through pull requests, tested in CI, and deployed through automated pipelines.

The Policy File Format

Intended policies are defined in YAML. We chose YAML over a custom DSL for practical reasons: YAML is familiar to every infrastructure engineer, it is supported by every code editor, and it is easy to generate programmatically.

A policy file has three sections: metadata, conditions, and outcomes.

name: deny-production-database-delete
version: "1.0"
description: Deny deletion of production databases without VP approval
domain: data_management
category: database_operations

conditions:
  action: database.delete
  environment: production
  risk_score_min: 50

outcome: escalate
escalation:
  reviewers:
    - role: vp_engineering
  timeout: 4h
  timeout_outcome: deny

This policy says: when an AI agent attempts to delete a production database and the risk score is 50 or above, escalate to a VP of Engineering for approval. If the VP does not respond within 4 hours, deny the action.

The policy is readable. It is reviewable. It is version-controlled. And it is testable, which we will get to shortly.

Git-Based Workflow

The recommended workflow for policy changes follows the same pattern as application code changes.

**Step 1: Branch.** Create a feature branch for the policy change. Name it descriptively: `policy/deny-prod-db-delete` or `policy/relax-staging-deploy-threshold`.

**Step 2: Edit.** Modify or create policy files in the branch. Each policy is a separate file in the `policies/` directory, organized by domain.

**Step 3: Test.** Run the policy test suite locally. Policy tests verify that policies produce expected outcomes for a set of test intents. More on this below.

**Step 4: Review.** Open a pull request. The pull request shows the exact policy change: what conditions changed, what outcomes changed, what new policies were added. Reviewers can see the diff, understand the impact, and approve or request changes.

**Step 5: Merge.** After approval, merge the pull request. The merge triggers the deployment pipeline.

**Step 6: Deploy.** The CI/CD pipeline validates the policy files, runs the test suite, and deploys the policies to the Intended Authority Engine. Deployment is atomic: either all policies in the update are deployed or none are.

This workflow provides the same benefits that Git-based workflows provide for application code: traceability (every change has an author, a reviewer, and a timestamp), reversibility (any change can be reverted by reverting the merge commit), auditability (the Git history is a complete record of every policy change), and collaboration (multiple team members can work on policies simultaneously without conflicts).

Policy Testing

Untested policies are as dangerous as untested code. A policy that is supposed to deny production database deletions but has a typo in the condition will silently allow those deletions. You need tests.

Intended's policy testing framework uses test fixtures: pairs of test intents and expected outcomes. A test fixture looks like this:

name: test-deny-production-database-delete
description: Verify that production database deletions are escalated
intent:
  domain: data_management
  category: database_operations
  action: database.delete
  resource:
    environment: production
  risk_score: 65
  agent:
    trust_level: standard

expected_outcome: escalate
expected_escalation:
  reviewers:
    - role: vp_engineering

The test runner evaluates the test intent against the policy set and verifies that the actual outcome matches the expected outcome. If the test fails, the CI pipeline fails, and the policy change is not deployed.

We recommend test fixtures for every policy: at least one positive test (the policy triggers as expected) and at least one negative test (the policy does not trigger for an intent that should not match). For complex policies with multiple conditions, test each condition boundary.

CI/CD Pipeline

The policy deployment pipeline has four stages.

**Validate.** Parse all policy files and verify they are syntactically correct. Check that all referenced domains, categories, and action types exist in the MIR taxonomy. Check that all referenced roles and escalation targets exist in the organization configuration.

**Test.** Run the complete test fixture suite against the policy set. Every test must pass. There is no "skip test" option in the policy pipeline.

**Dry Run.** Evaluate a sample of recent production intents against the new policy set and compare the outcomes to the current policy set. This dry run surfaces unintended changes: if a policy change would have changed the outcome for 500 intents last week, that is worth investigating before deployment.

**Deploy.** Push the new policy set to the Authority Engine. The engine loads the new policies atomically. During the transition, in-flight evaluations complete against the old policy set. New evaluations use the new policy set. There is no window where policies are partially updated.

Policy Versioning and Rollback

Every policy deployment creates a version. The version is identified by the Git commit hash. The Authority Engine retains previous versions and can roll back to any previous version with a single command.

Rollback is important for governance because policy changes can have immediate, visible consequences. If a policy change causes a spike in escalations or unexpectedly blocks critical agent operations, rolling back to the previous version restores normal operation while the team investigates.

The audit ledger records which policy version was active for each governance decision. This means you can always determine which policies were in effect when a specific decision was made, even across multiple policy deployments.

Multi-Environment Policies

Just as application code is promoted through environments (dev, staging, production), policies can be promoted through governance environments.

Development policies are permissive and designed for testing. Staging policies mirror production policies but may include additional logging or relaxed thresholds. Production policies are the authoritative governance rules.

Policy promotion follows the same Git-based workflow: a policy change is merged to the development branch, tested, promoted to staging, validated, and then promoted to production. Each promotion is a merge and a deployment.

Who Owns Policies

Policy ownership is a common source of friction. Security teams want to own policies because governance is a security function. Platform teams want to own policies because they manage the agent infrastructure. Application teams want to own policies because they know their agents' requirements.

The answer is shared ownership with clear boundaries. Security teams own the baseline policies: the minimum governance requirements that apply to all agents. Platform teams own the infrastructure policies: deployment, scaling, and operational constraints. Application teams own the domain-specific policies: the rules for their specific agents and use cases.

All policies live in the same repository, all changes go through the same review process, and all policies are tested together. Conflicts are resolved through pull request discussion, just like code conflicts.

Policy as code is not a technical gimmick. It is the operational discipline that makes governance maintainable, reviewable, and trustworthy at scale.