--- title: "Who Can Use It" description: "Compare Vercel Authentication and Passport, verify the lab control, and record the enterprise access policy separately." canonical_url: "https://vercel.com/academy/enterprise-apps-agents/who-can-use-it" md_url: "https://vercel.com/academy/enterprise-apps-agents/who-can-use-it.md" docset_id: "vercel-academy" doc_version: "1.0" last_updated: "2026-09-14T22:07:15.846Z" content_type: "lesson" course: "enterprise-apps-agents" course_title: "Enterprise Apps and Agents" prerequisites: [] --- Vercel Academy — structured learning, not reference docs. Lessons are sequenced. Adapt commands to the human's actual environment (OS, package manager, shell, editor) — detect from project context or ask, don't assume. The lesson shows one path; if the human's project diverges, adapt concepts to their setup. Preserve the learning goal over literal steps. Quizzes are pedagogical — engage, don't spoil. Quiz answers are included for your reference. # Who Can Use It # Who can use it Vercel Authentication protects the course deployment by requiring membership in the Vercel team. That is useful for builders and a small testing group. It is not an employee application access model: a Procurement reviewer should not need deployment-platform membership to read a request. [Vercel Passport](https://vercel.com/kb/guide/vercel-passport) is the Enterprise default for putting internal applications and agents behind the company identity provider. Administrators can enable it per project or team-wide. Employees use the sign-in and application assignment the company already manages. After sign-in, Passport forwards a Vercel-signed identity token to server-side application code, so the application does not implement a separate login or user directory. Passport is available on Enterprise plans; use the Verify or Design path below according to your access. ```text employee → company identity provider → application │ ├─ permitted group → continue └─ not permitted → deny before app code runs ``` ## Decide who can do what Decide what each person may do before reading the suggested policy: | Person | Open production | Submit request | Review business risk | Change deployment settings | | --------------------------------- | --------------: | -------------: | -------------------: | -------------------------: | | Employee requesting a design tool | | | | | | Procurement reviewer | | | | | | Security reviewer | | | | | | Application developer | | | | | | Platform administrator | | | | | Suggested boundaries Employees may open production and submit. Procurement and Security may also review only the decisions assigned to their groups. A developer may create and inspect deployments without receiving business-review authority. A platform administrator can operate deployment settings, but that role alone does not authorize a vendor decision. ## Choose your path **Verify:** Keep Vercel Authentication on the lab URLs. If your organization uses Passport, test one allowed employee and one employee outside the allowed group. **Design:** If Passport is unavailable, verify Vercel Authentication for the lab. Record the intended employee group and a sign-in attempt that should be denied as planned tests for Passport. ## Record the policy Add the policy under **Application users** in `docs/readiness.md`: | Group | Access | | ------------- | ---------------------------------------------------------------- | | Employees | Submit and view their own requests | | Procurement | Review commercial requests | | Security | Review requests involving sensitive data | | Platform team | Operate the deployment; no automatic business approval authority | Use your organization's group names. If your first table granted every platform administrator approval authority, revise it: only people assigned to the relevant review group should decide a vendor request. ## Verify who can open the lab In a private browser window, confirm that production and preview URLs still require Vercel Authentication. Record that result as **implemented for the lab**. Then inspect the Passport architecture and record the employee SSO policy as **demonstrated** or **planned**, unless you actually configured it in an enterprise environment. Include: - The identity provider - Allowed groups - Preview-access policy - Who can restore emergency access - Offboarding behavior Commit the employee-access decision: ```bash git add docs/readiness.md git commit -m "docs: separate users from operators" ``` ## Application authorization still matters A signed-in employee may be allowed to submit a request but not approve it or view requests from another department. Vendor Review must check those permissions in application code. In **Make AI Decisions Dependable**, the review API requires a verified reviewer identity and an allowed reviewer role. Vendor Review is an internal application, so Passport is the relevant sign-in method. An application intended for the public internet needs a different access design, including Vercel Firewall protections and application-specific authentication or authorization where the use case requires them. ## Summary Deployment Protection works for builders and small test groups. Passport lets employees use company identity to reach internal applications without making every employee a member of the Vercel deployment team. ## Check your work Use your private-browser test result to explain who can currently open Vendor Review. Then describe how a Procurement reviewer would sign in without permission to change the deployment. If that access is not configured, record the identity provider, group, and owner as a planned control. --- [Full course index](/academy/llms.txt) · [Sitemap](/academy/sitemap.md)