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.

A conventional integration copies a long-lived provider token into each project. The token often outlives the feature, its owner, and anyone’s memory of why it exists.

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 provider account handy, use the credential incident below and complete the access table. Do not create a permanent token solely to have something to rotate later. That would be an unusually committed teaching aid.

List every system the application can access

Add a table under Systems the application can reach in docs/readiness.md:

If an action must occur on behalf of a specific employee, record that separately from application identity. Delegated user access should be explicit; “the agent has access” is not an adequate description.

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.

This does not turn authentication into authorization. Vendor Review must still verify that the signed-in employee may request the action, and the provider ultimately 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?

Connect is available for hands-on exploration, but the main course does not require a live third-party account. If you follow the public quickstart, record what you actually configured. Otherwise record this control as planned and preserve the completed access design.

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 without copying permanent provider credentials into every project. If a credential leaks, Connect limits what it can do and how long it remains useful. It also gives teams one place to manage and observe the relationship.

The three kinds of access are now distinct: managed builders own and deploy, employees sign in to the application, and the deployment receives limited access to approved systems.

Check your work

Choose the Slack row and revoke it on paper. Name the credential or connector, the environments that lose access, the person allowed to restore it, and the log that confirms the change. If the answer begins with “search every project for a token,” keep the long-lived credential recorded as an open gap.