Vercel

Access

Cloud Provider

Mycroft records Vercel team access, deployment protection settings and what shipped to production.

Where every merge ships, branch protection and deployment protection are doing the work a change advisory board is credited with. Mycroft ties each production deployment back to the approved merge that triggered it.

Find out more

How Mycroft connects to Vercel

How it connects: You issue a Vercel access token and give it to Mycroft along with your team ID.
What Mycroft can access: Read-only. Mycroft reads team, project and deployment metadata through the token, and does not write back.

Which controls Vercel evidence maps to

Each row is a control an auditor tests and the specific artifact Mycroft collects from Vercel to satisfy it. Collection runs on a schedule and every result is timestamped.

Vercel compliance control mappings and the evidence Mycroft collects for each
Framework	Control	What it requires	Evidence collected from Vercel
SOC 2	CC6.1	Logical access controls restrict access to information assets.	Team member roster with roles (owner, member, developer, viewer) and two-factor authentication enforcement status.
SOC 2	CC6.3	Access follows least privilege and is removed when no longer required.	Team and project-level access reconciled against the current workforce roster, with owners and elevated roles enumerated for review.
SOC 2	CC8.1	Changes are authorized and approved before being deployed.	Deployment history with commit, author and target environment, alongside the pull request approval from your connected code repository.
ISO 27001	A.8.31	Development, test and production environments are separated.	Project environment configuration showing distinct preview and production targets, with deployment protection settings on production.
ISO 27001	A.8.32	Changes are subject to change management procedures.	Production deployment records tied back to the reviewed and approved merge that triggered them.
ISO 27001	A.5.18	Access rights are provisioned, reviewed and removed.	Team membership included in the periodic user access review with reviewer decision and date recorded.

What Mycroft collects automatically

Gathered from Vercel on a schedule, dated and stored against the controls above.

Team roster with roles and two-factor authentication enforcement state
Project inventory with deployment protection and password protection settings
Environment configuration distinguishing preview from production
Deployment history: commit, author, environment and timestamp
Custom domain and TLS certificate configuration per project

Manual work this removes

The tasks that disappear from someone's quarter once Vercel is connected.

Assembling the team member list each quarter for the access review
Documenting that preview deployments are not publicly reachable
Tracing each sampled production deploy back to the pull request that authorized it
Identifying team members who have left the company

Often connected alongside:

All integrations →

Vercel and Mycroft: frequently asked questions

The connection uses a Vercel access token you issue, so its reach is whatever that token grants. Mycroft reads team, project and deployment metadata and does not write back. The token can be scoped to a single team.

Not on its own, which is why both are worth connecting. Vercel proves what was deployed to production and when; your code repository proves the change was reviewed and approved first. Mycroft joins the two so a sampled deploy comes back with its approving pull request attached.

Yes. Deployment protection and password protection settings are read per project and tested as a control, so a project that exposes preview environments publicly surfaces as a finding rather than as an incident.

We turn the compliance nightmare into a dream

Talk to us