AI code governance landscape
Choose AI coding controls by the decision they make
“AI governance” describes several different control problems. Buying one layer does not automatically solve the others.
AI coding agents produce changes. Runtime guardrails control actions. Code analysis evaluates implementation properties. Change control decides whether evidence and approval are sufficient to proceed. Enterprise governance oversees organizational AI risk.
The control-layer map
| Layer | Core decision | Representative tools |
|---|---|---|
| Coding agent | What code should be proposed? | Copilot, Cursor, Claude Code, Codex |
| Runtime guardrail | May this agent action execute? | Microsoft Agent Control Specification |
| Code quality and security | Does the implementation violate an analysis rule? | SonarQube, Snyk, Semgrep |
| Software change control | Is there sufficient evidence and approval to proceed? | alienctl |
| Enterprise AI governance | How is organizational AI risk inventoried and governed? | IBM watsonx.governance, Credo AI, Saidot |
Why a code quality gate is not a run receipt
Static analysis can find bugs, vulnerabilities, and maintainability problems. SonarQube’s AI Code Assurance applies stricter quality gates to projects containing AI-generated code. That is useful implementation evidence, but it does not necessarily establish what the agent was authorized to change, whether every relevant action was observed, or which human approval remains missing.
Why runtime control is not change readiness
Microsoft’s Agent Control Specification makes deterministic allow, deny, warn, escalate, and transform decisions at intervention points in an agent loop. A permitted sequence of actions can still result in a change whose verification or approval evidence is incomplete. Runtime policy and change readiness are therefore complementary.
Why enterprise governance is not a repository gate
Enterprise platforms such as IBM watsonx.governance organize AI inventories, policies, risks, regulatory mappings, and reporting. A repository workflow needs a more immediate decision: should a reviewer or release owner proceed with this specific change?
The practical architecture
- Let teams choose the coding agents that fit their work.
- Apply runtime restrictions where action-level intervention is needed.
- Use existing CI, quality, and security tools as evidence producers.
- Require a customer-owned receipt before the change proceeds.
- Export bounded evidence upward when enterprise governance requires it.
alienctl is being developed for step four. It does not replace the other layers and does not currently claim integrations with the named products.