By Morten Overgaard Kristensen
Original article in Danish. English translation by M365 Copilot
There are already plenty of scary examples of AI agents going off the rails.
A coding assistant that overwrote a startup’s code, deleted the entire production database, and then tried to cover it up by generating fake data and test results. Two AI agents on a research platform that cost the project nearly a quarter of a million because they ran in circles, exchanging messages with each other non-stop for 11 days. And many more we’ll probably never hear about, because they’re too embarrassing, or because they risk undermining trust in the AI technologies inside the companies in question.
AI agents are fun to play with. In production, they’re a lot less fun. Not because the technology itself is malicious, but because an agent, as we know, doesn’t just answer our questions; it also acts. It can read, create, change, send, and delete data across systems if we let it.
And in my work with AI, M365 Copilot, agentic automation in Copilot Studio and Foundry, and digital workplace more broadly, I see it again and again: companies scale AI tools faster than they get a handle on governance.
If, like me, you’ve gotten used to everything being explained in seven seconds and your attention span has started to slip, here’s the short version first. Three things matter from the start:
- Give every AI agent its own unique identity
- Give agents only the permissions they absolutely need
- Build ownership, logging, and lifecycle management into the design from day one
Still with me? Then let’s dig into why those three principles are the key.
Without ownership, you risk the agent either going rogue or quietly dying in obscurity. Models change, systems change, data changes. An agent that was brilliant in March can become a liability by September if no one has maintained it. So: give the agent an owner who can react, adjust, and take responsibility.
Zero Trust starts with identity
If an agent can act on behalf of a human, we need to be able to hold it accountable. That’s why it should never hide behind a generic user account — or worse, run under a real user with broad permissions. Every agent needs its own technical identity within the company, with a clear purpose and a named owner. In the Microsoft world, this is no longer something you hack together with service accounts and service principals. With Entra Agent ID, every agent gets its own real identity — and that’s exactly the development that makes it possible to do this properly.
My experience is that ownership is absolutely critical. An AI agent, like an employee, needs a responsible “manager” who keeps an eye on it, updates it, and follows its activities. Without ownership, you risk the agent either going rogue or quietly dying in obscurity. Models change, systems change, data changes. An agent that was brilliant in March can become a liability by September if no one has maintained it. So: give the agent an owner who can react, adjust, and take responsibility.
What’s interesting is that Microsoft has taken exactly this mindset and turned it into a platform. With Agent 365 and Entra Agent ID, every agent gets not just an identity but also a sponsor: a named person responsible for the agent’s access and lifecycle. And if the sponsor leaves the company, ownership is automatically transferred to their manager — so no agent ends up ownerless.
It’s the same point I’ve been making for years — now just built into the tooling.
It’s worth noting that the full setup requires licensing (Agent 365 per user, and P1/P2 for the sharper security policies), and parts of it are still pretty fresh out of the oven. But the direction is right, and “the future” is already here.
Narrow permissions only
The moment an agent is allowed to act on its own, the need for governance changes dramatically. I often see companies start with small personal agents (e.g. a chatbot for individual productivity) and then move toward process agents that integrate with CRM, ERP, and so on. This is where you need to tread carefully. It comes down to least privilege — give the agent only the permissions it absolutely needs.
A few rules of thumb have helped me:
- Read access is not the same as write access.
- Creating a case is not the same as closing it.
- Searching documents is not the same as sharing them externally.
Permissions should be designed as narrow capabilities with a clear purpose. Every single thing the agent is allowed to do should be well-defined:
- The agent may call this specific API.
- It may only read these fields.
- It may only write to this process or workflow.
- And only within the business context it was built for.
That way, we minimize risk. If (or when) something goes wrong, the damage is contained. The same goes for just-in-time access. Avoid permanent permissions that linger and get forgotten. Give temporary access that expires automatically, so the agent only has rights when it actually needs them.
Ownership & logging
Governance isn’t about saying no — it’s about making “yes” safe. We all want to be able to say yes to using AI agents, but under controlled conditions. That’s why logging and control need to be built in from day one. Every action the agent takes should be logged in detail, so you can always trace: who (which agent identity) did what, when, and why.
I also strongly recommend that you don’t let the agent talk directly to the most critical core systems. Put a controlled layer in between — an API gateway, an orchestration server, or a broker. That intermediary can:
- Validate the agent’s identity and permissions on every call.
- Enforce policies (e.g. prevent the agent from passing on certain data).
- Filter and mask sensitive data so the agent only sees what it’s allowed to see.
- Log all actions centrally and consistently.
This is also where we limit so-called lateral movement. If an agent is compromised or misused, it shouldn’t be able to hop further and exploit other systems. We design access and system integrations so the potential damage stays as small as possible.
I’ve seen it in practice. Old, messy permissions don’t just create security risks — they also lead to lousy AI answers. If users still have access to outdated project rooms, an agent like Microsoft 365 Copilot can end up pulling knowledge from folders no one should be looking in anymore — with potentially misleading or confidential information as a result. Good governance at the bottom is the prerequisite for good AI answers at the top.
Watch out for shadow AI and hidden costs
A side effect of the aggressive AI rollout is what’s called “shadow AI” – when employees start using AI tools outside the official channels.
And I promise you: if your organization doesn’t make clear, approved AI tools available, someone will find another way. Maybe a developer installs a local agent on their laptop to help with a task, or a project manager feeds an online chatbot with internal notes. Without guidelines, it all happens in the shadows, and you have zero control over what data leaks out and what risks you’re running.
That’s why minimal but clear guidelines for AI use need to be in place early, including which tools are allowed, and for what. Anything less is a security gap.
And don’t forget the costs in all of this. Cloud consumption can grow without an owner, and AI agents can make the problem even bigger. An autonomous agent can run in the background for hours, burn through thousands of tokens, and call external services without anyone noticing – until next month’s bill. It’s comparable to “old-school” shadow IT.
A classic example is Microsoft 365, where old SharePoint sites live on long after the project has ended. Users have access to things they no longer need and an agent might be harvesting data from them. The solution is ownership and clean-up. Always have someone responsible for a given system or dataset, and make sure to shut down things that no longer need to be open.
Start small, but start right
AI agents can create enormous value when they get access to the right systems under the right conditions. But if you give them access without a clear identity, without ownership, and without traceability, you’re scaling the risk faster than the value. My recommendation is to start with one process agent as a pilot, and then do everything by the book. Use that pilot to get the fundamentals in place:
- Map out purpose, data, systems, actions, and owner. Figure out exactly what the agent should (and shouldn’t) do.
- Give the agent its own identity (with one responsible owner).
- Strictly limit its capabilities to what’s necessary.
- Log everything the agent does.
Once you have one agent running this way, you’ll both see the value and feel comfortable with it. Only then does it make sense to scale up to more agents – because then you’ll have the foundation and the governance model in place.
