AI Governance Through a Security Lens: Guardrails Before the Gold Rush

Every organisation I talk to is standing up an "AI governance" initiative, and most of them are building it in the wrong place. It lands with legal, or with a newly-minted ethics committee, and it produces a policy document that describes principles nobody can operationalise. Meanwhile the actual risk — sensitive data flowing into models, autonomous agents acting with real privileges, opaque decisions affecting real people — is a security and identity problem, and security teams are barely in the room. That is a mistake, because we are the people who already know how to turn principles into enforced controls.

The frameworks already exist — use them as a control spine

You do not need to invent AI governance from scratch. Three reference points do most of the heavy lifting:

• NIST AI Risk Management Framework — its four functions (Govern, Map, Measure, Manage) are deliberately familiar to anyone who has run a security program. Govern sets accountability; Map identifies context and risk; Measure assesses; Manage treats. It is a risk lifecycle, and you already operate one.
• ISO/IEC 42001 — an AI management system standard built in the image of ISO 27001. If you run an ISMS, you can run an AIMS; the muscle memory transfers directly.
• The EU AI Act — risk-tiered obligations (unacceptable, high-risk, limited, minimal) that, like GDPR before it, will set a de-facto global bar regardless of where you operate. In Australia, the Voluntary AI Safety Standard and its proposed guardrails for high-risk AI point the same direction.

The trap is treating these as compliance checklists. Read them instead as a control taxonomy: each obligation maps to a control you can design, assign an owner, and test — exactly the work security teams do every day.

An AI risk taxonomy a security person recognises

Strip away the novelty and AI risk decomposes into categories we already manage, plus a couple that are genuinely new:

• Data risk — what goes in. Sensitive or regulated data used for training or inference, leaked through prompts, or memorised and regurgitated by a model. This is data governance and classification, applied to a new consumer.
• Access risk — who and what can invoke the model and the data behind it. This is identity and access management, and it is where security has the most to offer.
• Model and supply-chain risk — third-party models, fine-tuning data, and the dependencies behind them. The OWASP Top 10 for LLM Applications catalogues the technical failure modes — prompt injection, insecure output handling, training-data poisoning, excessive agency — and reads like a threat model because it is one.
• Output and decision risk — the genuinely new part. Non-deterministic systems producing decisions that affect people, with explainability and bias obligations attached. This needs new controls, but it sits on the same accountability scaffolding as everything else.

The identity angle everyone underestimates

Here is the part the ethics-committee version of AI governance misses entirely: AI agents are non-human identities, and they are about to be the most privileged ones you have. An agent that can read your data, call your APIs, and take actions on a user's behalf needs an identity, an entitlement set, and a lifecycle — exactly like the service accounts I have written about before, except more autonomous and far less predictable. Govern AI without governing the identities through which it acts and you have written a policy about a thing you cannot actually control.

What a runnable AI governance program looks like

• An inventory. You cannot govern what you cannot see. Every AI system, model, and significant integration — including the ones business units adopted without telling you — in a register with an owner and a risk tier.
• Accountability before sophistication. NIST's Govern function exists first for a reason. Name an accountable owner for each AI use case before you debate technical controls. Ownerless AI is ungoverned AI.
• Risk-tiered controls. A chatbot summarising public docs and an agent approving transactions are not the same risk and should not carry the same controls. Tier them and apply rigour proportionally — the EU AI Act's instinct is correct.
• Controls mapped to your existing program. Data classification gates what models may touch. IAM governs who and what may invoke them. Logging and monitoring make AI actions auditable. Third-party risk covers model providers. You are extending, not rebuilding.
• Continuous measurement. Models drift, data shifts, and new failure modes emerge. Like any control program in a fast-changing environment, the testing cadence has to match the rate of change — which for AI is fast.

The takeaway

AI governance fails when it is written by people who can articulate principles but cannot enforce controls, and it succeeds when security and identity teams treat it as what it is: risk management for an unusually powerful new class of system, built on frameworks that map cleanly onto disciplines we already run. Get into the room early, bring the control taxonomy, and govern the identities through which AI acts. Do that, and you build the guardrails before the gold rush — instead of writing the incident report after it.