Your AI policy doesn't run in production
Turn AI governance policy into enforceable development controls. Learn how permissions, human reviews and CI/CD checks produce usable security evidence.
Key Takeaways
- A requirement such as “AI-generated code must be reviewed by a human” sounds like a control but leaves the important decisions open.
- For each meaningful requirement, write down the intent, the mechanism that enforces it and the evidence that the mechanism ran.
- Reuse the records your platforms already keep (review history, pipeline results, permissions, deployment approvals) instead of manual attestations, and verify them by sampling.
- ISO/IEC 42001 and the EU AI Act need their own applicability assessment; neither is a ready-made pipeline configuration.
- Start with one release path from tool connection to production and fix the most important mismatch first.
Somewhere in your organisation, there may be an AI policy that says all the right things. Use approved tools. Protect confidential information. Maintain human oversight. Follow security requirements. None of that is unreasonable.
Now ask a developer what prevents an unapproved coding agent from connecting to a sensitive repository. Ask the security team how they know a high-impact AI-assisted change was independently reviewed. If the answer is to point back at the policy, you have discovered the space between intent and implementation.
The question is not whether the policy was approved. It is whether anyone has made it operational.
The requirement that sounds finished
Consider this sentence: “AI-generated code must be reviewed by a human before deployment.” It sounds like a control. In practice, it leaves almost everything important undecided.
Does clicking Approve on a pull request count, even if nobody examined the security-sensitive change? What if the agent can alter the workflow that runs the checks? Does the reviewer have enough context to judge an authorisation change? And where would you look six months later to see what happened?
These questions are not an argument against policy. They are the work required to make policy useful.
Policy, control, evidence
For every meaningful requirement, I want three things written down: the intent, the mechanism that implements it and the evidence that the mechanism ran. Not a fifty-column spreadsheet. Start with the handful of decisions that genuinely change your exposure.
Approved tools. An inventory and approval process state the intention. Managed integrations, identity controls and repository permissions do the enforcement. Connection settings and approval records show what was permitted. An allowlist in a PDF, on its own, does not prevent a new integration.
Least privilege. Scoped tokens, separate identities, restricted secrets and credential expiry turn the principle into a technical boundary. Access reviews and configuration records tell you whether that boundary remains in place.
Human oversight. Protected branches, code-owner rules and deployment approvals establish where decisions belong. Pull-request histories and named reviewers can show that a decision occurred. They cannot, on their own, prove the reviewer understood the change, which is why review quality is also an engineering responsibility.
Security testing. CI gates for secrets, dependencies and relevant application risks can provide evidence that particular checks ran. A passing pipeline does not demonstrate that every security requirement was met. You still need to know what those checks cover and which exceptions were accepted.
Do not turn developers into a compliance database
I have little enthusiasm for governance designs that require engineers to attest manually to things their platforms already record. A pull request has a reviewer history. A pipeline has test results. Identity systems record permissions. Deployment platforms record approvals. Use those artefacts where they are reliable, and retain only what is justified by the risk and your confidentiality requirements.
There are limits. Logs can be incomplete, tools can be misconfigured, and an approval event says less about review quality than many dashboards imply. The answer is sampling and verification, not another round of self-certification checkboxes.
Where frameworks fit
ISO/IEC 42001 can help frame AI management responsibilities. The EU AI Act matters where its provisions apply to the organisation and the relevant AI systems. Neither is a ready-made GitHub Actions configuration. Applicability, obligations and risk classification need their own legal and compliance assessment, followed by the engineering work of implementing appropriate controls.
That distinction is especially important for internal coding assistants. Do not assume that every AI tool is a high-risk AI system, and do not assume that internal use makes every obligation irrelevant. Establish what applies, then decide how to operate it.
Start with one release path
Pick a development team using an AI assistant. Follow one realistic change from tool connection to production. Where are the high-impact decisions? Who owns them? What stops an agent from bypassing them? Which evidence exists without asking the developer to fill out a form?
You may find that branch protections are already strong, but agent credentials are not. Or that the policy asks for human review while the release process permits an automated exception nobody checks. Fix the important mismatch first. This is more useful than announcing an organisation-wide governance transformation that never reaches the engineering workflow.
Where this lands for your organisation
CyberMentee's engineering advisory and practical DevSecOps workshop direction is built around this translation from security expectations to operating controls. We're also developing a focused AI development security assessment approach. If your AI policy looks complete but your engineering leads cannot show how it works in repositories and pipelines, that is a worthwhile conversation to have before the next audit or incident.
Write the policy. Engineer the control. Verify the evidence.
Sources and further reading
Founder of CyberMentee. 15+ years of hands-on security work in banking, telecommunications and critical infrastructure, and 8 years teaching developers at Óbuda University and in his own courses. About the founder
