I've published a community provider, frank-bee/anthropic (v0.7.0), that wraps Anthropic's platform and management APIs. To be clear up front: it's a personal/community project, not official and not endorsed by Anthropic.

It's on the Registry, so the usual snippet works:

terraform {
 required_providers {
  anthropic = {
    source  = "frank-bee/anthropic"
    version = "~> 0.7"
  }
 }
}

provider "anthropic" {
  # api_key via ANTHROPIC_API_KEY, or oauth_token via ANTHROPIC_OAUTH_TOKEN for     org-admin resources
}

Resources currently covered:

• Managed Agents — anthropic_agent, anthropic_skill, anthropic_environment, anthropic_deployment
• Admin — anthropic_workspace, anthropic_workspace_member, anthropic_organization_invite
• Workload identity federation — anthropic_service_account, anthropic_federation_issuer, anthropic_federation_rule
• anthropic_vault (credential storage referenced by deployments) and anthropic_memory_store
• Single-item data sources for the above, plus list data sources for agents/skills/environments/workspaces/users

A caveat I'd rather state than hide: the federation resources and the vault/memory-store resources are marked experimental. The WIF endpoints need an org:admin OAuth token my CI doesn't have, so their acceptance tests skip (verified against the spec, not end-to-end); the vault/memory-store wire shapes were probed from the live API. The rest is acceptance-tested against the real API.

The federation resources are the reason I built it. You register an OIDC issuer, write a rule that matches JWT claims (e.g. a specific repo:org/repo:ref:refs/heads/main subject from GitHub Actions), and point it at a service account — so CI gets short-lived Anthropic credentials with no static keys in secrets:

resource "anthropic_federation_issuer" "github_actions" {
  name       = "github-actions"
  issuer_url = "https://token.actions.githubusercontent.com"
  jwks       = { type = "discovery" }
}

resource "anthropic_federation_rule" "gha_deploy" {
  name      = "gha-deploy"
  issuer_id = anthropic_federation_issuer.github_actions.id
  match = {
    subject_prefix = "repo:my-org/my-repo:ref:refs/heads/main"
    claims         = { repository_owner = "my-org" }
  }
  target                 = { service_account_id = anthropic_service_account.inference_worker.id }
  workspace_id           = "wrkspc_xxxxx"
  oauth_scope            = "workspace:developer"
  token_lifetime_seconds = 600
}

Built on terraform-plugin-framework, MIT-licensed, client generated from an OpenAPI spec with oapi-codegen. As far as I can tell this is the most complete community coverage of Anthropic's management APIs available as Terraform right now, but I'd be happy to be pointed at gaps.

Issues and PRs welcome: https://github.com/frank-bee/terraform-provider-anthropic

A peer that likes to use -target in repositories and forces you to play minefield when you get a ticket to touch any resources in it?

Had a plan apply something last week that it really should not have. A chunk of our Terraform got written by an assistant, looked completely normal in the diff, and it had a security group wide open to the world on a port that had no reason to be public. No one caught it in review because it reads clean. The guy who prompted it did not clock the CIDR and neither did whoever approved the PR.

We caught it in staging and not prod, but only because someone happened to look twice.

Now I am wondering what the rest of you do for Terraform security scanning now that half our modules are getting drafted by AI. Do you gate the plan on something automated before it can apply, policy checks, a scanner, anything?