A lot of AI governance work reads like policy work — principles, model cards, ethics review boards. All useful, none of it operational. The operational question is narrower and more familiar: what is this system allowed to touch, under what conditions, and who is accountable when it touches something it shouldn't have?
That's the same question identity and access management has been answering for accounts and services for two decades. An AI agent that can call tools, write files, or execute code is, structurally, a privileged principal — and it deserves the same discipline: scoped permissions instead of blanket access, time-boxed elevation instead of standing capability, and a log that survives the incident review.
Where it differs from a normal service account is unpredictability of intent. A deploy bot does one thing. A model deciding what to do next is closer to a junior employee with broad tool access and no manager watching every action — which argues for the same controls you'd put around that employee: a narrower default scope, a human checkpoint before anything irreversible, and an audit trail that records not just what happened but why the system believed it was allowed to.
Treat AI governance as an IAM problem with an unusually opinionated principal, and most of the tooling and process already exists. You're not inventing a new discipline — you're pointing an old one at a new kind of account.