The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jun 12, 2026 6:30am

PR Summary

Medium Risk
New server routes handle OAuth secrets and can upload/submit auditor-visible evidence; mitigations include internal auth, file access checks, and size limits, but mis-scoped credentials or workflows could affect real Vanta data.

Overview
Adds a Vanta security/compliance integration end-to-end: 29 workflow tools (frameworks, controls, tests and failing entities, evidence documents, people, policies, vendors, devices, vulnerabilities, risk scenarios) plus a large Vanta block, registry wiring, VantaIcon, docs (vanta.mdx, integrations catalog), and icon mappings.

Server-side access goes through /api/tools/vanta/query, upload, and download, with Zod contracts, internal auth, OAuth client-credentials per request (US vs Gov base URL), normalized API responses, and scoped tokens for read/write/document upload. Evidence upload uses the existing file pipeline and access checks; download streams with a 100MB cap and returns base64 execution files.

Submit document is a write operation on the query route. BlockMeta adds templates and agent skills for common compliance workflows.

^{Reviewed by Cursor Bugbot for commit c160878. Configure here.}

@greptile

@cursor review

@greptile

@cursor review

Greptile Summary

This PR adds a complete Vanta integration with 29 tools spanning compliance frameworks, controls, tests, evidence documents (upload/download/submit), people, policies, vendors, monitored computers, vulnerabilities, and risk scenarios. Auth is handled server-side via OAuth client credentials with an in-memory token cache that includes SHA-256 hashing of secrets, scope-based cache keys, concurrent-request deduplication, and a 401-triggered force-refresh retry.

• Three internal API routes (/api/tools/vanta/query|upload|download) behind withRouteHandler + checkInternalAuth; the download route uses an incremental streaming read to enforce the 100 MB cap without buffering; the upload route validates fileContent size at the schema level before Buffer.from allocates.
• All tool params, normalizers, and contract schemas are cross-validated against Vanta's OpenAPI spec; a Zod discriminated union covers all 27 query operations, and the block's params function correctly applies dropdown/tri-state transformations while letting the executor auto-merge the raw block inputs.

Confidence Score: 5/5

Safe to merge; the one open question is whether Vanta's single-active-token-per-application constraint is global across scopes or per-scope, which determines whether the current scope-split caching causes extra retries in mixed read/write workflows.

Auth logic, token caching (SHA-256 hashing, TTL buffer, in-flight deduplication, 401 retry), upload size guards (schema-level .max() + post-decode check), and download size cap (incremental streaming read) all look correct. No missing required fields, broken contracts, or data-loss paths were found.

apps/sim/tools/vanta/utils.ts — specifically the three scope-keyed token cache entries and whether they interact correctly with Vanta's per-application token revocation behavior.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Block as Vanta Block
    participant QR as /api/tools/vanta/query
    participant UR as /api/tools/vanta/upload
    participant DR as /api/tools/vanta/download
    participant Cache as Token Cache (in-memory)
    participant Vanta as Vanta API

    Block->>QR: "POST {operation, clientId, clientSecret}"
    QR->>QR: checkInternalAuth
    QR->>Cache: vantaTokenCacheKey(sha256(secret))
    alt cache hit
        Cache-->>QR: cached token
    else cache miss / expired
        QR->>Vanta: POST /oauth/token
        Vanta-->>QR: access_token
        QR->>Cache: store with TTL-10min
    end
    QR->>Vanta: GET/POST /v1/resource
    alt 401 token revoked
        Vanta-->>QR: 401
        QR->>Vanta: POST /oauth/token forceRefresh
        Vanta-->>QR: new token
        QR->>Vanta: retry request
    end
    Vanta-->>QR: response
    QR-->>Block: success + normalized output

    Block->>UR: "POST {documentId, file}"
    UR->>UR: checkInternalAuth + assertToolFileAccess
    UR->>Vanta: POST /v1/documents/id/uploads multipart
    Vanta-->>UR: file metadata
    UR-->>Block: success + upload

    Block->>DR: "POST {documentId, uploadedFileId}"
    DR->>DR: checkInternalAuth
    DR->>Vanta: GET /v1/documents/id/uploads/fileId/media
    Vanta-->>DR: binary stream
    DR->>DR: readBodyWithLimit 100MB
    DR-->>Block: success + base64 file

