What is "data governance" when employees build AI agents

With Speculos we talk to companies rolling out AI internally, and the same three worries come up every time: data governance, cost, and vendor lock-in. This post is about the first one, because it is the one where the conversation goes in circles the most. Everyone says data governance and means something different. When I ask what exactly they are worried about, it comes down to three separate problems.

1. Keeping the data inside

This is the one everybody starts with. If employees are building agents and apps on customer data, contracts, or source code, that data cannot go to a vendor's cloud to be processed.

The way to do it is to run the platform that builds and runs the agents (the harness) on your own infrastructure. On AWS that means an AMI in your account, and Azure and Google Cloud have the equivalent. The models come through your own keys, whether that is Bedrock, Azure OpenAI, Vertex, or open weights you host, and the connectors to your databases stay inside your network. Nothing leaves.

It sounds simple when you say it in one sentence. It is not. Most AI builder tools are hosted products, they were never packaged to run inside someone else's account, and the ones that offer it usually mean a private tenant on their cloud, which is not the same thing. Getting a real harness running as an AMI, with your SSO in front of it and your keys behind it, is work.

2. The right people can build with the right data

The second problem is access, and it is bigger than it sounds. Your finance database, your HR system and your support tickets already have rules about who can read what. The usual answer is to apply those rules to the AI tool, and that is necessary, but it only gets you to people reading data in a chat.

Building an agent or an app on that data is a different thing. The person building needs the harness to see the sources she was granted, read their schema, and build against them without her ever pasting a credential anywhere. That takes an orchestrator sitting between the builder and the data, which is a component most companies do not have today, and it takes an admin who can connect each source once, at the company level, grant it person by person, and take it back the same way.

Without that layer, what actually happens is that people export a CSV or paste a connection string into a prompt, and the governance you set up on the warehouse is gone.

3. What happens after someone builds something

This one rarely comes up in the first meeting. It comes up after the first agent gets shared.

Say someone in finance builds an agent on top of the revenue database. It works, it is useful, and she shares the link with forty people. When one of those people asks the agent a question, does the data get filtered to what the person has access to?

In many tools the answer is no. The agent was built with the finance person's access and it keeps that access when it runs. So a person who cannot open the revenue database can now open an agent that can. Nobody bypassed anything, someone just shared a link.

The tools that avoid this by running the agent as whoever opens it have the opposite problem: all forty people have to connect the source themselves before it shows anything, so it never gets used.

This is where the orchestrator from problem two earns its place. Because the connectors exist at the company level, an app can point to a source instead of carrying a copy of someone's personal access token. And when the app is deployed, the orchestrator bundles the connector with it, so that access gets checked against what the admin granted each person who opens it to only show the data from the connector they have access to. IT also gets the thing they ask for first: a list of every app and agent in the company and the sources each one touches.

Bringing this into your organization

These three problems are what we built Speculos for.

It is an open-source harness that runs on your servers, on AWS as an AMI in your account, with your own LLM keys.

Your company connects its data sources once, an admin decides who can use each one, and people build agents and apps against the sources they were granted without touching a credential.

When an app is deployed, the connector is bundled with it, so it works for everyone who was granted the source and for nobody else. IT sees every app and agent the org has shipped and what each one touches.

If a team wants help putting it on their infrastructure, our engineers do the implementation with their IT. More at speculos.ai.