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 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.

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:

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:

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:

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.