AI Governance as a Discipline
Deploying AI agents without governance is not a strategy - it is a liability. As agentic AI moves from experiment to production, engineering organizations face a new class of risk: uncontrolled agent costs, unclear accountability, and compliance exposure in regulated industries.
I build the governance layer that transforms AI from a liability into a competitive advantage. This means agent audit trails, reliability SLOs, FinOps accountability frameworks, and human-in-the-loop policies that give CFOs, boards, and compliance teams the visibility they need to scale AI with confidence.
Governance is not a barrier to AI adoption - it is the foundation that makes sustainable AI adoption possible.
Schedule AI Governance Review
Why Governance Defines AI Maturity
Accountability
Every agent action is traceable. I build audit trail systems that record what agents did, when, why, and with what outcome - giving compliance teams and boards the visibility they require for regulated AI deployments.
Reliability
Agents in production need SLOs just like microservices. I define uptime, accuracy, latency, and human escalation rate objectives - then build the monitoring and alerting that enforces them with the same rigor as any production service.
Cost Control
AI agent costs compound fast without visibility. I implement FinOps frameworks that track cost-per-workflow, cost-per-automation, and ROI per agent deployment - giving CFOs the financial accountability they need to approve AI scaling.
Ten Rules I Run AI in the SDLC By
Every governance framework I build reduces to these ten. They are the operating model; the licenses are the cheapest and least important part.
- 1AI in the SDLC is an operating model change, not a tooling purchase. Licenses are the cheapest and least important part.
- 2Authoring is cheap. Verification is the constraint. Design review, test, and merge capacity before you scale generation.
- 3Individual output is not organizational throughput. Every serious dataset since 2024 shows the gap. Assume it applies to you until your own numbers say otherwise.
- 4Governance before scale. Retroactive policy lands after habits have formed and costs more to enforce.
- 5Baseline before adoption. A number without a pre-AI baseline is a story, not evidence.
- 6Measure outcomes, not activity. Cycle time, change failure rate, escaped defects, review latency. Not adoption percentage, not AI-authored lines.
- 7Humans own merges. An agent never holds merge authority on a protected branch. Every production change has a named human approver.
- 8The bar for AI-authored code is the bar for human code, applied with more suspicion. AI output is plausible by construction. Plausible is not correct.
- 9Agents are services. They get an identity, a permission scope, a sandbox, a budget, and hard rules, same as any other workload.
- 10The compounding asset is your context, not the model. Repo instructions, review rules, skills, evals, fixtures, and evidence are owned. Models are rented and will be swapped.
The AI SDLC Maturity Model
This is not a scale of how much AI you use. It is a scale of how safely and effectively it is integrated. The distinction matters because usage is now universal and returns are not.
McKinsey's State of AI found 88% of organizations using AI in at least one business function (November 2025), yet only about 6% qualify as high performers, and those high performers are nearly 3x more likely to have fundamentally redesigned workflows. The August 2026 edition holds the pattern: 80% report individual productivity gains, 37% report any enterprise EBIT impact, and roughly 75% of high performers redesigned workflows versus 25% of everyone else. Usage is universal. Redesign is rare. Redesign is where the return is. McKinsey, The State of AI (source dated 2026-08; verified 2026-09)
- Level 0 - No AI
No AI in the development workflow; everything is manual. The risk is falling behind the adoption curve, a productivity disadvantage, and trouble attracting talent. Next step: assess readiness, find low-risk entry points, and capture the baseline now while it is still clean.
- Level 1 - Ad hoc
Individuals using tools on their own initiative, on personal accounts, with no shared standards and no visibility. The risk is shadow AI, IP and data exposure, quality that tracks individual prompting skill, and no measurement. Next step: an approved tool list, data classification rules, minimum review standards for AI-generated code, and company-managed accounts with training opt-out.
- Level 2 - Guardrails introduced
Approved tools and usage guidelines exist, basic data classification is in place, review standards are on paper, some usage is logged, and repo instruction files exist in the main repos. The risk is guardrails that are unevenly adopted and thinly measured. Next step: measurement of adoption patterns, review quality, and bug escape rates against the baseline.
- Level 3 - Measured and standardized
Consistent cross-team standards, tracked metrics for adoption, quality, and risk, regular review cycles, the AI workflow in onboarding, risk-tiered review in place, and agents running under their own identity with budgets. The risk is metrics that capture activity instead of quality, rigid standards, and measurement overhead. Next step: formalize policy, automate compliance checks, and build the learn loop where every escaped defect becomes a rule.
- Level 4 - Governed and optimized
Governance embedded in the engineering workflow, automated compliance and quality checks on AI output, improvement loops driven by measured outcomes, clear ownership, evidence generated at release, and agents delegated bounded work classes unattended. The risk is governance overhead eating the speed benefit, complacency, and new capability outrunning the framework. Next step: reassess continuously, adapt to new capability, and share what you learned.
Twelve Questions, Count the Yeses
Answer yes or no. The count places you on the scale more honestly than any vendor maturity quiz.
- Every AI tool in use is on an approved list under a company-managed account.
- A written policy says what data may and may not enter a prompt or an agent's context.
- Every repo an agent touches has a maintained instruction file.
- Pre-AI baselines exist for cycle time, review latency, change failure rate, and escaped defects.
- Review standards say what AI should flag, what it should auto-fix, and what escalates to a human.
- PRs are routed to review tiers by risk, not treated uniformly.
- Agents in CI run under their own identity with a scoped token and a per-workflow budget.
- No agent can push to a protected branch or approve its own PR.
- Critical modules have a mutation score gate, not only a coverage gate.
- Model versions are pinned and changes are logged.
- Escaped defects are converted into review rules on a schedule.
- Someone owns the AI operating model by name.
Scoring: 0 to 3 yeses is Level 1. 4 to 6 is Level 2. 7 to 9 is Level 3. 10 to 12 is Level 4. Questions 7 through 9 are where most organizations lose their yeses, and they are the three that separate a tooling rollout from an operating model.
The Regulatory Landscape
Governance stopped being a voluntary maturity exercise. Three developments matter most if you build regulated software, and the headlines about all three are misleading:
- The EU AI Act was not postponed, only part of it was. The Act becomes fully applicable on 2 August 2026 "with some exceptions," and the Commission confirms its transparency rules come into effect that same month. What moved was the heavy high-risk conformity regime: Regulation (EU) 2026/1744 of 8 July 2026, the Digital Omnibus on AI adopted by Parliament on 16 June 2026, pushed the Chapter III obligations to 2 December 2027 for Annex III high-risk systems and 2 August 2028 for Annex I. One transparency date is sooner, not later: generative systems already on the market before 2 August 2026 must meet the Article 50(2) machine-readable marking duty by 2 December 2026. The Omnibus has been in force since 27 July 2026. Coding assistants are not high-risk on their face - the Commission's draft classification guidelines of May 2026 do not single them out - but a product that makes consequential decisions about people may be, and that is the question to answer. Reading "the EU delayed the AI Act" and standing down is a mistake. European Commission on the AI Act and Regulation (EU) 2026/1744 (verified 2026-09)
- Texas now rewards documented governance in statute. House Bill 149, the Texas Responsible Artificial Intelligence Governance Act, took effect 1 January 2026. Its safe harbor at Sec. 552.105(e) protects a defendant that discovers a violation through an internal review process while substantially complying with the NIST "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile" - the GenAI Profile specifically, not the base framework - or another nationally or internationally recognized AI risk framework. Framework alignment moved from a procurement checkbox to a legal position. The Attorney General's online AI complaint mechanism, required by Sec. 552.102 no later than 1 September 2026, is now live. Texas HB 149 text and Texas AG, Consumer AI Rights (effective 2026-01-01; verified 2026-09)
- Colorado is the cautionary tale. SB24-205 was repealed and reenacted by SB26-189, signed 14 May 2026 and effective 1 January 2027, and separately, on 27 April 2026 a federal court entered a stipulated order in X.AI LLC v. Weiser that temporarily stays the Attorney General from enforcing SB24-205 - or its replacement - until 14 days after a ruling on X.AI's forthcoming preliminary-injunction motion. Any compliance plan built against the original statute is now aimed at law that no longer exists, and Attorney General rulemaking under the re-enacted law is still underway. The lesson is not the statute text. It is that a governance program has to survive the statute changing underneath it. Colorado Attorney General on AI (verified 2026-09)
- California is building the outside auditor. On 9 September 2026 California signed SB 813 (Chapter 179), a framework for independent verification organizations that can assess AI systems and models for compliance with state law, and AB 1405 (Chapter 178), a state registry for AI auditors with standards for their independence, transparency, and integrity. The direction is third-party assurance: governance evidence will increasingly be read by someone outside the company, so it has to hold up without the team that produced it in the room. California Governor on SB 813 and AB 1405 (signed 2026-09-09; verified 2026-09)
What this means operationally: the framework you map controls to matters more than the jurisdiction you sit in. Map once to the NIST AI Risk Management Framework and its Generative AI Profile, then satisfy each regime by mapping rather than rebuilding. Every control in the sections above and below - the audit trail, the reliability SLO, the approval gate, the spend guardrail - is evidence for that mapping.
Regulatory summary verified 2026-09. AI law moves quickly and inconsistently. Treat every date here as a checkpoint to re-verify, not a conclusion, and confirm against primary sources before making a compliance decision.
Threat Model for AI in the SDLC
Blanket AI policy either over-restricts or under-protects, because the risks are vector-specific. These are the nine I model for every pipeline that has an agent in it, each mapped to its OWASP reference and the control that actually closes it.
Prompt Injection
Vector: issue text, PR comments, READMEs, dependency docs, web pages an agent fetches, MCP server responses.
OWASP: LLM01, ASI01.
Control: all retrieved content is data; agents never act on instructions found in content; human approval for any action outside the task scope.
Sensitive Data Disclosure
Vector: secrets, PII, PHI, and customer data in prompts, context windows, fixtures, or agent working trees.
OWASP: LLM02.
Control: data classification enforced on the input side; secret scanning on context; synthetic fixtures only; vendor retention and training terms in writing.
Supply Chain
Vector: hallucinated packages, typosquats, malicious MCP servers, unpinned model versions.
OWASP: LLM03, ASI04.
Control: lockfile mode; registry allow list; new-dependency review gate; MCP servers reviewed like dependencies; model pinning.
Excessive Agency
Vector: an agent with write access to protected branches, deploy rights, production credentials, or an unrestricted shell.
OWASP: LLM06, ASI02, ASI03.
Control: least privilege in the harness configuration; a branch namespace the agent owns; tool deny list; no self-approve.
Unexpected Code Execution
Vector: an agent runs generated code or scripts in a privileged environment.
OWASP: ASI05.
Control: ephemeral sandbox per task; network egress allow list; no production credentials in the agent's environment.
Memory and Context Poisoning
Vector: corrupted instruction files, skills, or retrieval sources that change agent behavior persistently.
OWASP: ASI06.
Control: instruction files and skills are reviewed code with CODEOWNERS; an eval suite runs on every change to them.
Insecure Output Handling
Vector: generated code with XSS, injection, or weak crypto merged because it looked fine.
OWASP: LLM05.
Control: SAST in the pipeline; review rules for the classes AI gets wrong most (XSS, log injection, error masking); mutation-scored tests.
Unbounded Consumption
Vector: runaway agent loops and retry storms.
OWASP: LLM10.
Control: per-workflow budgets, attempt limits, and hard monthly caps on the API platform.
Human-Agent Trust Exploitation
Vector: reviewers rubber-stamp because the agent's summary was confident.
OWASP: ASI09.
Control: AI comments labeled as automated; tiered review; rework and no-comment-merge metrics reported by tier.
OWASP references are the Top 10 for LLM Applications 2025 (LLM01 to LLM10) and the Top 10 for Agentic Applications 2026 (ASI01 to ASI10, published 12-09-2025). OWASP published a 2026 edition of the LLM Top 10 on 4 August 2026 and announced an Agent Control Standard v0.1 on 1 September 2026; the codes above follow the 2025 LLM edition, and the 2026 edition renumbers - Excessive Agency moves to LLM03, Unbounded Consumption to LLM06, and Improper Output Handling to LLM10 - so re-map before you cite it. (verified 2026-09)
MCP gets its own line because it is the newest attack surface. The 2026-07-28 spec revision published security best practices covering confused deputy, token passthrough (a server must never forward the client's token upstream), SSRF via metadata, and localhost redirect impersonation. The reference filesystem and git servers and the mcp-remote bridge have all carried CVEs since mid-2025. An MCP server is reviewed like a dependency - who wrote it, what it can read, what it can write, whether it carries instructions in its responses - and pinned by version. (verified 2026-09)
Data Classification Mapped to AI Surfaces
Four tiers are enough: Public, Internal, Confidential, and Restricted (PII, PHI, secrets, customer data). What makes the classification useful is mapping each tier to the four surfaces data can actually leave through - an IDE assistant, a chat tool, an agent in CI, and an MCP connector - and enforcing the map on the agent's input side with secret scanning and PII detection, not only on commits.
Restricted data never enters a prompt. Synthetic fixtures only. Training opt-out is confirmed in writing per vendor and per tier: Business and Enterprise tiers are typically opted out by default, consumer accounts are not, and that sentence is the entire shadow-AI exposure.
| Tier | IDE assistant | Chat | Agent in CI | MCP or connector |
|---|---|---|---|---|
| Public | Yes | Yes | Yes | Yes |
| Internal | Company-managed account, training opt-out | Same | Yes, logged | Approved connectors only |
| Confidential | Company-managed, opt-out, no consumer tools | Same, no pasting into consumer tools | Yes, with audit log | Approved, read-only unless reviewed |
| Restricted (PII, PHI, secrets, customer data) | Never in prompt or context | Never | Never; synthetic fixtures only | Never |
The map is short on purpose. A classification scheme nobody can hold in their head is one nobody applies at 4pm on a Friday, and the agent's context window does not care how good the policy document was.
How the Controls Map to the Frameworks
None of the frameworks below were written for a pipeline with agents in it. All of them can be satisfied by one, if the controls are built as evidence from the start. This is what each one asks of AI in the SDLC and how the operating model above answers it.
- SOC 2. Change management asks that changes be authorized, tested, and approved by someone other than the author, with least-privilege access that is reviewed. The answer is a named human approver on every production merge, agent identity with scoped access, an evidence pack per release, and no self-approve. There is no authoritative AICPA guidance on AI-authored code as of September 2026 - only a nonauthoritative Technical Q&A (TQA 9561, 10 September 2026) on a service organization's use of AI in SOC examinations - so expect auditors to ask for the AI tool inventory and for proof that an agent cannot approve its own change. (verified 2026-09)
- HIPAA. PHI never leaves the covered boundary without a BAA, access is logged, and minimum necessary applies. Coverage is per product, not per vendor, and it is narrower than the vendor lists suggest: GitHub does not sign BAAs and Copilot is not HIPAA-eligible; Anthropic covers the API and Enterprise, the Claude Code CLI only with zero data retention, and not Claude Code cloud sessions (formerly Claude Code on the web), managed Code Review, or MCP connectors; OpenAI covers the API and ChatGPT Enterprise, with Codex local eligible and Codex cloud not. The Restricted-tier rule - PHI never enters a prompt - is what keeps the rest of the toolchain out of scope. (verified 2026-09)
- ISO/IEC 27001:2022. A secure development lifecycle (A.8.25 to A.8.31), supplier security, and logging. Answered by the usage policy, versioned review standards, the vendor evaluation checklist, and the agent audit trail.
- ISO/IEC 42001:2023. An AI management system: risk assessment, impact assessment, lifecycle controls, transparency, human oversight. This operating model is most of the AIMS for the engineering function; the maturity model and the twelve questions map to its clauses. (verified 2026-09)
- NIST AI RMF 1.0 and the Generative AI Profile (AI 600-1). Govern, Map, Measure, Manage, plus the GenAI-specific risks of confabulation, information security, and IP. The governance pillars are Govern, the threat model is Map, the measurement stack is Measure, and the agent controls are Manage. The RMF is under revision with no draft published as of September 2026, and NIST launched an AI Agent Standards Initiative in February 2026 - map to the current text and expect to re-map. (verified 2026-09)
- NIST SP 800-218A. Secure development practices when generative models are part of the development process. Answered by the engineering practices (instruction files, plan approval, mutation-scored tests, risk-tiered review) and by attribution and provenance on every agent commit. (verified 2026-09)
- SLSA v1.2 and Sigstore. Build provenance and signed attestations do not change because AI wrote the code, but the Source track's L4 requires two-party review, and an agent counts as zero parties - an agent author plus one human reviewer does not satisfy it. No SLSA track or in-toto predicate for AI-generated code exists yet, so the agent identity that opened the PR is recorded in the commit trailer and the PR template until one does. (verified 2026-09)
The operational point stands: map once to the NIST AI RMF and its Generative AI Profile, then satisfy each regime by mapping rather than rebuilding. Every control on this page is evidence for that mapping.
FinOps for AI Agents
CFOs now demand tangible ROI from AI investments. I build the cost accountability layer that proves it - tracking every dollar of AI spend against measurable business outcomes.
- Cost-per-workflow tracking: Every agent workflow is tagged and costed - so you know exactly what each automation delivers and what it costs.
- ROI dashboards: Real-time visibility into automation ROI, cost trends, and efficiency gains - board-ready reporting without the manual data assembly.
- Budget guardrails: Automated spend controls that prevent runaway agent costs while preserving the flexibility to scale high-ROI automations.
- Cost attribution: AI spend attributed to teams, products, and workflows - enabling chargeback models and informed investment decisions.
Three Buckets, Not One
AI spend in an engineering organization lands in three buckets. Most organizations budget for one of them, and it is never the one that surprises them.
Seats - Fixed
Committed in advance. The lever is the mix: premium seats for the engineers living in an agentic tool all day, standard seats for everyone else.
A developer hitting overage on a standard seat every month is a mispriced seat, not a budget problem. Move the seat and stop having the conversation.
Seat Allowances - Semi-Fixed
Seat products now include a monthly credit pool - GitHub AI Credits since June 2026, GitLab Credits since January 2026 - and coding agents, AI review, and cloud agent sessions all draw from the same pool, often alongside CI minutes. Model the burn before enabling unattended agents, because the pool empties faster than anyone expects.
Overage at published model rates is variable cost wearing a seat's clothing. The industry moved from per-seat to usage-based in 2026; budget accordingly.
API - Variable
Anything in CI, any unattended agent, any custom tooling. This is the bucket that surprises you. The controls: a per-workflow token budget, spend tagged by repo, workflow, and ticket, a hard monthly cap with an alert at 70 percent, and prompt caching and batch APIs wherever the vendor offers them - the same review workflow can cost 2 to 10x more without them.
Route by eval, not by reputation: the cheapest model that passes the eval for that task class, not the best model for everything.
The unit economics I report: agent spend per merged PR by workflow, review agent cost per PR, and cost per escaped defect prevented (an estimate, but a tracked one). If an unattended agent lane's cost per merged PR exceeds the loaded cost of a human doing the same class of work, the work class is wrong, not the idea.
Agent Reliability SLOs
Production AI agents need the same reliability standards as production microservices. I define and enforce the SLOs that make agentic AI trustworthy at scale.
- Uptime SLOs
Agent availability targets with error budgets and automated alerting when agents fail to respond or produce malformed outputs.
- Accuracy SLOs
Task completion rate targets - measuring the percentage of agent tasks completed successfully without human correction or escalation.
- Latency SLOs
Response time objectives for agent workflows, ensuring agents meet the speed requirements of the processes they are embedded in.
- Escalation Rate SLOs
Human escalation rate targets - tracking how often agents need to hand off to humans, and alerting when escalation rates exceed acceptable thresholds.
Why Governance Is Not Optional
- Adoption is near-universal, and it cuts both ways. DORA found that "ninety percent of this year's survey respondents report using AI at work, a 14.1% increase over the same metric in last year's report," and that while "AI adoption now improves software delivery throughput," it "still increases delivery instability." Governance is what converts throughput into throughput you can ship on a Friday. DORA 2025 (source dated 2025-09; verified 2026-07)
- Tooling will not save a weak operating model. DORA's central finding is that "AI's primary role in software development is that of an amplifier," magnifying existing strengths and existing dysfunctions alike. An organization without clear accountability does not acquire it by adopting agents - it just reaches the consequences faster. DORA 2025 report (source dated 2025-09; verified 2026-07)
- Verification burden is the real cost, and it is where human-in-the-loop policy earns its keep. In the Stack Overflow Developer Survey 2025, 66% of developers named "AI solutions that are almost right, but not quite" their biggest frustration and 45% said debugging AI-generated code is more time-consuming. Plausible-but-wrong is the failure mode that audit trails and approval gates exist to catch. Stack Overflow 2025 (source dated 2025-07; verified 2026-07)
- Autonomy limits should be set from measured reliability, not vendor claims. METR reports models have "almost 100% success rate on tasks taking humans less than 4 minutes, but succeed <10% of the time on tasks taking more than around 4 hours," and publishes the limit of its own instrument: "Measurements above 16 hrs are unreliable with our current task suite." That is the shape of the curve an escalation policy should be drawn against. METR time horizons (sources dated 2025-03 and 2026-05; verified 2026-07)
- Oversight erodes quietly when nobody is measuring it. Faros AI's 2026 telemetry across 22,000 developers and 4,000 teams found PRs merged with no human review up 31.3%, incidents per PR up 242.7%, and - in the roughly 10% of teams that track it - deployments per week down 11.7%. That is what "humans own merges" looks like when it is a slide instead of a branch rule. Faros AI, The Acceleration Whiplash (source dated 2026-04; verified 2026-09)
- The people committing the code know it, too. Sonar's State of Code 2026 survey of 1,100+ developers found 42% of committed code is now AI-generated or assisted, 96% do not fully trust it, and only 48% always verify AI code before committing. A policy that assumes verification happens without enforcing it is describing the other 52%. Sonar State of Code 2026 (source dated 2026-01; verified 2026-09)
Human-in-the-Loop Policies
Autonomous Action
I define which agent tasks can be executed autonomously without human review - typically low-risk, high-frequency, reversible actions like PR triage, dependency updates, and documentation generation.
Human Approval Gates
High-risk or irreversible agent actions require human approval before execution - deployments to production, access privilege changes, financial transactions, and patient-facing decisions in MedTech.
Escalation Workflows
When agents encounter ambiguity, low confidence, or edge cases outside their training, structured escalation workflows route decisions to the right human reviewer with full context preserved.
The policies above are the contract; two longer pieces cover the mechanics. Agents Are Services walks through the identity, permission, sandbox, and budget contract every agent in CI gets, plus the seven hard rules that are enforced in the workflow rather than requested in the prompt. Verification Is the Constraint covers why verification, not authoring, is the constraint - and why every human-in-the-loop policy is really a verification-capacity decision.
Audit Trails & Compliance
Regulated industries cannot deploy AI without comprehensive audit trails. I build governance frameworks specifically designed for FinTech, MedTech, and other compliance-heavy environments where AI actions must be fully traceable and defensible.
Every agent action is logged with full context: what task was executed, which tools were called, what data was accessed, what decision was made, and why. This creates the audit trail that satisfies SOC 2, HIPAA, and PCI requirements for AI-assisted workflows.
Schedule AI Governance Review