Everyone Wants to Build a Copilot Agent. Almost Nobody Should.

The pitch is intoxicating. Open Microsoft 365 Copilot, describe in two sentences what you want, upload a couple of files, and thirty seconds later you have an agent. Your own little AI, wired into your SharePoint, ready to answer questions and do things. 🪄

So of course everyone wants one. The business wants a chatbot for the knowledge base. The pro-maker wants a flow that validates quotes. The developer wants a multi-agent orchestrator with their own model. Three people, three times the word "agent", three completely different products.

And here is the uncomfortable part: letting all of them just... build one, whenever they like, is a genuinely bad idea. 🧑‍🔬

Your scientists were so preoccupied with whether they could 🦖

Two clicks and a "citizen agent" is live, grounded in SharePoint, OneDrive and Graph, quietly reading whatever the maker can read. Could you let everyone do that? Absolutely. The tooling practically begs you to.

But an agent is a mini-application with real data access, one owner (maybe), and a lifecycle (probably not). An Agent Builder agent has no versioning, no rollback, no audit trail, and exactly one maker, right up until the day it becomes business-critical and that maker leaves. Now it is a load-bearing wall nobody remembers building. 🧱

Easy to birth. Hard to raise.

It's the supply chain, wearing a friendlier face 🔗

If that sounds familiar, it should. It is the same shape as every software supply-chain disaster of the last few years.

Take Axios, the HTTP library sitting quietly inside a large chunk of the internet. One maintainer, social-engineered. One old npm token from 2019 that skipped the modern security checks. One poisoned dependency slipped into a trusted update. 89 seconds from "latest" to first infection, and 100 million weekly downloads exposed before anyone pulled it, three and a half hours later.

The attacker did not attack the victims. They attacked the thing the victims trusted.

An agent you did not vet, wired to a connector you did not audit, running on data you did not scope, is a new link in exactly that kind of chain. And from 1 July 2026, chain security is not a best practice you can wave off, it is a board-level legal duty. "We let people build whatever they wanted" is not a great line to read aloud to a regulator. 📋

Three doors, and the maturity picks which one 🚪

When an agent is justified, there are three doors, and the trick is that your organisation's maturity chooses the door, not your enthusiasm:

• Agent Builder (phase 1, the Office makers): no-code, lives inside M365 Copilot, grounded in your files. Fast, friendly, and almost no governance.
• Copilot Studio (phase 2, the pro-makers): the governance layer. Cross-channel, 1400+ connectors, and crucially, environments, DLP policies and audit logs.
• Microsoft Foundry (phase 3, the developers): full pro-code control, your own models and CI/CD, and the full responsibility that comes with it.

Rule of thumb: the further right you go, the more you can do, and the more you must. A Foundry choice in phase 1 is an expensive lesson. An ungoverned Agent Builder agent that turns business-critical overnight is a time bomb.

The twelve things to look at before you build 🧭

Before anyone picks a door, these are the twelve criteria to walk past. Not all equally heavy for every organisation, but you have to have seen them:

1. Code complexity (no-code, low-code, or pro-code?)
2. Model selection (does anyone get a say in the model?)
3. Deployment target (where does it run, and who sees it?)
4. Lifecycle management (dev, test, prod, versions, rollback?)
5. Observability (do you know what it did, to whom, and why?)
6. Evaluations (how do you prove it is good enough before prod?)
7. Safety (content filters, prompt injection, identity?)
8. Tools & knowledge (what can it do, and where does it learn?)
9. Multi-agent (one agent, or several with hand-offs?)
10. Memory (does it remember, per user, per org?)
11. Audience (internal only, or external customers?)
12. Cost control (per-message pricing has surprised bigger teams than yours.)

So what do you actually do? ✅

You do not hand the keys to everyone. You restrict who can create and share agents to the people who can actually own the risk, exactly what the Agent Builder sharing controls exist for.

The rule is simple and it scales: use the approved tools (Copilot as it ships), and if someone wants something else, they file a request first. It gets checked for safety, and it gets discussed with whoever can genuinely manage the risk. That is not bureaucracy for its own sake. It is the difference between an agent estate you can defend and a pile of shadow mini-apps that can read the finance folder.

Wrap-up 🦖

Copilot agents are genuinely great, when the right person builds the right one, on the right door, for a reason someone signed off on. The problem was never that people can build them. It is that "can" and "should" got introduced at the party and nobody checked ID.

Give the keys to the people who can carry the risk. Point everyone else at the approved tools and the request form. And before you open any door, walk the twelve criteria, because the cheapest agent to govern is the one you thought about before it existed. 🧠

---

Want the full story, including the Axios attack in gory detail and the Agent Builder deep-dive? I turned it into a talk: Hoe bouw je een agent en waar moet je op letten?