Case Study: Rolling Out Agents to a Team

A phased plan

Week 1: agents run in a dev container with only the repo mounted, no secrets in the environment, network limited to the package registry and Git host, on branches only, with a committed permission file and a pre-tool hook. Week 2: add CI secret scanning, CODEOWNERS for CI and infrastructure paths, a diff size gate and audit logging to a team-owned store. Week 3: run a red-team suite in CI and a tabletop incident drill. Later: relax rules selectively based on audit data, one capability at a time, never everything at once.

A guarded agent end to end

A complete setup stacks policy, sandbox, secrets and network control, Git gates, hooks and logging.

The setup on one page

Each line maps to a section of this course.

Threat model   six risk families, trust boundaries, layers   (Sec 1)
Policy         allow/ask/deny file, parsed command allowlist   (Sec 2)
Environment    dev container, project-only mount, no secrets   (Sec 3, 4)
Network        egress allowlist, no metadata endpoint          (Sec 4)
Repository     branch only, protection, CODEOWNERS, size gate  (Sec 3, 5)
CI             tests + secret scan + human approval            (Sec 5)
Hooks/budgets  pre-tool hook, session limits, managed baseline (Sec 6)
Operations     audit log, red-team suite, incident checklist   (Sec 7)

Relax from evidence

If developers keep approving the same "ask" prompt, move that command to allow. If an allow rule is never used, remove it. Audit data keeps the policy tight where it matters and light where it does not.

Quick check: Which is the better way to loosen a guardrail?

• Remove everything at once
• Disable logging first
• Loosen one capability at a time using audit evidence
• Ask the agent to decide