2026-02-21

Terraform + Intended: Infrastructure as Authority

Developer Relations · Developer Experience

Terraform + Intended: Infrastructure as Authority

If your infrastructure is defined as code, your authority policies should be too. Intended provides a Terraform provider that lets you manage policies, domain packs, escalation workflows, and agent configurations using the same HCL syntax and GitOps workflows you use for everything else.

No more clicking through a console to create policies. No more manual policy changes that are not tracked in version control. No more drift between what you think your policies are and what they actually are.

Installing the Provider

Add the Intended provider to your Terraform configuration:

hcl

terraform {
  required_providers {
    meritt = {
      source  = "meritt-security/meritt"
      version = "~> 1.0"
    }
  }
}

provider "meritt" {
  api_key = var.meritt_api_key
  org_id  = var.meritt_org_id
}

The provider authenticates with your Intended API key and manages resources in your organization's account.

Defining Policies

Policies are the core resource. Each policy defines a rule that the authority engine evaluates when an agent submits an intent:

hcl

resource "meritt_policy" "staging_deploy_allow" {
  name        = "staging-deploy-allow"
  description = "Allow all deployments to staging environments"
  intent      = "infrastructure.deployment.*"
  decision    = "allow"

  conditions {
    environment = "staging"
  }

  priority = 100
}

resource "meritt_policy" "production_deploy_business_hours" {
  name        = "production-deploy-business-hours"
  description = "Allow production deployments during business hours with canary"
  intent      = "infrastructure.deployment.apply"
  decision    = "allow"

  conditions {
    environment       = "production"
    deployment_method = "canary"
    time_window       = "09:00-17:00"
    days              = "mon-fri"
  }

  priority = 200
}

resource "meritt_policy" "production_deploy_off_hours" {
  name        = "production-deploy-off-hours"
  description = "Escalate production deployments outside business hours"
  intent      = "infrastructure.deployment.apply"
  decision    = "escalate"

  conditions {
    environment = "production"
  }

  escalation {
    type     = "single"
    timeout  = "30m"
    timeout_action = "deny"

    reviewer {
      role = "on-call-engineer"
    }
  }

  priority = 300
}

resource "meritt_policy" "deny_production_delete" {
  name        = "deny-production-delete"
  description = "Deny all production resource deletion by AI agents"
  intent      = "infrastructure.*.delete"
  decision    = "deny"

  conditions {
    environment = "production"
  }

  reason = "Production resource deletion requires manual intervention"

  priority = 50
}

Policies are evaluated in priority order. Lower numbers are evaluated first. Deny policies at priority 50 are evaluated before allow policies at priority 100, ensuring that deny rules take precedence.

Configuring Agents

Agent configurations define the identity and capabilities of each AI agent in your system:

hcl

resource "meritt_agent" "deploy_bot" {
  agent_id    = "deploy-bot-prod"
  name        = "Production Deploy Bot"
  description = "Automated deployment agent for production services"
  domain_pack = meritt_domain_pack.infrastructure.id

  allowed_intents = [
    "infrastructure.deployment.*",
    "infrastructure.scaling.horizontal",
    "infrastructure.health.*",
  ]

  denied_intents = [
    "infrastructure.*.delete",
    "infrastructure.networking.security-group.*",
  ]

  velocity_limits {
    intent  = "infrastructure.deployment.apply"
    window  = "1h"
    max     = 10
  }

  velocity_limits {
    intent  = "infrastructure.scaling.*"
    window  = "1h"
    max     = 20
  }

  tags = {
    team        = "platform"
    environment = "production"
    tier        = "1"
  }
}

resource "meritt_agent" "cost_optimizer" {
  agent_id    = "cost-optimizer"
  name        = "Cloud Cost Optimizer"
  description = "Agent that right-sizes resources and terminates idle instances"
  domain_pack = meritt_domain_pack.infrastructure.id

  allowed_intents = [
    "infrastructure.compute.resize",
    "infrastructure.compute.terminate",
    "infrastructure.storage.resize",
  ]

  spending_authority {
    max_hourly_impact  = 500
    max_daily_impact   = 5000
    currency           = "USD"
  }

  tags = {
    team = "finops"
  }
}

