Terraform

Declare policies, agent identities, and approval groups as code with the Cirvix provider, and apply them through the same pipeline as everything else.

The provider manages the control-plane objects that would otherwise be edited by hand in a dashboard — useful specifically because it puts policy changes through the same review and apply pipeline as your infrastructure.

Provider configuration

main.tf

terraform {  required_providers {    cirvix = {      source  = "cirvix/cirvix"      version = "~> 0.9"    }  }} provider "cirvix" {  api_key = var.cirvix_api_key}

Resources

Resource	Manages
`cirvix_policy`	A JSON rule set, versioned and diffable
`cirvix_agent_identity`	An agent's owner, scopes, and environments
`cirvix_approval_group`	Who can grant a hold, and the channel it routes to
`cirvix_mcp_server`	A registered MCP server and its per-agent tool scope

policies.tf

resource "cirvix_policy" "deny_dotenv" {  name   = "deny-dotenv-read"  source = file("${path.module}/policies/deny-dotenv-read.json")} resource "cirvix_agent_identity" "pr_triage" {  name        = "pr-triage"  owner_email = "priya@example.com"  scopes      = ["repo:read", "issues:read", "slack:post"]  environments = ["staging"]}

Plan and apply

TerminalShell

$ terraform init$ terraform plan$ terraform apply

A `destroy` on a guardrail policy is enforcement, not cleanup

Running terraform destroy against a cirvix_policy resource removes that rule's enforcement immediately. Because the rule set is default-deny, removing a permit fails closed on its own — but removing a forbid guardrail like deny-dotenv-read opens exactly the door it existed to close. Keep guardrail rules in a separately-reviewed module from ordinary permits.

KubernetesPair provider-managed policy with a chart-managed gateway.Self-hosted / VPCThe full deployment this usually feeds into.

Edit this page on GitHub

Was this page helpful?