PR Summary

Medium Risk
Touching auth/authorization paths across multiple workflow lifecycle and deployment endpoints can change who is allowed to read/mutate workflows (session vs API key vs internal calls) and affects audit attribution.

Overview
Centralizes workflow route authorization by expanding validateWorkflowAccess to accept an options object (deployment requirement, read/write/admin action, and optional internal-secret bypass) and adding stricter workflow validation (workspace presence + workspace-scoped API key checks).

Updates workflow lifecycle and deployment-related routes (deploy, deployed-state, status, deployments list, deployment version activation/revert, and workflow update/delete) to use the shared access validator, resolve actor identity from hybrid auth for audit/public-API checks, and require a user-backed identity for mutating operations.

Adds getAuditActorMetadata helper and broadens/adjusts Vitest coverage to assert API-key flows, correct permission levels (e.g., write for metadata-only PATCH), and improved async execute-route failure diagnostics.

^{Written by Cursor Bugbot for commit ce2ed79. This will update automatically on new commits. Configure here.}

Someone is attempting to deploy a commit to the Sim Team on Vercel.

A member of the Team first needs to authorize it.

Greptile Summary

This PR hardens the workflow API auth layer by introducing a shared validateWorkflowAccess middleware and migrating seven route surfaces ([id], deploy, deployed, status, deployments, deployments/[version], deployments/[version]/revert) onto it, replacing a patchwork of session-only and ad-hoc auth checks with a consistent session / API-key / internal-secret path.

Key observations:

• The overall direction is correct and the standardisation is a genuine improvement over the previous divergent per-route auth.
• Double authorization in route.ts: Both the DELETE and PUT handlers call validateWorkflowAccess (which internally runs authorizeWorkflowByWorkspacePermission) and then immediately call authorizeWorkflowByWorkspacePermission a second time with the same arguments. The redundant second call wastes a DB round-trip on every request and introduces a small race-condition window where the two checks could return different results.
• Double session validation in deploy/route.ts: validateLifecycleAdminAccess calls validateWorkflowAccess for all callers (which already completes auth + permission checks for session users), and then, for session callers, discards the result and re-runs validateWorkflowPermissions in full. The first check's result is silently thrown away for this auth type.
• Dead allowInternalSecret: false option in deployed/route.ts: The allowInternalSecret field is only evaluated inside the requireDeployment: true code path in middleware. Specifying it with requireDeployment: false has no effect and misleads readers.
• The allowInternalSecret default in middleware.ts is coupled to requireDeployment unnecessarily, which reinforces the same misunderstanding.
• Test coverage is good — every changed route has a corresponding test file, and the tests verify the new middleware is called with the expected options.

Confidence Score: 3/5

• Auth hardening direction is correct but two routes contain redundant/double authorization logic that should be resolved before merging.
• The shared middleware and its adoption across routes is well-structured, and the test suite covers the new paths. However, the double authorizeWorkflowByWorkspacePermission in the [id] route and the double session-validation in the deploy route are real logic issues that add unnecessary DB load and create subtle race-condition windows in security-critical code paths.
• apps/sim/app/api/workflows/[id]/route.ts (DELETE/PUT double authorization) and apps/sim/app/api/workflows/[id]/deploy/route.ts (double session validation in validateLifecycleAdminAccess).

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Incoming Request] --> B{Auth Type?}

    B -->|Bearer JWT| C[verifyInternalToken\ndeployed/route only]
    C -->|valid| D[Skip validateWorkflowAccess\nload deployed state directly]
    C -->|invalid| E[validateWorkflowAccess]

    B -->|Session / API Key / Internal Secret| E

    E --> F[getWorkflowById]
    F -->|not found| G[404 Workflow not found]
    F -->|found, no workspaceId| H[403 Personal workflow deprecated]

    F -->|requireDeployment: false| I[checkHybridAuth]
    I -->|fail / no userId| J[401 Unauthorized]
    I -->|success + userId| K[authorizeWorkflowByWorkspacePermission\naction: read / write / admin]
    K -->|denied| L[403 / 404 Access denied]
    K -->|allowed| M[Return workflow + auth]

    F -->|requireDeployment: true| N{isDeployed?}
    N -->|false| O[403 Workflow not deployed]
    N -->|true| P{Internal Secret header?}
    P -->|valid + allowInternalSecret| Q[Return workflow — no userId]
    P -->|missing / invalid| R[Check X-Api-Key header]
    R -->|missing| S[401 API key required]
    R -->|present| T[authenticateApiKeyFromHeader\nworkspace or personal]
    T -->|fail| U[401 Invalid API key]
    T -->|success| V[updateApiKeyLastUsed\nReturn workflow]

    M --> W[Route handler\nDELETE / PUT / POST / PATCH / GET]
    V --> W
    Q --> W

_{Last reviewed commit: 73c1328}

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 15, 2026 11:07am

@PlaneInABottle this PR might have to wait till our v0.6 release. Lot of auth changes there that might overwrite this potentially

@PlaneInABottle can you rebase against staging