The governance checklist for vibe-coded apps, agents, and integrations

Answer for everything your teams have built, not one application.

Check a statement only if you could defend it in a security review.

0 of 16 confirmedOnly check what you could defend

Integration capacity

3 checks

Everything your teams built outside IT exists because they needed data and could not wait for it. This section asks whether that is still true. If it is, closing the other gaps buys you a quarter before they reopen.

We can state how long an integration request takes from submission to running in production, and the number is measured, not estimated.A team that needs data from a connected system gets it faster through the official route than by building the connection themselves with an AI assistant.We know which teams have built their own connections to production systems, and what those connections can reach.

Visibility

3 checks

You cannot govern, cost, or investigate what you cannot list. This section decides whether the rest of the checklist applies to everything running, or only to the applications you already happen to know about.

We can produce a current list of every vibe-coded app, agent, and integration our teams have built, with who built it and what it connects to.Every vibe-coded app, agent, and integration our teams have built produces a log of the actions it takes, retained on a defined schedule, and we can retrieve a specific action when asked.AI and infrastructure spend is attributable to the specific application that incurred it, and each application has a spend cap somebody reviews.

Identity and access

4 checks

Most incidents start with a credential rather than a bug. This section asks what your applications run as, what they can reach, and whether that matches what the person using them is allowed to see.

Access to every vibe-coded app our teams have built goes through our identity provider, not a login the app manages itself.When these applications reach a connected system, they act as the person using them, not as a shared token or service account.Each application can reach only the systems and data it needs, scoped independently of whoever built it, and cannot hand a user data they could not access directly.No credential for any of these applications sits in code, configuration, or a prompt. Secrets are held centrally and injected at runtime.

Path to production

6 checks

A prototype that works on one laptop is not the same as something the business can depend on. This section asks whether a defined route between the two exists, and what it checks before something goes live.

Nothing the business relies on depends on one person's laptop staying on. Everything runs on managed infrastructure.Applications are built and tested somewhere that is not production, and the route between the two is defined.An application that has not been reviewed cannot reach production systems. Approval is enforced by what it can connect to, not by a policy document.Every application has an accountable owner recorded centrally, and it is not only the person who built it.Actions that move money, change records in a system of record, or touch regulated data require a person to approve them.Model versions are pinned, and a model change is evaluated before it reaches anything running in production.

Unchecked statements are treated as gaps to establish, not failures.