_{Reviews (9): Last reviewed commit: "improvement(integrations): expose vanta ..." | Re-trigger Greptile}

Greptile Summary

This PR adds a Vanta integration with 29 tools spanning compliance frameworks, controls, tests, evidence documents (list/get/upload/download/submit), people, policies, vendors, monitored computers, vulnerabilities, and risk scenarios. Auth uses Vanta's OAuth client-credentials flow exchanged server-side on each request, with three internal Next.js routes protected by checkInternalAuth.

• All 29 tools are backed by Zod-validated discriminated-union contracts and defensive normalizers that guard every field against null/wrong-type values from the Vanta API.
• Evidence file upload supports both a direct UserFile pipeline (with storage-access authorization) and a raw base64 fallback; download streams the binary back as base64 with content-length and post-decode size guards.
• normalizeVantaPolicy reads latestVersionStatus from the nested path resource.latestVersion.status; if Vanta returns this as a flat top-level string field (as the TypeScript type and output descriptor suggest), every policy response will silently return null for that field.
• fileContent in the upload contract is declared z.string().nullish() without a .max() bound, so a large base64 payload (≈133 MB for the 100 MB limit) is fully decoded into memory before the size guard fires.

Confidence Score: 3/5

The core routing, auth, and normalization logic is well-structured, but two correctness issues in the new code need addressing before merging: a field-path mismatch in the policy normalizer that silently drops latestVersionStatus, and a missing schema-level size bound on the base64 upload path.

The policy normalizer reads latestVersionStatus from a nested latestVersion.status path that is unlikely to match the actual Vanta API response shape, silently returning null for every policy. The fileContent contract field has no .max() constraint, allowing an authenticated caller to trigger a large in-memory allocation before the 100 MB guard fires. Both issues are in newly introduced code and affect live behavior.

apps/sim/tools/vanta/utils.ts (normalizeVantaPolicy field path), apps/sim/lib/api/contracts/tools/vanta.ts (fileContent size bound), apps/sim/app/api/tools/vanta/query/route.ts and download/route.ts (auth outside try/catch)

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Tool as Vanta Tool (client)
    participant QRoute as /api/tools/vanta/query
    participant URoute as /api/tools/vanta/upload
    participant DRoute as /api/tools/vanta/download
    participant Auth as checkInternalAuth
    participant VantaOAuth as Vanta /oauth/token
    participant VantaAPI as Vanta REST API

    Note over Tool,VantaAPI: Query / read flow (27 operations)
    Tool->>QRoute: "POST {operation, clientId, clientSecret}"
    QRoute->>Auth: checkInternalAuth(request)
    Auth-->>QRoute: "{success, userId}"
    QRoute->>VantaOAuth: "POST {client_credentials, scope: read}"
    VantaOAuth-->>QRoute: "{access_token}"
    QRoute->>VantaAPI: GET/POST (operation URL, Bearer token)
    VantaAPI-->>QRoute: raw JSON
    QRoute-->>Tool: "{success, output: normalizedData}"

    Note over Tool,VantaAPI: Upload evidence file flow
    Tool->>URoute: "POST {clientId, clientSecret, documentId, file|fileContent}"
    URoute->>Auth: checkInternalAuth(request)
    Auth-->>URoute: "{success, userId}"
    URoute->>URoute: processFilesToUserFiles / Buffer.from(base64)
    URoute->>VantaOAuth: "POST {client_credentials, scope: read+write+upload}"
    VantaOAuth-->>URoute: "{access_token}"
    URoute->>VantaAPI: "POST /documents/{id}/uploads (multipart)"
    VantaAPI-->>URoute: uploaded file metadata
    URoute-->>Tool: "{success, output: {upload}}"

    Note over Tool,VantaAPI: Download evidence file flow
    Tool->>DRoute: "POST {clientId, clientSecret, documentId, uploadedFileId}"
    DRoute->>Auth: checkInternalAuth(request)
    Auth-->>DRoute: "{success}"
    DRoute->>VantaOAuth: "POST {client_credentials, scope: read}"
    VantaOAuth-->>DRoute: "{access_token}"
    DRoute->>VantaAPI: "GET /documents/{id}/uploads/{fileId}/media"
    VantaAPI-->>DRoute: binary file data
    DRoute-->>Tool: "{success, output: {file: {name, mimeType, data, size}}}"

