Skip to main content

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​

RoleYou typically want to govern...Start with
AI engineerWhich models, tools, and data your agents may useSDK
Database administrator (DBA)Reads vs writes vs schema changes on your databasesSDK / Gateway
Software developerYour AI coding assistant's shell, file, and network actionsCoding hooks
DevOps engineerProduction-facing actions made by agents you cannot editGateway
Security engineerSecret and PII egress, org-wide enforcement, audit evidenceSDK / Gateway
Intern / new hireA safe sandbox where mistakes cannot cause real damageCoding 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, Cursor, Codex CLI, or Gemini CLI. See Coding assistant hooks.

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:

  1. Who this is for -- one or two sentences naming the role and its goal.
  2. What you typically want governed -- the two or three things this role actually cares about, in their language.
  3. Which surface to install -- exactly one recommended surface, with the one command or one URL change to wire it.
  4. Starter policy -- a complete, copy-paste controlzero.yaml that is valid as-is and starts in a safe posture.
  5. What you'll see -- where the audit trail or approvals show up for this role, so they know it is working.
  6. 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.