What the application can reach

Vendor Review will eventually notify a Procurement channel and create a record in an existing procurement system. Those integrations introduce a third identity to manage: the application itself.

If you copy a long-lived provider token into each project, removing an integration does not revoke its credentials. Someone must track those copies and revoke access when it is no longer needed.

Vercel Connect uses the deployment’s platform identity to issue short-lived, scoped access at runtime. A connector represents the approved relationship with the provider. The application requests access for a specific project, environment, subject, and supported permission set instead of storing the provider credential. Connect is in beta and available on all plans.

deployment identity → Connect policy → short-lived provider token
       │                    │
       │                    ├─ project, environment, permissions
       │                    └─ subject: application or named user
       └─ no copied provider secret in the application

Checkpoint: credential incident

Compare two versions of the same incident: a preview deployment logs the credential used to notify Procurement.

Version A: the project holds a long-lived Slack token also used by three other applications.

Version B: the deployment requested a short-lived token scoped to one project and environment, with the narrowest permissions the provider supports. Resource-level scope varies by provider, so do not assume that every connector can restrict a token to one channel, repository, or record.

For each version, answer:

• What can the leaked value do?
• How long can it do it?
• Which applications must be searched or changed?
• What must be revoked?
• What evidence identifies the affected project and environment?

Choose your path

Verify: If you have a supported provider account, attach one Connect connector to a non-production environment and inspect its token requests and revocation path.

Design: If you do not have a supported provider account, use the credential incident above and complete the access table. You do not need to create a token for this exercise.

List every system the application can access

Add a table under Systems the application can reach in docs/readiness.md. The rows below describe desired access, not verified connector capabilities. Check whether the provider can enforce each restriction and record any gap:

For each action, record whether the application uses its own identity or acts on behalf of a specific employee.

Act as a user only when required

Most Vendor Review automation should act as the application. When an external system must enforce the requesting employee’s own permissions, use a named-user subject instead. Passport can establish the verified employee identity at the application boundary, and Connect can request a token that acts on behalf of that named user after any required consent.

Vendor Review must still verify that the signed-in employee may request the action. The provider determines which scopes and resource restrictions its token supports.

Choose the narrowest access

For every integration, ask:

• Does it need read, write, or both?
• Does preview need production data?
• Can the application act as itself, or must a user delegate?
• How quickly can the access be revoked?
• Where can an operator inspect token requests, authorization, refresh, and revocation events?

Record any connector you configured and tested. If you completed only the access design, keep the control marked planned.

Commit the system-access decision:

git add docs/readiness.md
git commit -m "docs: record application access"

Summary

Connect gives an application or a named user short-lived, scoped access to approved systems. Your access table records what each integration needs, which environment can use it, and who can revoke access. Keep these permissions separate from builder access and employee sign-in.

Check your work

Write a revocation procedure for the Slack row. Name the credential or connector, the environments that lose access, the person allowed to restore it, and the log you would inspect to confirm the change. Record any untracked copies of long-lived credentials as an open gap.