Govern employee-built AI apps and agents by assigning accountable owners and enforcing rules for access, data use, actions, and spending. Match review requirements to what each app can affect, then test those controls before broader use and revisit them when the app changes.
An employee might build a tool that summarizes supplier documents or an agent that updates sales records. Both need an owner, but the consequences of a mistake differ. Governance should make those differences explicit enough that a department can decide what to launch and a platform team can enforce the decision.
Copy link to headingWhat does governance cover?
AI governance connects company policies to how an app operates. For an internal app, that includes deciding who can use it and what information it may process. An agent also needs limits on actions through connected tools.
Consider an agent that reads customer emails and proposes changes to a customer relationship management system, or CRM. Permission to read an email does not authorize an account update. The company must decide which updates the agent may propose, who can approve them, and how to correct a mistake.
NIST's AI Risk Management Framework 1.0 provides voluntary guidance organized around govern, map, measure, and manage. It gives an enterprise a structure for assigning responsibility and assessing risk.
The OWASP Top 10 for Agentic Applications adds a security reference for systems that plan and act through tools. Use these references to review your operating model, with concrete decisions attached to each application.
Copy link to headingWho should be responsible for an employee-built app?
Assign a business owner who can decide whether the app is useful and whether its outputs are acceptable. That person may be a department manager rather than the employee who wrote the first version. The owner should understand the work well enough to recognize a harmful result.
Name a technical maintainer as well. The builder may fill that role during a small pilot, with support from engineering. As more people depend on the app, the company needs an explicit decision about who maintains integrations and responds when it fails.
Platform and security teams can provide common controls and review sensitive uses. Data owners decide which records the app may access. If a proposal involves a new external service or restricted information, the builder should know whether procurement or legal review is needed before work begins.
Keep a record for each app with its purpose, owner, deployment location, and connected systems. Include its intended users and a way to disable it. When the builder changes roles, review the record and confirm who will maintain the app.
Copy link to headingWhich controls should every app have?
Document the controls noted below so reviewers can check the basis for approval and business owners can explain a proposal without describing the code.
Sign-in and authorization need separate tests. Sign-in identifies a user; authorization determines what that user may do. Someone permitted to submit a purchase request may have no authority to approve it. Enforce that difference in application code or the connected service, wherever the action takes place.
Give agents access to the operations required for their task. For reporting, an agent may need to read sales data without editing it. If a connection acts through a shared service account, review that account's permissions explicitly. Storing its credential in a managed system does not reduce the authority the credential grants.
For model calls, decide what data may leave the company and under which provider terms. Providers may agree to exclude prompts from training while still retaining them. Include application logs and agent memory in the data review because they can hold copies of the same information.
Set a spending limit before a pilot expands. Specify who receives an alert and what users see when the limit blocks further requests. Model usage is one expense; also account for hosting and any paid tools the agent calls.
Copy link to headingHow should reviews differ between apps?
Assess what an error would affect and how the team could recover. Consider these two proposed uses, with the controls above in place:
The document tool's review can concentrate on the quality and use of its output. The CRM agent also needs evidence that the system enforces limits on its actions. If the document tool later accepts confidential supplier contracts, the data owner must review the new input before the team approves its use.
Copy link to headingWhen should an agent ask for approval?
Match approval to the consequences of the output or action. Draft reports may need review before anyone relies on them, while updates to customer records or external messages may need approval before the agent acts.
For the CRM agent, let the salesperson see the proposed record changes alongside the source email. Approval should apply to that specific update. If the agent changes the proposal, it should seek approval again before writing it.
The check belongs in the code that performs the action. Telling the model to ask first can help it follow the process, but the tool should also refuse an unapproved write. Record the reviewer and the approved action so the company can establish what permission was given.
Avoid a design in which every harmless read demands a click. Define a permitted range of activity, then put review at the point where the agent would exceed it. This gives reviewers a decision they can evaluate.
Copy link to headingHow should a prototype become a supported application?
Start with a limited pilot whose users understand the task and can identify errors. Agree on evidence for wider use, including answer accuracy on representative examples and users' ability to recover from a failed action.
Test the control boundaries alongside the normal workflow. Try an unauthorized user, a request for a restricted record, and an action without approval. For an agent that reads emails or documents, include content that tries to redirect its behavior. These tests should show whether the application enforces the policy when its model behaves unexpectedly.
Before broader rollout, confirm that a named person can disable the app and revoke its connections. Test whether the agent audit trail lets that person reconstruct an unsuccessful run, including any partial changes. Decide how long to keep those records and who may inspect them.
Record the app's permitted use as part of its approval. Review the app again before it starts applying CRM updates automatically, uses a new sensitive data source, or becomes available to another department. Those changes can alter the business risk even if the app stays on the same approved platform.
Copy link to headingWhat can a shared platform enforce?
Companies can use a shared deployment platform to configure common controls once and apply them across projects. The business owner still has to decide which users, data, and actions are appropriate.
On Vercel, Vercel Passport requires visitors to authenticate through a company identity provider before reaching a protected deployment. It is an Enterprise feature.
Vercel Connect manages provider connections using OAuth flows or stored API keys, with permissions that depend on the connection's configuration.
By default, AI Gateway deletes prompts and responses after requests complete. AI Gateway's data controls can also restrict routing to providers with verified zero data retention agreements. Its no-training filter does not apply when a request uses your own provider keys, so review the provider’s configuration and agreement.
The credentials an app uses determine which AI Gateway budgets apply. Requests using a deployment's platform identity count toward project and team budgets, while requests using an AI Gateway API key count toward the applicable key, user, and team budgets. Spending through your own provider keys does not count toward these limits. Test limits with the app's actual credentials and account for possible overspend, since budgets are checked before requests start.
These controls leave application-specific work to the team. Employees who sign in still need permission to approve a purchase, and permitted models can still produce incorrect answers. The Enterprise Apps and Agents course in the Vercel Academy illustrates how employee access and business permissions fit together.
Copy link to headingFrequently asked questions
Copy link to headingWho owns an employee-built AI app?
Name a business owner who is accountable for the app's purpose and acceptable use, alongside someone responsible for its technical maintenance. One person may hold both roles during a small pilot. Broader adoption needs an explicit support arrangement, especially if the original builder moves on.
Copy link to headingDoes an approved coding tool make the resulting app approved?
No. Approval to use a coding tool does not establish which data the finished app may access or which actions it may perform. Review the deployed application's intended use and permissions before people rely on it.
Copy link to headingDoes every agent action need approval?
Approval requirements should follow the consequences of the action. Your company might let an agent search authorized documents while requiring a reviewer before it changes a customer record. Enforce the approval rule at the point where the action executes.
Copy link to headingWhat changes should trigger another review?
Review changes that expand an app's authority or the consequences of an error. Examples include enabling writes, connecting restricted data, or making the app available to a new group. Replacing a model can also warrant renewed testing if the app depends on its behavior.
Copy link to headingDo platform controls make an app compliant?
No. Platform controls can support an organization's requirements, but compliance also depends on the use case and how the application handles data and decisions. Assess the complete application against the obligations that apply to it.