_{Reviews (2): Last reviewed commit: "fix(integrations): use write-only scope ..." | Re-trigger Greptile}

@greptile

@cursor review

Greptile Summary

This PR adds a full Vanta integration with 29 tools spanning compliance frameworks, controls, tests, evidence documents (upload/download/submit), people, policies, vendors, monitored computers, vulnerabilities, and risk scenarios. Auth is handled via OAuth client credentials exchanged server-side per request, with three dedicated internal API routes (/api/tools/vanta/query|upload|download) protected by withRouteHandler and checkInternalAuth.

• Query route: a discriminated-union handler backed by exhaustive Zod contracts validates 27 operations, builds Vanta API URLs, and normalizes responses field-by-field against Vanta's OpenAPI spec.
• Upload route: routes evidence files through the existing processFilesToUserFiles/assertToolFileAccess pipeline before posting multipart data to Vanta, with a 100 MB size guard; auth check sits inside the try block (inconsistently with the other two routes) and could surface as 500 on unusual auth exceptions.
• Block: the config.params function correctly handles all renaming/transformation cases (e.g., documentStatusFilter→statusMatchesAny, tri-state dropdowns→booleans), relying on the generic handler's { ...inputs, ...transformedParams } merge for same-named pass-through params.

Confidence Score: 4/5

Safe to merge with the concurrent-token issue noted; it only manifests when two Vanta tool calls share credentials and run in parallel.

The integration is well-structured with thorough Zod contract validation, correct credential visibility, proper file-access authorization in the upload path, and solid normalizers for all 14 resource types. The two areas that could bite in production are the token-per-request pattern (Vanta invalidates prior tokens on each exchange, so parallel executions with the same credentials race) and the auth check inside the upload route's try-catch. Neither is a showstopper but both are worth addressing before the feature gets heavy parallel use.

apps/sim/tools/vanta/utils.ts (token exchange without caching), apps/sim/app/api/tools/vanta/upload/route.ts (auth check placement)

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Block as VantaBlock
    participant GenHandler as GenericHandler
    participant Tool as VantaTool
    participant QueryRoute as /api/tools/vanta/query
    participant UploadRoute as /api/tools/vanta/upload
    participant DownloadRoute as /api/tools/vanta/download
    participant VantaOAuth as Vanta OAuth
    participant VantaAPI as Vanta REST API

    Block->>GenHandler: resolve inputs + config.params()
    GenHandler->>GenHandler: "finalInputs = inputs + transformedParams"
    GenHandler->>Tool: executeTool(toolId, finalInputs)

    alt query / read operations
        Tool->>QueryRoute: POST with operation + credentials
        QueryRoute->>QueryRoute: checkInternalAuth
        QueryRoute->>VantaOAuth: POST /oauth/token
        VantaOAuth-->>QueryRoute: access_token
        QueryRoute->>VantaAPI: GET /v1/resource
        VantaAPI-->>QueryRoute: JSON response
        QueryRoute-->>Tool: normalized output
    else file upload
        Tool->>UploadRoute: POST with documentId + file
        UploadRoute->>UploadRoute: checkInternalAuth + assertToolFileAccess
        UploadRoute->>VantaOAuth: POST /oauth/token (upload scope)
        VantaOAuth-->>UploadRoute: access_token
        UploadRoute->>VantaAPI: POST multipart upload
        VantaAPI-->>UploadRoute: upload metadata
        UploadRoute-->>Tool: upload output
    else file download
        Tool->>DownloadRoute: POST with documentId + uploadedFileId
        DownloadRoute->>DownloadRoute: checkInternalAuth
        DownloadRoute->>VantaOAuth: POST /oauth/token (read scope)
        VantaOAuth-->>DownloadRoute: access_token
        DownloadRoute->>VantaAPI: GET media endpoint
        VantaAPI-->>DownloadRoute: binary stream
        DownloadRoute->>DownloadRoute: readBodyWithLimit 100MB
        DownloadRoute-->>Tool: base64 file output
    end

    Tool-->>GenHandler: ToolResponse
    GenHandler-->>Block: output

_{Reviews (3): Last reviewed commit: "fix(integrations): bound vanta base64 fi..." | Re-trigger Greptile}

@greptile

@cursor review

@greptile

@cursor review

@greptile review

@greptile

@cursor review

@greptile

@cursor review