What You Will Build
- A deployment agent that gates production releases with multi-party approval
- Database migration management with DBA sign-off
- Firewall rule changes with teach-back verification
- Rollback protection that prevents panic-driven emergency changes
- Both Python and TypeScript implementations using LangGraph
Configuration
Create anattesta.yaml in your project root:
attesta.yaml
A custom infrastructure domain profile might set a
production_multiplier of 1.6. A deployment scored at 0.55 (MEDIUM) in staging would then become 0.88 (CRITICAL) in production, triggering multi-party approval. This is intentional — the same operation carries fundamentally different risk in production. See Custom Domains for how to create your own domain profile.Python Implementation
Define the infrastructure tools
Each function is gated by Attesta. A custom domain profile can be configured to detect deployment operations, database commands, firewall changes, and privilege escalation.
infra_agent.py
Build the agent loop with LangGraph
This agent uses LangGraph with Attesta inserted as a gate node between the agent and tool execution.
infra_loop.py
TypeScript Implementation
Expected Terminal Output
Scenario 1: Service Status (LOW — auto-approved)
Read-only status check. No deployment or destructive patterns match. Auto-approved silently.| Field | Value |
|---|---|
| Risk Level | LOW |
| Action | get_service_status |
| Risk Score | 0.10 |
| Domain | custom (SOC 2) |
| Result | AUTO-APPROVED |
Scenario 2: Staging Deployment (MEDIUM — confirm)
Thedeploy keyword triggers the deployment pattern (contribution: 0.8), but the staging environment hint keeps the risk in MEDIUM range. A simple confirmation is required.
| Field | Value |
|---|---|
| Risk Level | MEDIUM |
| Action | deploy_to_staging |
| Risk Score | 0.42 |
| Domain | custom (SOC 2) |
| Arguments | service="api-gateway", version="2.1.0", strategy="rolling" |
| Challenge | CONFIRM (min review: 3s) |
| Prompt | Deploy api-gateway v2.1.0 to staging? [y/N] y |
| Result | APPROVED (reviewed in 4.2s) |
Scenario 3: Production Deployment (CRITICAL — multi-party)
The samedeploy function name, but with the production: True hint, triggers the production multiplier (1.6x). The combined score crosses into CRITICAL, requiring dual approval from the SRE lead and release manager.
| Field | Value |
|---|---|
| Risk Level | CRITICAL |
| Action | deploy_to_production |
| Risk Score | 0.88 |
| Domain | custom (SOC 2) |
| Arguments | service="api-gateway", version="2.1.0", strategy="canary", canary_percentage=10, change_ticket="CHG-2026-0042" |
| Escalation | Production deployment |
| Notified | sre_lead, release_manager |
| Challenge | MULTI-PARTY (2 of 2 required) |
Deploying api-gateway v2.1.0 to production with a 10% canary rollout under change ticket CHG-2026-0042. This will update 1 of 10 instances initially. Approved (48.2s)Approver 2 (release.mgr@company.com) — QUIZ:
Q1: Which service is being deployed? api-gateway Q2: What is the change ticket? CHG-2026-0042 Approved (35.4s)Result: APPROVED (2/2 approvers, total 83.6s)
Scenario 4: Database Migration (CRITICAL — multi-party)
Therun_migration function is overridden to CRITICAL risk. A custom domain’s schema migration escalation rule can require DBA and backend lead approval.
| Field | Value |
|---|---|
| Risk Level | CRITICAL |
| Action | run_migration |
| Risk Score | 0.91 |
| Domain | custom (SOC 2) |
| Arguments | migration_file="20260213_add_user_preferences.sql", database="primary", environment="production" |
| Escalation | Schema migration |
| Notified | dba, backend_lead |
| Challenge | MULTI-PARTY (2 of 2 required) |
Running migration 20260213_add_user_preferences.sql on the primary production database. This will alter the users and orders tables to add preference columns. Approved (55.1s)Approver 2 (backend.lead@company.com) — QUIZ:
Q1: Which database is affected? primary Q2: Is this migration reversible? No (DDL) Approved (41.3s)Result: APPROVED (2/2 approvers, total 96.4s)
Scenario 5: Emergency Rollback (HIGH — quiz)
Rollbacks are emergency operations. Despite the urgency, Attesta requires a quiz challenge to verify the operator understands the rollback impact. The 15-second minimum review prevents panic-driven approvals.| Field | Value |
|---|---|
| Risk Level | HIGH |
| Action | rollback_deployment |
| Risk Score | 0.72 |
| Domain | custom (SOC 2) |
| Arguments | service="api-gateway", target_version="2.0.3", reason="v2.1.0 causing 502s on /api/checkout" |
| Challenge | QUIZ (min review: 15s) |
Q1: Which version will the service revert to? 2.0.3 — Correct Q2: What is the reported issue? 502 errors on the checkout endpoint — Correct Q3: How many production instances will be reverted? All 10 — CorrectResult: APPROVED (reviewed in 23.7s)
Scenario 6: Firewall Rule Change (HIGH — teach-back)
Firewall changes trigger the custom domain’s firewall modification escalation rule, requiring teach-back verification. The security engineer and network admin are notified.| Field | Value |
|---|---|
| Risk Level | HIGH |
| Action | modify_firewall_rule |
| Risk Score | 0.78 |
| Domain | custom (SOC 2) |
| Arguments | rule_id="FW-PROD-001", action="allow", protocol="TCP", port=443, cidr="10.0.0.0/8", direction="ingress" |
| Escalation | Firewall modification |
| Notified | security_engineer, network_admin |
| Challenge | TEACH-BACK (min review: 15s) |
Explain what this firewall change will do: This will allow inbound TCP traffic on port 443 from the 10.0.0.0/8 CIDR range (internal network) through firewall rule FW-PROD-001. This opens HTTPS access from internal services to the production environment. Key terms matched: allow, TCP, 443, 10.0.0.0/8, ingressResult: APPROVED (reviewed in 34.8s)
Audit Trail
After running the scenarios, the audit log at.attesta/infra-audit.jsonl contains entries for every operation:
Risk Level Summary
| Function | Risk Level | Challenge | Key Trigger |
|---|---|---|---|
get_service_status | LOW | Auto-approve | Read-only status check |
list_recent_deployments | LOW | Auto-approve | Read-only history |
deploy_to_staging | MEDIUM | Confirm (3s) | Deploy pattern + staging environment |
deploy_to_production | CRITICAL | Multi-party, 2 approvers (45s) | Deploy pattern + production multiplier (1.6x) |
rollback_deployment | HIGH | Quiz (15s) | Rollback pattern + emergency hint |
run_migration | CRITICAL | Multi-party, 2 approvers (45s) | Risk override + schema migration escalation |
modify_firewall_rule | HIGH | Teach-back (15s) | Firewall pattern + security boundary hint |
rotate_credentials | HIGH | Quiz (15s) | Credential management pattern |
Compliance Mapping
| Framework | Attesta Mechanism |
|---|---|
| SOC 2 CC6.1 — Logical access security | Access control patterns flag permission and credential changes |
| SOC 2 CC7.2 — Monitoring system components | Audit trail records all infrastructure operations |
| SOC 2 CC8.1 — Change management | Multi-party approval for production deployments and migrations |
| ISO 27001 A.9 — Access control | Credential rotation and permission changes require verification |
| ISO 27001 A.12 — Operations security | Production multiplier escalates risk for live environment changes |
| ISO 27001 A.13 — Communications security | Firewall patterns with teach-back challenges |
Next Steps
Custom Domain Profiles
Build your own domain-specific risk profiles
Multi-Framework
Same config across LangChain, OpenAI, and Claude
LangChain Integration
Full LangChain and LangGraph reference