Agent configurations are enforced by the authority engine. If an agent submits an intent that is not in its allowed_intents list, the request is denied before policy evaluation. This provides a coarse-grained boundary that complements the fine-grained policy evaluation.

Escalation Workflows

Define reusable escalation workflows that policies can reference:

hcl

resource "meritt_escalation_workflow" "production_change" {
  name = "production-change-approval"

  step {
    type    = "single"
    timeout = "15m"

    reviewer {
      role = "on-call-engineer"
    }
  }

  fallback {
    timeout = "30m"

    reviewer {
      role = "engineering-manager"
    }
  }

  final_timeout        = "1h"
  final_timeout_action = "deny"

  notification {
    channels = ["slack", "email"]
    slack_channel = "#prod-approvals"
  }
}

resource "meritt_escalation_workflow" "financial_approval" {
  name = "financial-multi-party"

  step {
    type              = "multi-party"
    required_approvals = 2

    reviewer {
      role = "finance-approver"
    }

    reviewer {
      role = "department-head"
    }

    reviewer {
      role = "compliance-officer"
    }
  }

  final_timeout        = "2h"
  final_timeout_action = "deny"

  notification {
    channels = ["slack", "email"]
    slack_channel = "#finance-approvals"
  }
}

Policies reference workflows by ID:

hcl

resource "meritt_policy" "large_purchase" {
  name     = "large-purchase-approval"
  intent   = "procurement.po.create"
  decision = "escalate"

  conditions {
    amount_above = 50000
  }

  escalation_workflow = meritt_escalation_workflow.financial_approval.id
  priority = 200
}

Domain Pack Configuration

You can deploy custom domain packs through Terraform:

hcl

resource "meritt_domain_pack" "infrastructure" {
  name    = "infrastructure-custom"
  version = "2.1"
  base    = "infrastructure"  # extend the built-in pack

  intent_override {
    name = "infrastructure.deployment.apply"

    risk_model {
      financial_impact_weight    = 0.10
      operational_risk_weight    = 0.25
      blast_radius_weight        = 0.20
      reversibility_weight       = 0.15
      velocity_weight            = 0.15
      privilege_level_weight     = 0.10
      data_sensitivity_weight    = 0.00
      compliance_exposure_weight = 0.05
    }
  }

  threshold_override {
    intent             = "infrastructure.deployment.*"
    auto_approve_below = 0.35
    escalate_below     = 0.75
    deny_above         = 0.75
  }
}

The `base` parameter extends a built-in domain pack. You only need to specify the overrides. Everything else inherits from the base pack.

GitOps Workflow

With Intended policies in Terraform, you get the full GitOps workflow for free:

1. A team member creates a branch and modifies a policy in HCL 2. They open a pull request. The CI pipeline runs `terraform plan` and posts the policy diff as a PR comment 3. The security team reviews the policy change alongside the code change 4. The PR is merged. The CD pipeline runs `terraform apply` and the policy is live

Every policy change is tracked in version control. Every change has a reviewer. Every change can be rolled back with a revert commit. The policy configuration is always in sync with the repository because the repository is the source of truth.

State Management

The Intended Terraform provider supports remote state backends. For teams using Terraform Cloud or Terraform Enterprise, the Intended resources integrate with your existing state management. For teams using S3 or GCS backends, the same approach works.

The provider supports `terraform import` for bringing existing policies under Terraform management. If you created policies through the console or API, you can import them into your Terraform state without disrupting the running configuration:

bash

terraform import meritt_policy.staging_deploy_allow policy_abc123

Drift Detection

The provider detects configuration drift on every `terraform plan`. If someone modified a policy through the console (outside of Terraform), the plan will show the difference. You can then decide whether to adopt the console change into your HCL or revert it by applying the Terraform configuration.

This is important for governance of governance. The policies that control AI agent behavior should themselves be under strict change management. Terraform provides that change management natively.

Your infrastructure is code. Your authority should be code too. The Intended Terraform provider brings policies, agents, escalation workflows, and domain packs into the same version-controlled, peer-reviewed, continuously-deployed workflow that your infrastructure already uses.