Setup by role
Governance looks different depending on what you do all day. A DBA cares about which queries an agent can run; a security engineer cares about secret egress; an intern just needs guardrails so they cannot break anything. This section gives each role a short, self-contained path: what you typically want governed, a copy-paste starter policy, which surface to install, and what you'll see once it is running.
Every starter policy on these pages begins in a safe posture. None of them will surprise you with a block you did not ask for. If you have never run Control Zero before, pair any role guide with Observation-only setup to watch first and enforce later.
Pick your role
| Role | You typically want to govern... | Start with |
|---|---|---|
| AI engineer | Which models, tools, and data your agents may use | SDK |
| Database administrator (DBA) | Reads vs writes vs schema changes on your databases | SDK / Gateway |
| Software developer | Your AI coding assistant's shell, file, and network actions | Coding hooks |
| DevOps engineer | Production-facing actions made by agents you cannot edit | Gateway |
| Security engineer | Secret and PII egress, org-wide enforcement, audit evidence | SDK / Gateway |
| Intern / new hire | A safe sandbox where mistakes cannot cause real damage | Coding hooks |
Not sure which surface a guide means? Each surface is one of:
- SDK -- a library you add to an AI app you are building. One
guard()call per tool. See Quickstart, Option B. - Gateway -- a proxy you point an existing app at by changing one base URL. Zero code changes. See Gateway.
- Coding hooks -- a one-command install into Claude Code, Gemini CLI, Cursor IDE, Kiro CLI, or Codex CLI. Claude Code, Gemini CLI, Cursor IDE, and Kiro CLI hard-block denies before execution; see Coding assistant hooks for per-event coverage and the documented Codex boundaries.
Adding a new role guide
These guides follow one repeatable shape, so adding a role for a persona we have not covered (data scientist, platform engineer, support lead, auditor) is mechanical. Keep shared concepts in the linked Concepts pages and layer only the role-specific depth here. The template for every role page is:
- Who this is for -- one or two sentences naming the role and its goal.
- What you typically want governed -- the two or three things this role actually cares about, in their language.
- Which surface to install -- exactly one recommended surface, with the one command or one URL change to wire it.
- Starter policy -- a complete, copy-paste
controlzero.yamlthat is valid as-is and starts in a safe posture. - What you'll see -- where the audit trail or approvals show up for this role, so they know it is working.
- Next steps -- two or three links to the relevant recipes, concepts, or use cases.
If a role wants something Control Zero cannot enforce today, do not invent a policy for it -- link the closest real capability and note the gap honestly.
Related
- Choose your path -- a five-question decision tree if you are unsure which surface fits.
- Policy Recipes -- copy-paste policies for common scenarios, each CI-verified.
- Observation-only setup -- watch first, enforce later.