Microsoft has told enterprises to treat their AI agents as insiders. Insiders are governed through identity: who they are, what they can reach, who answers for them, and when their access ends. Most organisations can’t yet answer those questions for their agents, and this month’s breaches show what that costs.
On 19 October, Microsoft’s security chief published a sentence you don’t often hear from a company that sells AI. “Frontier models, regardless of their origin, cannot be trusted,” wrote Hayete Gallot, Executive Vice President of Microsoft Security.
Her argument wasn’t that agents are malicious. It was that organisations deploy them internally, trust them implicitly, and give them broad reach. In her words, they’re “frequently overprivileged, have access to data, tools and systems” – which makes them something security teams already have a name for. Microsoft’s term is “agentic insiders”, and it’s the most useful reframe of AI risk this year.
Microsoft’s own answer is supervision. It’s adding Guardian Agents to its Project Perception programme to watch what agents do at runtime, and its agent discovery now covers 60 types of local agent. That’s welcome. But it starts in the wrong place, because the incidents of the past few weeks weren’t failures of supervision. They were failures of lifecycle.
This Month’s Breaches Weren’t Break-Ins
Read this month’s security news with Microsoft’s phrase in mind and a pattern appears. The attackers mostly didn’t break in. They used access that was legitimate, granted once, and no longer being watched.
In Denmark, the government disclosed on 5 October that a small private company’s lawful access to the national Central Person Register had been misused to reach the names, addresses, and CPR numbers of around 8.8 million people, including people who’ve died or emigrated. The misuse ran for days before an employee in the register’s administration spotted unusual activity. “It is clear to me that the security measures surrounding this company’s access to CPR have not been good enough,” said Digitalisation Minister Christina Egelund.
Three days earlier, the Technical University of Denmark disclosed that an attacker had logged in to DTUBasen, its identity and access management system, with compromised credentials and downloaded a large amount of data. Up to 200,000 people may be affected. Only around 40,000 of them are current users. Around 160,000 are people who’ve already left.
And on 8 and 9 October, roughly 1,900 compromised GitHub accounts were used to push credential-stealing workflows to more than 30,000 repositories, according to GitGuardian. The workflows went after machine credentials: cloud keys, package registry tokens, and AI provider API keys. Those are exactly the credentials agents run on.
None of these needed a clever exploit. Each needed an identity with more access, for longer, than anyone was actively governing. That’s the insider problem, and AI agents are about to multiply it.
Agents Are Joiners Nobody Onboarded
Identity teams have governed insiders through the same lifecycle for decades: joiner, mover, leaver. A person joins, and an HR record triggers an identity with birthright access. They move, and their access is meant to change with them. They leave, and their access is meant to end that day.
AI agents skip all three stages. They’re created the way shadow IT always was – someone with access spins one up, connects it to a mailbox, a CRM, or a repository, and gives it a token that carries their own permissions. There’s no HR record, no start date, no manager, and no end date. A JumpCloud survey reported this month found that 55% of organisations use or test agents capable of changing systems, permissions, records, or workflows. Among organisations already using agents, 59% haven’t fully extended their human identity and access policies to them, and only 18% require human approval before an agent takes a high-risk action.
The joiner gap means nobody decided what the agent should start with. The mover gap is worse for agents than for people, because adding a tool to an agent is a configuration change, not an access request, so scope only ever grows. And the leaver gap is where the risk settles: the pilot ends, the project’s shelved, or the person who built the agent leaves, and the agent and its token keep working. An agent nobody owns is a leaver who never left.
Supervision Needs Something to Supervise Against
Runtime monitoring can tell you what an agent is doing. It can’t tell you whether the agent should exist, who answers for it, or whether its access should have ended last quarter. Those are governance questions, and they sit upstream of anything a guardian agent can see.
Gallot’s own post lists the layers that securing agents requires: “identity, permissions, data, endpoints, network, cloud and runtime.” Identity heads that list. Runtime closes it. A guardian agent watching an unowned, overprivileged agent is a very attentive witness to a problem nobody designed out.
The good news is that the controls agents need already exist, in a discipline most enterprises have run for years: identity governance and administration. The real question is whether yours is automated enough to take on a new class of identity at machine pace.
What We Learned Fixing the Lifecycle for People
Our most recent case study describes a global professional services organisation moving from a legacy IAM platform to Okta Identity Governance. It wasn’t an AI project. It was a lifecycle project, and it built almost exactly the foundation agent governance now needs.
The legacy estate ran onboarding, role changes, and terminations through custom scripts, tightly coupled provisioning, and manual effort, with privileged and service accounts governed inconsistently. The new model made identity governance the central orchestration layer. Joiner-mover-leaver processes were automated end to end, including immediate access removal on termination, downstream account clean-up, and reassignment of account ownership. Access requests moved to self-service with multi-level approvals, and certifications became a standard, auditable workflow.
Three choices from that programme matter most for agents. First, non-human identities were governed alongside human ones, with privileged and service accounts brought under the same lifecycle as people rather than tracked in a side spreadsheet. Agents are the newest member of that class. Second, the team built a repeatable application onboarding framework, so every new integration went through the same requirements, identity model, provisioning rules, and access policies. That’s the mechanism that lets you add agents without starting a new project each time. Third, the migration ran in phased waves with the old and new platforms side by side, starting with lower-risk applications, so nothing depended on a big-bang cutover.
It also paid for itself. Retiring the legacy platform removed around $720K a year in recurring product and maintenance costs, before counting the infrastructure behind it. The organisations best placed to govern agents won’t be the ones that bought an agent-security tool first. They’ll be the ones whose identity lifecycle already runs itself.
Five Questions to Put to Every Agent
The case study closes on what good identity governance makes visible: who has access, what they can access, why it was granted, how it was approved, and when it should be removed. Those five questions were written for people. They work unchanged for agents.
Who answers for it? Every agent has a named human owner and a business sponsor. When the owner moves or leaves, ownership transfers automatically or the agent is suspended. No owner, no agent.
What can it reach? The agent runs on its own identity, with permissions scoped to its task, never on a borrowed human token or a shared API key. We’ve covered why shared agent credentials are so dangerous, and GhostAction is a reminder of how efficiently those keys get harvested.
Why does it exist? Each agent maps to an entry in a register that ties it to a use case. If nobody can name its purpose, it’s a candidate for retirement, not for review.
How was its access approved? Agents go through the same request-and-approval path as people, and high-risk actions are approved before they run, not found in the logs afterwards. Where an agent can commit money, the bar is higher still, as we set out in Your AI Agents Are About to Start Spending Your Money.
When does its access end? Every agent identity has an expiry date by default, a recertification cycle, and automatic revocation when its owner leaves or its project closes. An agent that cannot answer this question should not be in production.
Where to Start This Quarter
Find what’s already running. Vendor agent discovery will help, but your identity provider’s logs, your secrets scanner, and your OAuth app consents will show you more. Count the tokens and service accounts as well as the named agents, because those are the identities agents are already running on.
Close the leaver path first. DTU’s identity store held records for around four former users for every current one. Lifecycle debt builds up at the exit, so start there: an owner, an expiry date, and automatic revocation for every non-human identity you find.
Put new agents through the joiner door. No agent reaches production without an identity in your governance platform, an owner, a purpose, and an end date. Make the governed route the fast route, or people will route around it.
Extend what you have before you buy something new. If your identity governance already handles service accounts through request, approval, certification, and removal, agents can join that lifecycle. If it can’t, that’s the signal to modernise it – and as our case study showed, the business case for that can stand on its own.
Q&A: Governing AI Agents as Insiders
What does Microsoft mean by an “agentic insider”?
An AI agent deployed inside your organisation with access to its data, tools, and systems. Microsoft’s point is that these agents are trusted implicitly and are often overprivileged, so they carry insider risk even if nobody hacks them: they can be manipulated, make mistakes, or be compromised, and they act at machine speed.
Do AI agents need their own identities?
Yes. An agent running on a borrowed human token or a shared API key can’t be scoped, reviewed, or revoked on its own, and its actions can’t be cleanly attributed. Give each agent its own identity in your governance platform, with a named owner and permissions scoped to its task.
Can our existing identity governance platform govern AI agents?
Usually, as a starting point. Modern identity governance platforms already manage service and privileged accounts through request, approval, certification, and removal workflows, and agents can join that lifecycle as another class of identity. What changes is the pace: agents are created and re-scoped far faster than people, so the lifecycle has to be automated rather than ticket-driven.
What’s the first control to put in place?
The leaver path. Make sure every agent and every non-human identity has an owner and an expiry date, and that its access is revoked automatically when the owner leaves or the project closes. Most residual risk sits with identities that have outlived their purpose.
Is modernising identity governance worth it if we aren’t deploying agents yet?
It usually stands on its own. In our identity governance case study, retiring a legacy IAM platform removed recurring licence and maintenance costs while automating the joiner-mover-leaver lifecycle and bringing service accounts under governance. Readiness for agents came with it.
Working Through This With Vertex Agility
As an AI-native transformation consultancy, we see agent governance fall into the gap between two teams: the people deploying agents and the people governing identity. Our Cloud & Platform services cover the identity and access foundations, including the kind of governance modernisation in our case study, and our Security Healthcheck is a two-week Quickstart that includes an identity and access management review with actions.
If you’d like to see how ready your organisation is to run agents safely, our free AI Readiness Audit scores your governance and risk posture alongside your data, use cases, and skills. It takes minutes, and it’ll show you where the lifecycle gaps are before an incident does.