Phase 1 — Agent Environment Reconstruction The organization operates AI coding agents as development assistants with repository, terminal, testing, and PR capabilities. Potential Impact Areas Area Agent Access Risk Source code Read/Write 🟡 Controlled Tests Read/Write 🟢 Low Documentation Read/Write 🟢 Low Terminal Yes 🟡 Controlled Package installation Yes 🟡 Controlled CI/CD Indirect 🟡 Controlled Terraform Write through PR 🟠 High Secrets No direct access 🟢 Low Production DB No access 🟢 Low Production infrastructure No direct access 🟢 Low External APIs Restricted credentials 🟡 Controlled PR creation Yes 🟢 Low PR merge No default access 🟢 Low Production deployment No autonomous access 🔴 Restricted Environment conclusion: The safest design is to give agents substantial autonomy inside development repositories while keeping production, credentials, infrastructure changes, and sensitive business logic behind enforceable controls. --- Phase 2 — Agent Capability Classification Capability Classification Policy Read source code 🟢 Low Risk Autonomous Modify normal application code 🟢 Low Risk Autonomous Modify tests 🟢 Low Risk Autonomous Modify documentation 🟢 Low Risk Autonomous Create branch 🟢 Low Risk Autonomous Run tests 🟢 Low Risk Autonomous Install development packages 🟡 Controlled Allow with scanning Execute terminal commands 🟡 Controlled Sandbox + command controls Modify CI/CD 🟠 High Risk Human review Modify Terraform 🟠 High Risk Human approval Modify authentication 🟠 High Risk Security-aware review Modify authorization 🟠 High Risk Explicit approval Database writes 🟠 High Risk Non-production only Production database access 🔴 Restricted Prohibited Production infrastructure access 🔴 Restricted Prohibited Read secrets 🔴 Restricted Prohibited by default Create PR 🟢 Low Risk Autonomous Merge sensitive PR 🔴 Restricted Human approval Production deployment 🔴 Restricted Human-controlled --- Phase 3 — Code Modification Policy 🟢 AUTONOMOUS Agents may modify: Application business logic that is not security-sensitive Unit tests Integration tests Documentation Developer tooling Non-production configuration Formatting and linting configuration Internal utility code Conditions: Changes remain on an agent-created branch. Tests must run successfully. Security scanning must pass. Agent identity must be recorded. --- 🟡 REVIEW REQUIRED Human review is mandatory for: Dependency upgrades CI configuration Build configuration API contracts Shared libraries Configuration affecting multiple services Significant refactoring Performance-sensitive code The agent can prepare the complete change, but the PR cannot merge until required reviewers approve it. --- 🟠 APPROVAL REQUIRED Explicit approval is required for: Authentication Authorization IAM configuration Terraform infrastructure Database migrations Payment/billing logic Security controls Production configuration Compliance-related controls Permission changes --- 🔴 PROHIBITED Agents must not directly modify: Production infrastructure Production secrets Production IAM credentials Production database records Security monitoring configuration Organization-level access-control policies Emergency security controls without authorized human intervention --- Phase 4 — Protected Resource Rules Resource Why Protected Approver Required Evidence Authentication Account compromise risk Senior engineer/security reviewer Tests + security review Authorization Privilege escalation risk Security/engineering owner Authorization tests IAM Cloud privilege escalation Cloud/security owner Terraform plan + review Database migration Data integrity risk Database owner Migration test + rollback plan Payment logic Financial impact Engineering + business owner Tests + impact analysis CI/CD Supply-chain risk Senior engineer Pipeline validation Production config Service availability On-call/engineering owner Deployment validation Emergency Procedure For a critical incident: 1. Human incident commander authorizes the emergency action. 2. Agent access is temporarily elevated only if technically necessary. 3. All commands and changes are logged. 4. Credentials are short-lived. 5. Changes receive retrospective review. 6. Temporary permissions are immediately revoked. --- Phase 5 — Production Access Policy Development Agents may: Read/write code Execute commands Run tests Install packages Use non-production services Access synthetic/test data Autonomy: HIGH Test Agents may: Deploy through CI Run automated tests Execute approved test operations Use isolated test databases Autonomy: HIGH Staging Agents may: Create deployment artifacts Trigger approved staging deployments Run integration tests Production-equivalent credentials must not automatically be inherited. Autonomy: MEDIUM-HIGH Production Agents: Must not receive standing production credentials. Must not directly modify production data. Must not directly modify production infrastructure. Must not independently deploy production changes. Must not execute arbitrary production shell commands. Autonomy: LOW / HUMAN CONTROLLED --- Phase 6 — Secret Governance The agent architecture should follow: Agent → Short-lived identity → Least-privilege tool → Specific resource rather than: Agent → Long-lived cloud credential → Broad access Rules Agents must not: Print secrets Commit secrets Put secrets in PR descriptions Include secrets in logs Copy credentials into generated documentation Expose environment variables unnecessarily Controls Use AWS Secrets Manager. Prefer short-lived credentials. Scope credentials to specific environments. Automatically scan commits and PRs for leaked secrets. Revoke compromised credentials immediately. Rotate credentials following confirmed exposure. --- Phase 7 — Database Governance Database Action Agent Permission Read test DB ✅ Allowed Write test DB ✅ Allowed with limits Read staging DB 🟡 Controlled Write staging DB 🟡 Controlled Read production DB 🔴 Prohibited by default Write production DB 🔴 Prohibited Modify production schema 🔴 Prohibited autonomously Create migration 🟠 Approval required Agents should use synthetic or sanitized data whenever possible. Database migrations require: Migration test Schema validation Backup/rollback strategy Human approval CI verification --- Phase 8 — External API Governance 🟢 Read-only APIs Agents may call approved APIs for development and testing. Examples: Public documentation APIs Non-sensitive metadata APIs Internal test services 🟡 Low-impact writes Allowed when: Test environment is used Credentials are scoped Rate limits exist Actions are reversible 🟠 Business-impacting APIs Require human review or approval. Examples: Customer account modifications Production configuration changes Operational actions 🔴 Irreversible actions Agents cannot autonomously perform: Financial transactions Permanent deletion of customer resources Irreversible production operations High-value external actions --- Phase 9 — Autonomous PR Creation Agents may create PRs autonomously when: Repository is approved. Source branch is not protected. Required tests pass. Security scans pass. Dependency checks pass. Agent identity is attached. PR includes change summary. PR includes risk classification. PR identifies modified sensitive files. PR must contain Agent: Agent Version: Initiating Developer: Repository: Branch: Change Summary: Risk Level: Files Modified: Tests Executed: Security Checks: External Side Effects: Human Approval Required: Agents cannot create autonomous PRs that bypass branch protection. --- Phase 10 — Autonomous Merge Governance 🟢 AUTO-MERGE Potentially allowed for: Documentation Formatting Non-sensitive test changes Low-risk internal tooling Mechanical refactoring Requirements: CI passes Security scan passes Dependency scan passes No protected files modified No unresolved review comments Branch protection remains active 🟡 HUMAN REVIEW Required for: Application behavior changes Dependencies Shared libraries CI/CD changes 🟠 EXPLICIT APPROVAL Required for: Database migrations Infrastructure Authentication Authorization Payment logic Security controls 🔴 NEVER AUTONOMOUSLY MERGE Production access changes IAM privilege escalation Secret-management changes Critical security controls Emergency production changes --- Phase 11 — Human Approval Gates Change Who Approves When Normal application code Code owner Before merge Dependency upgrade Engineering reviewer Before merge Authentication Security/code owner Before merge Authorization Security owner Before merge Terraform Infrastructure owner Before merge Database migration Database owner Before merge Payment logic Engineering + designated owner Before merge Production deployment Authorized release owner Before deployment IAM changes Security/cloud owner Before merge Approval must happen before the high-impact action, not after it. --- Phase 12 — Agent Identity Every agent receives a unique identity such as: agent-id: coding-agent-042 agent-version: 3.7 model: approved-model-version initiator: developer-identity repository: payments-api branch: agent/fix-validation environment: development timestamp: recorded Agent actions must never appear as if they were performed directly by the human developer. This provides accountability for: Human → Agent → Tool → Action → Result --- Phase 13 — Audit Logging The organization should capture: Agent identity Human initiator Model/version Tool configuration Repository Branch Commit Timestamp Environment Commands File changes PR creation Approvals Merge Deployment Database operations External API actions Permission changes Logs should be: Access-controlled Tamper-resistant Searchable Retained according to organizational policy Available for incident investigation --- Phase 14 — Incident Response DETECT Detect: Credential exposure Unexpected production access Suspicious commands Prompt injection Unauthorized file changes Abnormal API activity DISABLE Immediately disable: Agent session Agent identity Tool permissions Relevant credentials CONTAIN Stop affected workflows. Revoke active credentials. Block suspicious deployments. Freeze high-risk changes. INVESTIGATE Determine: What agent acted? Who initiated it? What tools were used? What files/resources changed? What credentials were exposed? What systems were affected? RECOVER Restore affected systems. Rotate credentials. Revert unsafe commits. Validate infrastructure and data integrity. REVIEW Perform: Root-cause analysis Policy review Agent configuration review Control improvement Retrospective approval review --- Phase 15 — Governance Maturity Current Assessment: 🟡 Governed The organization already has: Protected branches CI/CD Security scanning Environment separation Secrets management Production approval The main opportunity is making agent-specific controls enforceable and attributable. 0–30 Days Control Risk Addressed Owner Effort Enforcement Success Remove production credentials Unauthorized production access Cloud/Security Low IAM Zero standing agent prod credentials Define protected paths Sensitive modifications Engineering Low Repository rules Protected paths enforced Agent identity Attribution Platform Medium IAM Every action attributable Emergency disable Agent compromise Security Low IAM Agent can be disabled rapidly 31–90 Days Add agent-aware PR metadata. Enforce sensitive-file approval. Centralize agent audit logs. Add secret scanning. Strengthen branch protection. Implement tool-level permissions. 3–6 Months Automated change-risk classification. Policy-as-code. Automatic detection of protected-resource modifications. Automated approval routing. Agent behavior monitoring. 6–12 Months Continuous governance evaluation. Advanced anomaly detection. Dynamic agent permissions. Automated credential revocation. Continuous compliance reporting. --- Phase 16 — Final Enterprise Coding Agent Governance Policy 1. Purpose & Scope This policy governs AI coding agents operating within the organization's software development lifecycle. Its purpose is to maximize useful agent autonomy while maintaining security, accountability, traceability, reliability, and human control. --- 2. Agent Classification Level 1 — Development Agent May independently: Read/write approved code Run tests Create branches Create PRs Level 2 — Controlled Engineering Agent May perform additional operations subject to: Sandboxing CI validation Human review Restricted credentials Level 3 — High-Impact Agent May prepare infrastructure, database, security, or deployment changes but requires explicit human approval. Level 4 — Restricted Agent Cannot independently perform production, privilege-escalation, secret-management, or irreversible operations. --- 3. Access Control Policy All agent access follows: Least privilege + environment isolation + short-lived credentials + explicit authorization. No production access is granted by default. --- 4. Code Modification Policy Agents may autonomously modify low-risk application code, tests, documentation, and approved tooling. Human review is required for significant behavioral or shared-system changes. Explicit approval is required for security, infrastructure, database, payment, authorization, and production-sensitive changes. --- 5. Production Policy Agents have no standing production access. Production actions require an approved human-controlled workflow. --- 6. Secret Management Policy Agents must not receive secrets unless technically necessary. When access is unavoidable: Use least privilege. Use short-lived credentials. Scope by environment/resource. Log access. Prevent secret disclosure. Rotate exposed credentials. --- 7. Database Access Policy Development and test databases may be accessible within defined limits. Production database access is prohibited by default. Production schema modifications and migrations require explicit approval. --- 8. External API Policy Agents may use approved low-risk APIs. Business-impacting and irreversible operations require stronger controls. External actions must use: Scoped credentials Rate limits Idempotency where applicable Logging Approval for high-impact operations --- 9. Autonomous PR Policy Agents may create PRs autonomously when all repository, testing, security, branch, and risk-classification requirements are satisfied. Creating a PR does not grant merge authority. --- 10. Autonomous Merge Policy Auto-merge is limited to low-risk changes satisfying all automated controls. Sensitive, security, infrastructure, database, payment, authorization, and production-related changes require human approval. --- 11. Human Approval Gates Human approval is mandatory before: Sensitive code changes Production changes Database migrations IAM changes Security changes Infrastructure modifications Permission changes High-impact external actions Irreversible operations --- 12. Agent Identity Policy Every agent action must be independently attributable to: Agent + Version + Human Initiator + Tool + Repository + Commit + Environment + Timestamp --- 13. Audit Logging Policy High-impact agent actions must generate tamper-resistant audit records. Auditability must cover the complete lifecycle: Request → Agent → Tool → Change → Review → Approval → Merge → Deployment --- 14. Incident Response Policy Any suspected agent compromise or policy violation triggers: DETECT → DISABLE → CONTAIN → INVESTIGATE → ROTATE → RECOVER → REVIEW Agent disablement and credential revocation must be technically executable without relying on the agent cooperating. --- 15. Enforcement Architecture The policy should be enforced through multiple independent layers: IAM Controls: Agent identity Permissions Credential lifetime Environment access Repository Controls Controls: Protected branches CODEOWNERS Sensitive paths Merge permissions CI/CD Controls: Tests SAST Dependency scanning Secret scanning Infrastructure validation Deployment approvals Tool Permissions Controls: Terminal access Database access API access Cloud operations Secrets Management Controls: Credential issuance Rotation Revocation Secret isolation Runtime Controls Controls: Sandboxing Network access Command restrictions Resource limits Audit System Controls: Agent activity recording Investigation Alerting Compliance evidence Critical principle: Policy must not depend solely on the agent following instructions. Technical enforcement must exist outside the agent. --- 16. Governance Decision Matrix Action Agent Allowed Human Review Explicit Approval Prohibited Read source code Yes No No No Modify normal application code Yes As required No No Modify tests Yes No No No Modify documentation Yes No No No Create branch Yes No No No Run development tests Yes No No No Install package Yes Sometimes No No Modify CI/CD Yes Yes Sometimes No Modify Terraform Prepare only Yes Yes No Modify authentication Prepare only Yes Yes No Modify authorization Prepare only Yes Yes No Create DB migration Prepare only Yes Yes No Write test database Yes No No No Write production database No No No Yes Access production secrets No No No Yes Create PR Yes No No No Merge low-risk PR Limited Automated gates No No Merge security-sensitive PR No Yes Yes No Deploy production No Yes Yes No Modify production IAM No Yes Yes No Perform irreversible production action No Yes Yes Yes for autonomous execution --- 🚦 Final Autonomy Recommendation Maximum Safe Autonomy: HIGH in Development, CONTROLLED in Staging, LOW in Production Agents can independently Write normal application code Create tests Refactor low-risk code Fix bugs Update documentation Run development tests Create branches Create PRs Perform approved development-environment operations Agents require human review for Dependencies CI/CD Shared libraries Significant application behavior API contracts Infrastructure changes Agents require explicit approval for Authentication Authorization IAM Database migrations Payment logic Security controls Production configuration High-impact external actions Agents must never autonomously Access production secrets Write production database data Modify production infrastructure Escalate permissions Bypass branch protection Disable security controls Execute irreversible high-impact production operations Core governance principle: > Give the agent maximum autonomy where mistakes are cheap, reversible, isolated, and observable. Add human control where mistakes can affect security, money, customer data, availability, or irreversible state.