AI coding agent governance for small engineering teams: a one-page operating model

Executive summary

• A one-page governance operating model (five decisions, a RACI table, a weekly 30-minute review) for 10–100 person teams who need an AI policy without a NIST/ISO-scale framework.
• Map each decision to a control and an owner: approved tools, data rules, blocks/allowlists, alerts, and evidence.
• Enforce with vendor-native settings first, then hook DLP and egress across agents, plus coverage detection (hooks can fail open on crash/timeout; coverage is detection, not MDM).
• Access-review decisions are keep / revoke / modify / rotate; this is an operating model, not legal advice.

For a 10–100 person team, AI coding governance means five decisions: which tools are approved, what data they may see, which actions need a block, who gets alerts, and what evidence you keep. Write those decisions on one page, enforce what you can at the agent hook and gateway, and review weekly. This is an operating model—not legal advice—and it is sized for teams that do not have a dedicated security org to run a full NIST AI Risk Management Framework program.

If you need the architecture picture first, read enterprise AI coding security control plane. This post is the weekly ritual and ownership map that makes that control plane livable without a 40-page policy.

Why big-company AI governance does not fit a 30-person team

NIST AI RMF, ISO/IEC 42001, and vendor “AI governance platforms” assume model builders, procurement committees, and continuous risk registers. A 30-person product company usually needs something narrower: which coding agents may touch production repos, and who checks that the controls still work.

You still benefit from the same principles—map, measure, manage—but you can skip the chapters that never touch Claude Code, Cursor, Codex, Copilot, or Antigravity. Canadian Centre for Cyber Security guidance on generative AI (ITSAP.00.041) and the OPC principles for responsible generative AI are useful north stars; your one-pager is the local implementation.

Decision 1: Approved tools and plans

Rule of thumb: team or enterprise plans with admin controls; no free or personal subscriptions on company repositories.

| Tool | Example approved tier | Why it matters | | --- | --- | --- | | Claude Code | Team / Enterprise with managed settings | Org-wide deny rules and model locks | | Cursor | Teams with Privacy Mode enforced | Training and retention terms differ by plan—verify Cursor data use before audit season | | GitHub Copilot | Copilot Business / Enterprise | Content exclusion and org policies | | Codex CLI | Org requirements via agent approvals & security | Sandbox modes and approval policies | | Antigravity | Org-approved distribution only | Treat like any other agent with MCP and shell access |

Shadow tools are a separate inventory exercise. Start with shadow AI coding tools: a CISO checklist, then fold the approved list into this page.

Owner: engineering manager proposes; CTO approves.

Decision 2: Data the agents may see

Define three classes:

1. Never send to models: live secrets (.env, cloud keys, database URLs), regulated personal data you cannot justify, client contracts that forbid third-party AI.
2. Send with care: application source, internal service names, customer metadata in logs.
3. Fine to send: public docs, synthetic fixtures, redacted snippets.

Operational controls:

• Folder exclusions and deny rules (Claude Read(./.env), Copilot content exclusion—with known gaps for symlinks and some agent paths).
• Hook-level redaction: ReclaimLLM’s local layer is string replacement plus folder exclusion, not semantic classification.
• When ReclaimLLM’s hook runs, recognized .env / *.env reads are sanitized or denied (fail-closed for that class). Hook crash, timeout, or egress-backend errors can still fail open—ReclaimLLM’s installer does not set Claude’s onFailure: "block" or Cursor’s failClosed: true on injected hooks. Teams can add those vendor flags if they want stricter behavior.

Owner: tech lead drafts rules; CTO accountable.

Decision 3: Actions that are blocked vs reviewed

| Action | Typical stance | Control | | --- | --- | --- | | Reading secret files | Block or redact | Deny rules + hook DLP | | Network egress (curl, wget, scp, inline fetch) | Block or allowlist | Pre-execution egress guard on Claude Code, Cursor, Antigravity, Codex, and Copilot | | MCP servers not on allowlist | Block or require review | Managed MCP settings + hooks | | Pasting customer PII into chat | Review + training | Policy + AD-004 alerts |

Document exceptions with an expiry and reason—same pattern as DLP exceptions in coverage without MDM.

Owner: platform / security advisor implements; CTO approves allowlists.

Decision 4: Who gets which alert

Route by severity so on-call is not drowned in coverage noise.

| Signal | Example routing | Product hook | | --- | --- | --- | | P0 secret exfiltration pattern | On-call engineer + CTO | AD-004 (configurable; default digest at 08:00 org time) | | Coverage gap (hooks missing, DLP off) | IT / platform | AD-010–013 | | Gateway anomaly | Security lead | AD-005/006 | | Weekly summary | Engineering managers | Signals digest |

Alert bodies should never contain the secret itself—only evidence pointers (session id, file path class, detector id).

Owner: on-call rotation maintains routing; CTO accountable for escalation.

Decision 5: Evidence you keep

Minimum evidence set for a customer or auditor question:

• Sessions (what the agent read and called)—with retention you configure.
• File access reviews and project-scoped file lineage on Paid/Enterprise.
• Admin audit log (365-day export).
• Access review campaigns for gateway keys, org API keys, and members—decisions are keep, revoke, modify, or rotate per ReclaimLLM’s compliance workflow (compliance dashboard).

