Capability 04 of 04 · Delivery Management
Governance & Compliance
Controls around AI-generated code - licensing, security scanning, and audit trails.
5
maturity levels
15
practices
15
guides
L1 · Stage 01Assisted
Practices - what it looks like3 guides
- Individual devs use their own AI subscriptionsShadow AI refers to the use of AI tools by developers through personal subscriptions and accounts that operate entirely outside the organization's awareness, approval, or oversight.guide→
- AI usage not yet auditedA zero audit trail state means that when an auditor, security team, or incident investigator asks "what AI systems were involved in producing this code change?" there is no answer.guide→
- AI usage is informal, policy not yet definedIn 2023 and early 2024, many organizations responded to AI coding tools by banning them outright.guide→
Criteria - what to measure
- 01The team knows which AI tools are in use
- 02AI-generated code follows the normal review and merge process
- 03Team is aware of shadow AI usage (developers using private subscriptions)
- 04Organization has moved past "ban AI" as a policy position
L2 · Stage 02Delegated
Practices - what it looks like3 guides
- Official AI tool policy; per-session spend caps, short-lived keys and kill switches; autonomy set by a declarative deny/ask ruleset that is reviewed and version-controlled, not by a human clicking approve; a deliberate default for new vendor features instead of letting them auto-enable (Copilot's "Default policy for new features")An official AI tool policy is the organization's first structured governance response to AI in the delivery pipeline, and at L2 its sharpest edge is a declarative deny/ask ruleset - reviewed, version-controlled and enforced before any classifier runs - rather than a human clicking approve.guide→
- Basic audit: who uses what - and every agent has a named human owner, because 51% of organisations cannot say who owns their AI identitiesBasic audit at L2 means the organization has established visibility into which developers are using which AI tools, at what frequency, and for what purposes.guide→
- Regulatory obligations for your jurisdiction and sector are identified and owned (EU AI Act Article 50 transparency applicable since Aug 2 2026, high-risk duties deferred to Dec 2027 / Aug 2028; China tiers agents by decision authority); data-residency routingThe regulatory obligations that apply to your jurisdiction and sector are identified and owned by a named person - starting with the EU AI Act, whose Article 50 transparency regime has been applicable since 2 August 2026 while the high-risk duties stand deferred to December 2027 and August 2028.guide→
Criteria - what to measure
- 01Official AI tool policy exists and is communicated to all developers
- 02The organization can list which developers use which AI tools
- 03The regulatory obligations that apply to this organisation's jurisdiction and sector are written down, with a named owner
- 04AI tool policy is reviewed at least annually
- 05Approved tool list is maintained and accessible
- 06Every agent in use has a named human owner
- 07New vendor AI features are enabled by a deliberate decision, not by vendor default
L3 · Stage 03Systematic
Practices - what it looks like3 guides
- Minimum viable audit trail: model, timestamp, context, approver - and the agent's own identity, registered as a distinct principal in the IdP (Entra Agent ID, Okta, Google Agent Identity), not a developer's tokenThe four fields that make an AI-assisted change defensible after the fact: which model, when, what it was asked to do, and who approved the result.guide→
- Policy-as-code; all model traffic through an AI gateway (LiteLLM, Kong AI Gateway 2.0, Agent Router, Claude apps gateway, Cloudflare): central keys with BYOK-only, per-team budgets, model allowlist with exact-version pinning and hard denies (`availableModelsMatch`, `deniedModels`, Codex `requirements.toml`); repository-supplied agent config (`.claude/`, `.vscode/`, `.cursor/`, `.git/config`, `build.rs`) on a mandatory-diff path, because it executes on folder openPolicy-as-code means expressing compliance rules as executable code that runs in the pipeline rather than as documents people are asked to read - now extending to enterprise managed settings for agent clients, an org-wide default model admins can actually enforce, and repository-supplied agent config placed on a mandatory-diff path because it executes the moment a folder is opened.guide→
- Compliance gates in CICompliance gates in CI are automated checks that must pass before a pull request can be merged, specifically focused on governance and compliance requirements rather than functional correctness.guide→
Criteria - what to measure
- 01Minimum viable audit trail is captured per AI-assisted change: model identifier, timestamp, context description, human approver
- 02Policy-as-code enforces compliance rules in CI (OPA or equivalent)
- 03Compliance gates run on every PR to in-scope repositories
- 04Audit trail fields are validated by CI (missing fields fail the build)
- 05Policy exceptions are logged and require follow-up within 48 hours
- 06Model traffic goes through an AI gateway with a model allowlist and exact-version pinning
- 07Each agent is registered as a distinct identity in the IdP, not acting on a developer's token
L4 · Stage 04GovernedMost teams aim here
Practices - what it looks like3 guides
- Full provenance tracking per change (cryptographic agent traces; commit-to-prompt lineage via gateway prompt IDs; prompt and response logs in the SIEM with retention beyond vendor defaults - Cursor keeps 30 days); agent access certified like human access and revoked when the owner leavesFor every change in production you can reconstruct the whole lineage: the requirement, the ticket, the AI sessions, the review, the CI run, the release.guide→
- Automated compliance checks; the AI gateway run as critical infrastructure with a patch SLA (LiteLLM's MCP auth bypass reached the CISA KEV list), DLP at the gateway, and unapproved agents detectable - 26% of large firms cannot; skills and MCP servers allowlisted and pinned rather than scanned, assessed against OWASP Agentic Skills Top 10Compliance checks that judge substance rather than paperwork - prohibited patterns, regulatory boundaries crossed, known issues in the model that wrote it - with skills and MCP servers allowlisted and pinned rather than scanned, and assessed against the OWASP Agentic Skills Top 10.guide→
- AI code vs human code distinction in VCS (Kubernetes model: disclosure mandatory, AI commit messages banned; humans write the why)Version control tags which commits and lines came from AI, so "how much of the payments module was AI-generated?" has a computable answer.guide→
Criteria - what to measure
- 01Full provenance tracking per change: model version, prompt context, agent session ID, iteration count
- 02Automated compliance checks run without manual intervention on every merge
- 03AI-generated code is distinguishable from human-written code in version control (metadata, labels, or attribution)
- 04Provenance data is queryable (e.g., "show all changes made by model X in the last 30 days")
- 05Compliance check results are aggregated into a governance dashboard
- 06Prompt and audit logs are retained beyond vendor defaults, in a store the organisation controls
- 07The AI gateway has a patch SLA and is monitored for CVEs like any other critical infrastructure
L5 · Stage 05Self-improving
Practices - what it looks like3 guides
- Continuous compliance: agent monitors regulatory changesAn agent tracks regulatory change continuously and maps each one onto the policies, gates and code it affects, instead of just alerting a human.guide→
- Self-documenting audit trail: every agent action traces to one agent identity and one accountable human, and the urgent fast path runs through the same controls (47% of firms with written policies skipped them for urgent deployments)A self-documenting audit trail is one where the documentation of AI involvement in a change is generated automatically by the AI system itself, without requiring human effort to produce it.guide→
- Enterprise-grade RBAC per agent: task-scoped permissions with no standing access, new agents start on probation and earn scope from their track recordEvery agent gets an audited identity of its own, so what it may do is set by its role rather than by the permissions of whoever launched it.guide→
Criteria - what to measure
- 01Continuous compliance: agent monitors regulatory changes (EU AI Act updates, SOC2 changes) and proposes policy updates
- 02Audit trail is self-documenting (agent decisions include reasoning, not just outcomes)
- 03Enterprise-grade RBAC is enforced per agent (each agent has scoped permissions for specific tools and repositories)
- 04Policy update proposals from compliance agent are auto-tested against existing codebase before rollout
- 05Agent RBAC permissions are audited automatically for least-privilege compliance
From the Field
Recent releases, projects and discussions the AI Radar classified into this capability.
article
Vorim AI – Identity, permissions, and audit trails for AI agents
article
Crossplane AI Contribution Policy
release
kodustech/kodus-ai
release
crewAIInc/crewAI
release
langchain-ai/langchain
release
Kilo-Org/kilocode
discovered
AtomicBot-ai/Atomic-Chat
discussion
How are you keeping on top of security these days?
Which level is your team at in Governance & Compliance?
The criteria above are what we check in a facilitated assessment. Run it yourself to place this capability, see which gates you have passed, and compare it against the other 3 in Delivery Management.
Start the assessment →