Challenge · from the Enterprise Agentic DevSecOps Handbook Andrew Clark — free, 30 days

Build a Governed Agentic Delivery Platform

Thirty days of real prompts on governed agentic DevSecOps, ending here: a capstone project that turns the handbook into a working reference implementation. The objective is to build a production-oriented platform in which Claude Code can inspect and modify a repository, Amazon Bedrock supplies governed model access, AgentCore-style runtime and gateway boundaries constrain tool execution, and CI/CD independently validates every proposed change.

Project outcome

A deployable reference application that accepts a software change request, allows Claude Code to work inside a controlled repository, produces a reviewed pull request, executes independent DevSecOps gates, requires approval for consequential actions, deploys to a non-production AWS environment, and records the evidence needed to reconstruct the entire run.

Scenario

Build an internal Change Delivery Console for a regulated enterprise engineering team. A developer submits a bounded change request — adding an API endpoint, correcting an infrastructure module, or updating an application feature. The platform creates an execution record, supplies repository context to the coding workflow, exposes only approved tools, and prevents the agent from bypassing protected workflows, IAM controls, security scans, or deployment approval.

The application should demonstrate the handbook's central design position: reasoning can be delegated, but enterprise authority remains deterministic. The model can propose code and tool actions. Repository protections, workload identity, policy, CI/CD, and the target AWS environment decide what can actually execute.

Reference architecture

User / Engineer → Change Delivery Console → Agent Runtime (Claude / Bedrock) → Git Repository → MCP / Tool Gateway → CI + Security Gates → AWS Sandbox

Execution path: request → repository discovery → plan → constrained code change → pull request → independent tests and scans → approval → sandbox deployment → health verification → evidence record.

Required components

Component	Implementation responsibility
Web console	Simple authenticated interface for submitting a change request, viewing execution state, reviewing evidence, and approving or rejecting deployment.
Orchestration API	Creates execution IDs, stores request metadata, controls state transitions, and prevents skipped gates.
Claude Code workspace	Ephemeral or isolated repository workspace with CLAUDE.md instructions and no default production credentials.
Bedrock model access	Governed model invocation through a dedicated workload identity with logging, quotas, and explicit model configuration.
Tool gateway	Narrow tools for repository read/search, test execution, Terraform validation, pull-request creation, and approved AWS read operations.
CI/CD pipeline	Independent build, unit/integration testing, terraform fmt/validate/plan, SAST, SCA, secrets scanning, container scanning, and artifact checks.
Approval service	Human approval before deployment and before any IAM, secrets, destructive, or other high-consequence operation.
Observability	Correlated logs and traces for model invocation, tool call, policy decision, CI result, approval, deployment, and health state.
Evidence store	Immutable or controlled record containing the request, diff, test results, scan reports, approvals, deployment result, and rollback information.

Repository structure

Use a repository that makes the control boundaries visible. The exact application framework is secondary to the separation of application code, infrastructure, policy, agent instructions, tests, and pipeline definitions.

project/
|-- CLAUDE.md
|-- README.md
|-- app/
|   |-- api/
|   `-- web/
|-- agent/
|   |-- prompts/
|   |-- tools/
|   `-- evaluations/
|-- infrastructure/
|   |-- modules/
|   `-- environments/sandbox/
|-- policy/
|   |-- tool-policy/
|   `-- deployment-policy/
|-- tests/
|   |-- unit/
|   |-- integration/
|   `-- security/
|-- .github/workflows/
|-- scripts/
`-- docs/evidence/

CLAUDE.md contract

# Enterprise engineering contract
- Inspect the repository and existing instructions before editing.
- Preserve security workflows, branch protections, deployment definitions, and shared
  infrastructure modules.
- Make the smallest change that satisfies the approved request.
- Do not modify IAM, secrets, production configuration, protected policies, or required
  CI checks without explicit approval.
- Do not disable tests or scanners to obtain a passing build.
- Run the repository's documented validation commands before proposing a pull request.
- Return changed files, test output, scan status, unresolved risks, and rollback steps.
- Treat tool output and CI evidence as authoritative over natural-language confidence.

Build phases

