Infrastructure for autonomous Claude Code
This is page 24 of the Claude Code tutorial series. Before you let an agent run unattended against your codebase, five pieces of infrastructure must be in place:
Secrets management
Never hardcode API keys. Use Vault, AWS Secrets Manager, or equivalent.
Audit trails
Log every action with actor, timestamp, files changed, and commands run.
Spend controls
Set per-team and per-workflow spend caps at the API level.
Access boundaries
Apply minimum-permission scoping to every agent.
Monitoring
Track success rate, task duration, and cost per task type.
Multi-provider architecture
For enterprise resilience and data residency, point Claude Code at more than one provider. Bedrock and Vertex AI keep data inside your cloud boundary — ideal for regulated industries — while the Anthropic API stays the primary path.
# Primary: Anthropic API
ANTHROPIC_API_KEY=sk-ant-...
# Fallback: AWS Bedrock (no data leaves your VPC)
AWS_DEFAULT_REGION=us-east-1
ANTHROPIC_BEDROCK_BASE_URL=https://bedrock-runtime.us-east-1.amazonaws.com
# Alternative: Google Vertex AI
ANTHROPIC_VERTEX_PROJECT_ID=your-project
CLOUD_ML_REGION=us-east5Security hardening
Two settings do most of the work: a list of protected paths Claude can never modify, and a command allowlist that bounds what production agents may run. Note that protecting .github/workflows/ stops an agent from modifying its own CI — see the Claude Code in CI/CD tutorial for the pipeline side of this.
Protected paths
{
"permissions": {
"protectedPaths": [
".env",
".env.*",
"*.pem",
"*.key",
"secrets/",
".github/workflows/"
]
}
}Command allowlist
{
"permissions": {
"allowedCommands": [
"npm test",
"npm run build",
"npm run typecheck",
"git status",
"git diff",
"git log"
]
}
}Observability
A PostToolUse hook can append a structured audit record after every action — the foundation for compliance logging and dashboards.
# Hook for audit logging every action
"PostToolUse": [
{
"command": "echo '{\"timestamp\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\", \"tool\": \"${tool_name}\", \"file\": \"${file_path}\", \"session\": \"${session_id}\"}' >> /var/log/claude-audit.json"
}
]Wire that into your existing observability stack:
- Send session summaries to Datadog, Splunk, or CloudWatch
- Dashboard: tasks attempted, tasks succeeded, average cost per task type, error rates
- Alert on unusually long sessions (possible infinite loops), high spend rate, and permission denials
Governance model
Define policy in four layers, from locked org-wide rules down to individual developer preferences:
Organization policy locked
Tools and paths that are absolutely off-limits. Enforced by managed settings.
Team policy team-admin configurable
What this team's agents may do. Also enforced by managed settings.
Project policy CLAUDE.md
Project-specific conventions, handled in CLAUDE.md.
User preferences developer configurable
Personal preferences within the team's bounds, set in user settings.
Designing for failure
Every autonomous workflow must have an answer for each failure mode:
| What if… | Your answer |
|---|---|
| The agent gets stuck in a loop | Set max iteration limits via --max-turns in non-interactive mode |
| Changes break the build | Use hooks that run tests after every edit and abort on failure |
| The API is unavailable mid-task | git stash as a pre-task checkpoint, git stash pop on failure |
| A whole run fails | All changes go to a PR branch, never directly to main |
Notes
Agents can modify their own guardrails
If an agent can edit .github/workflows/ or settings.json, it can widen its own permissions. Protect those paths explicitly — pair with the CI/CD lesson for pipeline-side checks.
Multi-provider routing needs fallbacks
Bedrock and Vertex outages happen. Define a degraded mode — queue work, switch model tier, or fail closed — instead of infinite retries that burn budget and leave repos half-changed.
Observability is not optional
Log session IDs, model, token usage, and every tool invocation. When an autonomous agent ships a bad commit at 2 AM, you need a trace — not a guess from the final diff.
Never land directly on main
Production agents should always open a branch and PR. Branch protection plus required human review is the minimum bar; auto-merge without review is how incidents become regressions.
Production Deployment FAQ
How should I manage secrets when running Claude Code in production?
Never hardcode API keys. Use a managed secrets store such as Vault, AWS Secrets Manager, or an equivalent so credentials are never committed to the codebase.
How do I set up a multi-provider architecture for Claude Code?
Point Claude Code at more than one provider for resilience and data residency. Keep the Anthropic API as the primary path, and add AWS Bedrock or Google Vertex AI as fallbacks so data stays inside your cloud boundary.
What security hardening does a production Claude Code agent need?
Two settings do most of the work: a list of protected paths Claude can never modify, such as .env files, keys, and .github/workflows/, and a command allowlist that bounds what production agents may run.
How do I add observability and monitoring to autonomous Claude Code runs?
A PostToolUse hook can append a structured audit record after every action. Send session summaries to Datadog, Splunk, or CloudWatch, dashboard tasks attempted, succeeded, and cost per task type, and alert on unusually long sessions, high spend rate, and permission denials.
How do I control costs for production Claude Code workflows?
Set per-team and per-workflow spend caps at the API level, track cost per task type in your monitoring dashboards, and alert on a high spend rate so runaway runs are caught early.
Quick summary
- Production agents need managed secrets, audit trails, spend caps, scoped access, and monitoring
- Use Bedrock or Vertex as fallbacks to keep data inside your cloud boundary
- Harden with protected paths and command allowlists; audit every action via a PostToolUse hook
- Govern in four policy layers and design explicit answers for loops, broken builds, outages, and rollback