No Repo, No Owner: Governing AI Agents Built by Business Users

A marketing manager builds an agent in Copilot Studio that drafts customer emails from CRM records. It works. It also reads a field that happens to contain partial payment data, and nobody responsible for governing the environment knows the agent exists.

The manager isn't hiding anything. She doesn't think of what she built as an agent, and she has no way to instrument it even if someone asked her to. She solved a problem the way the company told her to: quickly, with the tools she was given.

Almost every piece of writing on agent governance, including ours, quietly assumes an engineer built the agent. There's a repo, a CI pipeline, someone who understands telemetry, and a team you can hand a requirement to. A growing share of enterprise agents don't come from that world. They come from finance, marketing, HR, and operations, built in Copilot Studio, GPT builders, Gemini agent tooling, or an internal low-code platform. None of the standard governance assumptions hold for them.

Business-user agents are a different problem, not a smaller one

Agents built by engineers can be governed at the point of creation. Code review, CI checks, and required instrumentation give you a chokepoint where governance attaches before anything ships. You can make tracing a merge requirement. You can ask the team to add a guardrail. There's a person, a process, and a place to enforce it.

Agents built inside a SaaS builder have no such chokepoint. There's no pull request, no pipeline, and often no one who considers themselves technically accountable for what they made. Governance can't sit at the point of creation because the point of creation is a form field in someone else's product.

So governance has to move. It shifts to the platform layer and to detection, and the controls have to be defaults rather than requirements, because there is no one to hand a requirement to.

This is worth stating plainly because it's easy to treat these builders as a risk to contain. They aren't. They're building because the organization asked them to move faster, and most of what they build is useful. The goal is to let them keep building without every new agent becoming an ungoverned unknown.

What actually breaks

Five assumptions carry most agent governance advice. For business-user agents, each one fails.

"There is a repo to instrument." There isn't. The agent lives inside a hosted builder, and the person who made it can't add tracing even if someone walked them through it. The whole model of instrumenting an agent to emit traces from day one assumes access to the code path. Here there is no code path to reach.

"Someone can be asked to fix it." The builder may not know their tool counts as an agent. They configured a workflow, not a system, and they don't think of themselves as responsible for its behavior. A request that assumes technical ownership lands on someone who never signed up for it.

"There is a registration step." Registration assumes the builder knows a process exists. Most don't. Worse, a registration form makes the shadow problem worse rather than better: the compliant teams register and everyone else keeps building, so the form filters for conscientiousness rather than for risk. The agents you most need to see are the ones least likely to fill it out.

"Policy can be written per agent." At business-user volume, per-agent policy doesn't scale. When there are thousands of agents and each one took an afternoon to build, you can't write a rubric for each. Policy has to attach to the platform, the data source, or the risk tier, not to individual agents.

"Evals require someone to define them." A business user can't write an evaluation rubric, and shouldn't have to. Defaults tuned to the data an agent touches have to do that work. An agent reading from a table with financial fields inherits the checks that data sensitivity demands, without anyone specifying them.

What actually works

The shift is from asking builders to comply to governing the surface they build on. If you can't attach governance to the agent at creation, attach it to the platform the agent is created in.

Detection over registration. Platform APIs advertise what exists. Copilot Studio, GPT builders, and low-code platforms expose what's been built through their own interfaces, and telemetry and network signals catch the rest. Discovery that reads those surfaces finds agents whether or not the builder knows a governance process exists, which is the only way to close a gap the builder can't see.

Policy scoped to data and platform, not to agents. Attach controls to the sensitivity of the data an agent touches and the platform it runs on. An agent that reads customer records inherits PII handling. An agent on a platform with external model providers inherits the checks that implies. The builder makes no decisions; the policy follows the data.

Guardrails on by default. Put the burden on exceptions, not on adoption. Guardrails that intercept bad inputs before they reach the model and bad outputs before they reach a user should be on for every agent on the platform, so the safe path is the default path and turning a control off is the deliberate act, not turning it on.

A named owner assigned at discovery. Ownership shouldn't be volunteered at creation, because it won't be. Assign an accountable owner when the agent is discovered, the same way turning a discovered inventory into a governable set of applications works for engineered agents. Every agent gets an owner whether or not the builder raised their hand.

Split purpose from controls. The business user owns the agent's purpose. They know what it's for, what a good answer looks like, and when it's wrong. A governance function owns its controls: the guardrails, the policies, the data access. Neither has to do the other's job, and neither should. The marketing manager keeps deciding what her email agent says. Someone else makes sure it never sends payment data to an external model.

Designing governance for the people already building

Meet the builders where they are, which means governing the platform, not the person. The compliant outcome has to require no expertise from someone who doesn't have any, because expecting it guarantees the gap you're trying to close.

Make the safe path the default path. When guardrails are on by default, policy follows the data, discovery finds what registration would miss, and ownership is assigned rather than requested, a finance analyst can build the agent they were asked to build and the result is governed without them doing anything governance-shaped at all.

That's how you let finance, HR, marketing, and operations keep moving fast without turning every new agent into a blind spot.

See it in your environment

Arthur discovers agents across the platforms your teams already build on and brings them under one governance framework, no matter who built them or where they run. Book a demo to see it against your own environment, or explore the Agent Development Toolkit to get started.

‍