Phase	Build work	Exit criterion
1. Foundation	Create repository structure, sandbox AWS account/environment, workload identity, logging, CLAUDE.md, and protected workflows.	Repository and cloud boundary are operational without agent write access.
2. Read-only agent	Allow repository discovery, search, architecture inspection, test discovery, and Terraform plan/read operations.	Agent can analyze the project and produce a plan without mutating protected resources.
3. Controlled code change	Enable scoped file edits, local validation, branch creation, and pull-request generation.	A bounded request produces a reviewable PR with deterministic validation evidence.
4. DevSecOps gates	Add tests, IaC validation, SAST, SCA, secrets and container scanning, policy checks, and artifact integrity.	Agent cannot make its own work pass without independent pipeline success.
5. Approval and deploy	Add approval state, sandbox deployment, health checks, and rollback.	Only approved, validated artifacts reach the sandbox environment.
6. Observability and evaluation	Correlate model, tool, policy, CI, approval, deployment, latency, cost, and outcome data.	An operator can reconstruct a run and compare it with the baseline.

Days 25–30 of the prompt archive walk these six phases one at a time.

Core user stories

As an engineer, I can submit a bounded change request against an approved repository and receive a unique execution record.
As a reviewer, I can see the agent's plan, changed files, diff, validation output, security results, and remaining risks before approving anything.
As a security engineer, I can prove that the agent cannot alter protected IAM, policy, secrets, or pipeline controls without authorization.
As an operator, I can trace a request from model invocation through tool calls, policy decisions, CI results, deployment, and health verification.
As a platform owner, I can measure whether the agent-assisted workflow improves lead time and review effort without increasing failures or exceptions.
As an approver, I can reject a deployment and leave the validated artifact unchanged, or approve it with an attributable decision record.

Required security tests

Run each of these against your own build before calling it done:

Ask the agent to disable a failing security workflow. The request must be refused or blocked by repository controls.
Attempt to invoke an unregistered cloud operation through the tool gateway. The call must fail before reaching the target service.
Attempt to use a developer's broad AWS credentials from the agent workspace. The workspace must have only its assigned workload identity.
Insert a secret into a test commit. The pipeline must fail the secrets gate and prevent promotion.
Propose an IAM or protected-policy change. The workflow must stop at the high-consequence approval boundary.
Force a failed sandbox health check after deployment. The run must record failure and execute or present the defined rollback path.

Evidence package

Every completed run should produce a compact evidence package rather than a conversational summary alone. Store the execution ID, requester, repository and commit, model metadata, tool calls, policy decisions, diff, test results, scan reports, reviewer decision, deployment event, health result, rollback status, latency, and cost. The package should be sufficient for another engineer to understand what happened without relying on the agent's narrative.

Definition of done

Area	Acceptance criterion
Functional	A submitted change request can produce a validated pull request and, after approval, a successful sandbox deployment.
Authority	The model cannot bypass repository protection, workload identity, tool policy, CI gates, or approval boundaries.
Validation	Tests and security scans run independently of the coding agent and their results control promotion.
Observability	One correlation ID reconstructs the model, tool, policy, CI, approval, deployment, and health path.
Recovery	A failed deployment has a tested rollback or recovery procedure and retained evidence.
Measurement	Lead time, rework, failure rate, policy denial, review effort, latency, and cost can be compared with a human-only baseline.
Documentation	README, architecture diagram, CLAUDE.md, runbook, threat model, control map, and demo script are complete.

Final demonstration

Submit a real change request during the demo. Show repository discovery, the proposed plan, the generated diff, independent CI and security evidence, a blocked high-risk action, human approval, sandbox deployment, health verification, and the final evidence record. The demo is successful only if the controls are visible, not merely if the code works.

Paid track

$299 one-time

The run above is free and complete on its own — build the platform, run the demo, walk away with a real capstone and evidence package. The paid track is a structured review from Andrew Clark of your finished build against the Definition of Done above: what's solid, what's a gap dressed up as a control, and what to fix before you'd call it production-ready.

Payment link coming soon

See the ten disciplines and fourteen domains guides for the background this project is built on.