--- 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-08-28T23:02:55.033Z" 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, so decide before this exercise whether you can configure it or will record the design as demonstrated or planned. ```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, then write the intended employee group and deny case. This proves the course deployment is private while keeping the company access design honest. ## 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 | Your exact groups may differ. The important separation is between operating the platform and deciding the business process. If your first table granted every platform administrator approval authority, revise it before choosing the identity mechanism. ## 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 Platform authentication answers who may reach the application. Vendor Review still needs application-level authorization for actions such as approving a request or viewing requests from another department. Signing in does not grant every permission inside the application. That distinction matters in **Make AI Decisions Dependable**, where 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 Try the production URL in a private browser and record the result. Then answer this without saying “Vercel team member”: how does a Procurement reviewer reach Vendor Review without receiving permission to change its deployment? If the answer is not configured in your environment, the named identity provider, group, and owner should appear as a planned control. --- [Full course index](/academy/llms.txt) · [Sitemap](/academy/sitemap.md)