ReclaimLLM stores captured session content in US or EU regions (choice is permanent per org). Paid/Enterprise sessions use encrypted storage with an org recovery key—not zero-knowledge. SOC 2 Type II is targeted for early 2027; we are not certified today.

Owner: ops or compliance lead; CEO/CTO accountable for retention and legal hold.

RACI on one page

| Decision | Responsible | Accountable | Consulted | Informed | | --- | --- | --- | --- | --- | | Approved tools | Eng manager | CTO | Security advisor | All developers | | Data rules | Tech lead | CTO | Privacy lead | All developers | | Blocks / allowlists | Platform | CTO | Developers | — | | Alerts | On-call | CTO | — | Team leads | | Evidence | Ops / compliance | CEO / CTO | Auditor | — |

Print this table next to your approved-tool list. If Accountable is blank on a row, the policy is aspirational.

Enforcing it: vendor settings, hooks, gateway, coverage

Layer 1 — Vendor-native settings (baseline). Deploy managed settings, Cursor team admin, Copilot org policies, and Codex sandbox requirements before you ask developers to “be careful.”

Layer 2 — Hooks (boundary control). ReclaimLLM hooks cover Claude Code, Cursor, Codex, Copilot, and Antigravity—including DLP and egress on Antigravity as shipped product behavior, not a pre-release experiment. Hooks see tool calls on the machine; they are not MDM. A developer can remove them; coverage detection tells you when that happens—it does not remotely reinstall.

Layer 3 — Enterprise LLM gateway. Team-scoped keys keep provider credentials server-side and centralize model policy. The gateway is an LLM gateway: it does not see local file reads or MCP traffic that never touches your proxy.

Layer 4 — Detection. AD-004, egress guard, AD-015 egress anomalies, and gateway anomalies complement prevention. Link detecting AI agent secret exfiltration (AD-004) for runbooks.

Honest summary: coverage ≠ enforcement. Coverage snapshots report posture; they do not lock laptops.

The weekly 30-minute review

Put this on the calendar with the same priority as production error budget.

| Minute block | Look at | Question | | --- | --- | --- | | 0–5 | Signals inbox | Any open P0? Assign owner. | | 5–10 | Coverage % and “DLP off” filter | Which teams slipped? | | 10–15 | Sensitive file reviews | Unexpected .env or credential reads? | | 15–20 | New MCP servers in sessions | Anything not on the allowlist? | | 20–25 | Cost / token outliers | Misconfigured model or runaway agent? | | 25–30 | Actions | Update deny rules, file tickets, note exceptions |

Start from the dashboard and Signals list; export CSV when you need an evidence folder for a customer.

Quarterly: access reviews and policy refresh

Once a quarter:

1. Run an access review campaign (gateway keys, API keys, org members).
2. Re-read vendor terms for your approved plans—training and retention language changes.
3. Update the one-pager if you added a tool (MCP marketplace plugins, new cloud agent feature).
4. Tie evidence to SOC prep with SOC 2 evidence for AI coding tools when that audit window opens.

Canada and privacy accountability

Canadian teams often get asked how AI coding fits privacy accountability. Use your own counsel for legal interpretation; operationally, align retention, access, and breach notification with how you already handle SaaS subprocessors. For a checklist-style companion (not legal advice), see AI coding tools and PIPEDA and the Cyber Centre ITSAP.00.041 link above.

One-page policy template (copy this)

Approved tools: [list plans + admin owner]
Forbidden on company repos: personal/free tiers, unapproved MCP servers
Data: no live secrets; client code only where contract allows
Blocks: .env reads, non-allowlisted egress, MCP allowlist attached
Alerts: P0 → [names]; coverage → [team]; weekly digest → [leads]
Evidence: sessions [retention], audit log export monthly, access reviews quarterly
Review: 30 min weekly [day/time], owner [name]
Exceptions: written reason + expiry, logged in [system]

Next step

Run your weekly AI review from one dashboard—start free. For hook install and coverage, see AI coding assistant DLP and enterprise observability.

FAQ

What is AI coding agent governance?

The set of decisions, owners, and review cadences that define which AI coding tools your engineers may use, what data those tools may access, what must be blocked, who is alerted, and what evidence you retain—implemented with vendor settings, hooks, gateway policy, and audit exports.

Do small companies need an AI policy for coding tools?

If you store customer data, touch regulated industries, or sign security questionnaires, yes—you need a written answer even without a security team. A one-page operating model is enough to start; expand when contracts require it.

Who should own AI governance in a 30-person engineering team?

The CTO is usually accountable. Engineering management owns tool approval, platform owns hooks and allowlists, and on-call owns alert routing. Consult a fractional CISO or privacy lead when customers ask legal questions you cannot answer internally.

What should an AI coding policy include?

Approved tools and plans, data classes, blocked actions (secrets, egress, MCP), alert routing, evidence retention, exception process, and a weekly review ritual. Skip copying ISO annexes you will never operate.

How do we enforce an AI policy without MDM?

Use vendor managed settings where available, ReclaimLLM hooks for redaction and egress, an LLM gateway for keys, and coverage detection to notice hook removal or DLP-off check-ins. That is detection and boundary control, not tamper-proof MDM—state that plainly in customer security reviews.