Vibe coding governance: a practical framework for employee-built apps

An employee built an app and colleagues now rely on it. Record the owner, running release, intended users and company data it can read. A reviewer needs those four facts to decide whether the team can keep using it.

Ask a colleague to show the task in the running app. Record the actual URL, release and data source. Find out who will fix a failure when the original builder is away.

In the fictional Northwind workspace, Cleo owns Sales Order Dashboard for Sales Operations. Its support contact is #sales-ops on Slack. Its restricted audience includes Cleo and Eli.

• Understand how informal tools become shadow IT →

List the app's purpose, current environment, release, owner and support contact. Visit the listed URL from a colleague's account before calling the entry ready.

• Review the App Portal's discovery and launch role →

Give the next owner access to the source, release history, build settings and support route. Ask them to make and verify one change using their own account.

• Use the ownership handoff checklist →

Use Direct to Production when the configured checks are enough. Configure Staged when a person must review the release in Development or UAT. Record the reviewer and the release they approved.

• Choose Direct or Staged deliberately →

Have the data owner approve access for this app and environment. Review fields and query limits for gateway data, or methods and paths for native API grants. Test one permitted request and one denied request.

• Plan application-specific company data access →

Test an intended colleague and an account outside the audience. Check the portal link and provider hostname separately. Save the release, test identity, expected outcome and observed result without credentials.

• Verify the colleague sharing path →
• Check the direct-origin boundary →

One possible rollout starts with a 30-day inventory of used apps and their owners. Over the next month, pilot an approval and sharing workflow on one app. By day 90, have a second owner reproduce the release, test access and retire outdated links.

Fill out one record for a real app. Keep its review decision, owner and next review date beside the release.

Purpose: Describe the business task and intended users.
Owner: Name the accountable App Owner and support contact.
Inventory: Record source, runtime, environment and working release.
Release path: Choose Direct or Staged and name required reviewers.
Data: Define the application environment's approved fields or native operations.
Access: Record the portal audience and separate origin protection.
Verification: Test the core task, a denied identity and revoked data access.
Changes: Re-review material increases in data, audience or runtime scope.
Exit: Record ownership transfer, suspension or retirement and remaining endpoints.
Exceptions: Name the decision owner, reason and next review point.

Recheck the release when the audience expands, sensitive data is added, the runtime changes or a new owner takes over. Record what changed, who approved it and who verified it.

• Use a concrete pre-launch checklist →

Ask whoever uses the app to show one real task. Record who built it, who owns it now, its source project, every running URL, and where it stores records. Use test data for the review.

• Check anonymous access to each URL and backing service. Contain an exposed route or credential before inviting colleagues.
• Choose Direct to Production or a staged review with the accountable owner. Review the app's own data grant even when its builder can read the source.
• Test the intended colleague and a denied account. Record who will support the app, when it will be reviewed again, and which old routes, tokens or grants must be retired.

• Record the team handoff →
• Run the launch security checklist →
• Research on exposed AI-built applications →
• Veracode's code-generation benchmark →