Your team has already built an AI agent. Can you assure it?

There’s a version of the AI risk conversation that’s comfortable, because it’s about someone else. A vendor pitches you an agent, you run due diligence, you decide. The risk arrives at the front door, announced, and you get to inspect it.

This post is about the other version. The one where the agent is already running, nobody procured it, and the person who built it sits three desks away in your finance team. It is general guidance, not legal advice.

The shadow has changed shape

Shadow IT is an old problem. Shadow AI is its current form, and most security teams have made peace with the idea that employees paste sensitive text into consumer chatbots. That’s a data exposure event, and it’s serious, but it’s bounded: the blast radius is roughly what one person can copy and paste in one session.

Agents break that boundary. The pattern security researchers flagged through 2026 is not employees using AI, but employees building it, technically capable people in finance, operations and marketing creating autonomous workflows that connect to CRMs, SharePoint, internal APIs and email systems. The tools make it easy: an AI-powered IDE in agent mode, a no-code automation platform, a custom GPT wired to an internal database. None of it touches procurement. None of it appears in a contract. Microsoft’s Cyber Pulse 2026 found that 29 percent of employees use unsanctioned agents for work tasks.

The difference in exposure is the whole point. A shadow agent with read and write access to a CRM can pull every deal, every contact note and every forecast figure, and feed it to an external model as context on every run. The human pasting into a chatbot does it once. The agent does it on a schedule, unattended, until someone notices.

Why your existing governance does not catch this

The instinct is to reach for the controls you already have. They were built for a different kind of actor, and the mismatch is structural rather than a matter of tuning.

Human identity and access management assumes relatively stable roles, predictable behaviour and clear accountability: when something goes wrong with an employee, the firm has an identity to investigate, an access log to review and a manager to notify. An internally built agent fits none of those assumptions. It is ephemeral, existing for minutes to complete a task and then spinning down; dynamic, accessing different resources based on real-time reasoning about what it needs; and autonomous, making decisions with no human in the loop at each step.

So the agent your colleague built authenticates as them, inherits their access, and acts at machine speed and scale, while your monitoring is watching for a human pattern of behaviour it will never produce. 2026 data puts the average enterprise at 37 deployed agents, with more than half running without security oversight or logging. Most organisations cannot produce a list of the agents operating inside their own walls, which means the first real inventory usually happens after an incident, not before.

The seven build stages, turned inward

Anyone building an AI agent works through the same sequence: define the goal, choose a model, pick a framework, give it memory, connect it to tools, manage its context, and test it. We’ve written separately about asking a vendor those seven questions. The questions don’t change when the agent is built in-house. What changes is that there’s no supplier to direct them at, so you have to ask them of your own team, and they’re harder to answer honestly.

When your colleague wired their agent to a model, did anyone check which provider’s terms now apply to the company data flowing through it, or whether that data trains a future model version? When they reached for a framework, did anyone assess that open-source dependency the way procurement would assess a SaaS vendor? When they gave the agent memory, did anyone ask where that data now sits, whether it holds personal data, and whether a DPIA was needed? When they connected it to the CRM, did anyone apply least privilege, or did the agent simply inherit the builder’s full access because that was the path of least resistance?

For a vendor agent, a security questionnaire and a SOC 2 report stand in for those answers. For an internally built agent, no questionnaire exists. The only question is whether your organisation created the conditions for someone to build carefully, or to build fast and quiet because asking would have meant waiting.

This is not a discipline problem

It is tempting to treat shadow agents as a compliance failure by the people who built them. That framing will cost you, because it drives the behaviour further underground precisely when you need visibility most.

The people building these agents are not rebelling; they are solving real problems with the most effective tools available. There’s a reason they don’t wait: sanctioned enterprise AI tools reach production successfully only around 5 percent of the time, while consumer tools get there roughly 40 percent of the time. Your highest performers are the most likely to build, because they are the least willing to wait for an official tool that may never ship. Punish discovery and you teach them to hide it. The organisations that get this right make disclosure safe, then govern what surfaces.

This is the thinking behind the AI Amnesty approach we use with clients: borrowed from the old USB amnesty model, it gives people a route to declare what they’ve built without blame, so the organisation can see its real AI footprint and bring it under governance. Shadow AI discovery turns that surfaced picture into an inventory. The amnesty is what makes the inventory honest.

What to do in the next thirty days

You do not need a finished AI strategy to start. You need to convert an unknown into a list.

Begin with discovery, not policy. A policy written against an AI footprint you cannot see is a guess. Establish what is actually running first: which agents exist, who built them, what data and systems each can reach, and whether any action they take is logged. Run it as an amnesty rather than an audit, so the people with the answers have a reason to come forward. Assign every agent you find a named human owner, the single control that most consistently separates governed AI from ungoverned. Then triage by blast radius: an agent with write access to financial or customer systems matters more than one summarising public documents, and your first deep assessments should follow the access, not the build date.

None of this requires you to slow your organisation down. It requires you to know what your organisation has already built.

Questions security and compliance teams are asking us about internal AI agents

How do we find AI agents our own employees have built?

Start with an amnesty rather than surveillance, because the people who built them are your fastest route to a complete picture and will disclose far more readily if disclosure is safe. Combine that with technical discovery across the platforms where agents are commonly built: AI-enabled IDEs, no-code automation tools, and custom GPT or assistant integrations connected to internal systems. The goal of the first pass is a list of what exists and what each agent can reach, not a judgement on any of it.

Who should own an internally built AI agent once we find it?

A named human, recorded against the agent, accountable for its scope, its access and its continued operation. Ownership is the control that most reliably separates a governed agent from an ungoverned one, and it cannot be a team or a committee. It has to be a person who would be notified if the agent behaved unexpectedly and who has authority to switch it off.

Is an employee building an AI agent a security incident?

Not in itself, and treating it as one is usually counterproductive. Building an agent to solve a real problem is reasonable behaviour; the risk lies in that agent being ungoverned, unmonitored and unknown to security, not in its existence. Reserve incident handling for actual exposure, and treat discovery as governance, so that people keep disclosing rather than learning to hide.

Does an internally built agent need a DPIA?

Very likely, if it processes personal data, informs decisions about individuals, or operates at scale, and internal builds reach those thresholds just as readily as procured systems. The fact that no supplier was involved removes none of the obligation. In practice the memory and data-connection stages are where personal data quietly enters scope, so those are the first places to look when assessing one.

If your organisation is moving faster than its AI governance, our vCAIRO service provides the fractional AI risk oversight to bring internally built agents under control without bringing the people who built them to a halt. Speak to our team about where to start.