The ten disciplines of governed agentic DevSecOps
Claude Code accelerates engineering work. It should never be the thing that decides whether its own work is safe to ship. These ten disciplines are the recurring control points that show up, in one form or another, in every part of an enterprise deployment of a coding agent — repository to production. Adapted from Andrew Clark's Enterprise Agentic DevSecOps Handbook (August 2026 edition).
1. Architecture rule
Keep reasoning separate from authority. A language model may recommend a tool call, but the tool contract, identity, policy engine, network path, and target system determine whether that call can execute. For enterprise implementations, map the control to a named service, IAM principal, log source, and deployment gate. That makes the architecture reviewable and testable rather than dependent on prompt wording.
2. Claude Code workflow
Start with repository discovery. Read CLAUDE.md and existing build instructions. Inspect the relevant files before changing them. Produce a plan. Make the minimum change. Run deterministic validation. Present the diff and evidence for review. Claude Code should return evidence from the repository and validation commands — a confident natural-language answer is not evidence that a build, policy check, or deployment is correct.
# CLAUDE.md
- Preserve existing enterprise security and CI workflows.
- Reuse established Terraform modules and repository patterns.
- Run tests and terraform validate before proposing a pull request.
- Do not modify IAM, production, or protected deployment controls without approval.
- Summarize changed files, validation output, remaining risks, and rollback steps.3. Repository controls
Protect security workflows, deployment definitions, shared modules, generated artifacts, and sensitive configuration. Do not allow the agent to rewrite enterprise guardrails simply to make a build pass.
| Control | Enterprise implementation | Evidence |
|---|---|---|
| Identity | Dedicated IAM role or workload identity | CloudTrail / auth logs |
| Code change | Claude Code through reviewed pull request | Git diff + reviewer |
| Validation | CI tests, IaC and security scans | Build reports |
| Tool invocation | AgentCore Gateway / MCP target | Trace + policy result |
| Production | Approval-gated deployment | Deployment + health events |
4. Identity boundary
Use workload identities and short-lived credentials. Separate inbound user authentication from the agent's outbound authorization to tools and resources. Do not inherit a developer's broad interactive permissions by default.
5. Tool design
Prefer narrow, typed tools over unrestricted administrative shells. A good tool has a clear purpose, constrained arguments, predictable output, timeout behavior, and auditable authorization.
Implementation note: do not expose a generic shell or broad AWS administrator role just because it is convenient during a pilot. Convenience permissions tend to survive into production and defeat the entire control model.
6. Validation
Use unit tests, integration tests, terraform fmt/validate/plan, policy-as-code, SAST, SCA, container scanning, secrets scanning, and artifact integrity checks as independent gates. None of them defer to the agent's own assessment of its work.
7. Approval
Human approval should occur at a meaningful boundary. Show the exact proposed action, affected resources, policy result, validation evidence, and rollback plan before requesting authorization.
8. Observability
Capture model invocation, tool call, identity, policy decision, tool result, deployment event, and health signal. Operators should be able to reconstruct the complete execution path — not just read a chat transcript.
| Control | Enterprise implementation | Evidence |
|---|---|---|
| Identity | Dedicated IAM role or workload identity | CloudTrail / auth logs |
| Code change | Claude Code through reviewed pull request | Git diff + reviewer |
| Validation | CI tests, IaC and security scans | Build reports |
| Tool invocation | AgentCore Gateway / MCP target | Trace + policy result |
| Production | Approval-gated deployment | Deployment + health events |
9. Failure handling
Design retries, timeouts, circuit breakers, idempotency, dead-letter handling, and rollback independently of the model. Non-deterministic reasoning should sit inside deterministic operational boundaries.
10. Production criterion
A workflow is production-ready only when permissions are bounded, validation is repeatable, rollback is tested, evidence is retained, and performance is measured against a human-only baseline.
Chapter checkpoint
- Named owner and business outcome
- Documented trust boundary and data path
- Scoped workload identity and explicit tool inventory
- Independent validation and security gates
- Human approval for high-consequence actions
- Observable execution, rollback, and retained evidence
These ten disciplines repeat across every domain of a governed agentic platform — see Fourteen domains of the governed agentic platform for where each one shows up, and the 30-day challenge for a day-by-day way to apply them to your own repository.