Analysis 10 min read

# When Agents Launch the Database: Why AI Governance Has to Move Beyond the Repository

The software-development boundary is expanding. An agent can now generate code, launch a database, create tables, alter schemas, configure permissions, and interact with operational infrastructure — often without a human reviewing the diff. Platform vendors have noticed: when most new databases are created by agents rather than people, the old assumption that a human reviews each schema change no longer holds. A repository rule can govern code committed through Git. It cannot govern every action an agent takes through an API, a CLI, or a dashboard integration.

By Theo Valmis·June 2026

## Agents are now provisioning infrastructure

The headline number is striking on its own: Supabase reports that more than 60% of new databases on its platform are now started by an AI coding tool rather than by a person typing into a console — with Claude Code the single largest source. But the number is not the point. The point is what it reveals about where software work is happening.

Agents are no longer confined to generating application code that a human then reviews and commits. They provision infrastructure. They create tables, alter schemas, configure row-level security, and wire up integrations — actions that used to sit firmly on the human side of the boundary, behind a review.

When an agent can launch a database, the governance question is no longer “is this code correct?” It is “was this infrastructure change allowed, and who decided that?”

## The platforms are already adapting

Infrastructure vendors are responding to this shift in their product defaults. In a 2026 breaking change, Supabase made new tables in the public schema no longer automatically exposed through its Data API — explicitly because the old model assumed a human reviewed each schema change before it went live. Supabase stated plainly that agents, CLI scripts, and AI platforms now create tables, often without a human reviewing the diff, and moved to require an explicit Postgres grant before the API can see a table — enforced at the role layer regardless of how, or by whom, the table was created.

That is a vendor encoding governance into the platform because the human review step it used to rely on has quietly disappeared. It is a direct, external confirmation of the pattern: as agents act on infrastructure, safe defaults have to be enforced by the system, not assumed from a reviewer.

## Why repository-level governance is not enough

Most governance for AI-assisted development today is anchored to the repository. Linters, CI checks, branch protections, and review gates all operate on code that flows through Git. That is a real and useful layer — but it has a blind spot the size of everything that happens outside the commit.

An agent operating through a database API, a cloud CLI, a dashboard integration, or an external runtime can change the system without ever producing a diff that the repository sees. The architectural decision — “all schema changes go through a migration,” “this table must have row-level security,” “no service may be granted public access by default” — is exactly the kind of invariant that repository governance was meant to protect, and exactly the kind that an agent can now bypass by acting on a different surface.

Surface | Repo-level governance sees it? | Who governs it now
--- | --- | ---
Code committed via Git | Yes | CI, review, branch protection
Schema change via API | No | Often nobody
Permissions via dashboard | No | Often nobody
Infra change via CLI | No | Often nobody
Action via external agent runtime | No | The execution-surface layer

## Governance has to follow the agent

The lesson is not that the repository stops mattering. It is that governance can no longer be defined only where code lands. It has to propagate to the surfaces where agents actually act — the API call, the CLI invocation, the tool execution — and apply the same architectural decisions there.

This is the difference between governing a location and governing a decision. A decision like “no table is publicly readable without an explicit, reviewed grant” should hold whether the table was created by a migration in a pull request or by an agent calling an API at 3 a.m. The constraint belongs to the architecture, not to the path the change happened to take.

## What this validates

The shift to agent-provisioned infrastructure is an external proof point for a thesis that predates it: governance has to live below the prompt layer and across execution surfaces, not just in the codebase. Specifically, it validates the need for verification contracts that apply regardless of which tool made the change, deterministic enforcement that does not depend on a human being in the loop, and provenance for changes made outside the normal pull-request flow.

When agents launch the database, the repository is no longer the boundary of the system. Governance that stops at the commit stops short of where the work now happens.

## Frequently asked questions

Why does it matter that agents launch databases?+
Because provisioning infrastructure used to be a human action behind a review. When an agent creates tables, alters schemas, and configures permissions directly — often without a human reviewing the diff — the architectural decisions that govern infrastructure can be bypassed entirely, since most governance is anchored to code that flows through the repository.
Doesn't the repository still govern everything?+
No. Repository-level governance — CI, review, branch protection — only sees changes that arrive as a Git diff. An agent acting through a database API, a cloud CLI, a dashboard, or an external runtime can change the system without producing a diff the repository ever sees. That is a growing blind spot as agents act on more surfaces.
What are platforms doing about it?+
Some infrastructure vendors are changing their defaults — for example, no longer auto-exposing newly created tables through a data API — specifically because the old model assumed a human reviewed each schema change. They are moving toward explicit, reviewable grants enforced by the platform regardless of how or by whom a resource was created.
What does 'governance beyond the repository' actually mean?+
It means enforcing architectural decisions at the execution surfaces where agents act — the API call, the CLI command, the tool execution — not only where code is committed. A decision like 'no resource is public without an explicit reviewed grant' should hold whether the change came through a pull request or an agent calling an API directly.
Related governance concepts

- Execution Surfaces

  The growing set of places — tools, APIs, CLIs, runtimes — where agents act on a system.

- Governance Propagation

  Identical constraints fan out to every agent, tool, and surface, not just the repository.

- Artifact Provenance

  Knowing which agent or tool made a change, and which decision allowed it.

- Deterministic Enforcement

  Enforcement that does not depend on a human being in the loop.

Related operational essays

- The Governance Perimeter Is Moving to the Endpoint

  Centralized control collapses as autonomous execution spreads across surfaces.

- AI Is Becoming the Operating Layer for Software Execution

  Agents act on real infrastructure, not just code.

- The Agentic Infrastructure Attack Surface

  Every new surface an agent can act on is a new place governance has to reach.

- Architectural Zero Trust Verifies the Diff

  Trust the change, not the actor — wherever the change came from.