fix(workflows): harden workflow API auth routes

[PlaneInABottle]

Summary

• Hardens workflow lifecycle and deployment auth after the rebase so session, API-key, and internal callers follow the same access path.
• Incorporates the latest landed fixes already on the branch: rebased auth-hardening updates, the env mock fix, the duplicate lookup fix, and the archived workspace access fix.
• Also includes the current follow-up scope in the worktree: API-key audit actor metadata on lifecycle routes, deployment activation reuse of the preloaded workflow, and an English docs clarification.

What changed

• Landed on the branch
  • Rebases and keeps the workflow API auth-hardening stack aligned with current staging
  • Preserves env mocks / workflow context in the affected workflow route tests to avoid rebase regressions
  • Fixes the duplicate lookup path introduced in the hardened workflow access flow
  • Blocks archived workspace access for workflow routes
• Current follow-up in the worktree
  • Carries API-key actor name / email into deploy, activate, and revert audit records
  • Reuses the already loaded workflow during deployment activation auth checks instead of performing another lookup
  • Clarifies the English execution API docs to note that lifecycle/deployment endpoints can also be used with session auth or API keys where supported

Validation

• Targeted workflow auth coverage has been expanded across middleware, deploy, deployment activation, deployment revert, status, and async execution paths
• Follow-up test updates cover API-key audit actor metadata and preloaded-workflow reuse in deployment activation
• Docs change is wording-only and does not change runtime behavior

[cursor]

PR Summary

Medium Risk
Touches workflow auth/authorization paths and deployment lifecycle endpoints (deploy/activate/revert), so mistakes could block legitimate access or weaken enforcement; changes are mitigated by added unit coverage and mostly defensive error handling.

Overview
Unifies workflow lifecycle/deployment endpoints behind validateWorkflowAccess (session, API key, and internal-secret flows) and applies consistent read/write/admin gating across deploy, deployments, deployment version, deployed state, status, and workflows/[id] routes.

Hardens behavior around API-key usage: workspace-scoped keys now return 404 for cross-workspace workflow IDs, API-key auth includes userName/userEmail (via authenticateApiKeyFromHeader join + getAuditActorMetadata) so audit records capture API-key actors, and several routes now validate/short-circuit malformed JSON before side effects.

Improves resilience of deployment operations by making MCP sync and cleanup steps non-fatal (logged and continued) and adds restoreWorkflowDraftState to revert deployments with transactional graph+variable restore. Expands Vitest coverage substantially for these flows and updates docs to clarify lifecycle/deployment endpoints can be called with session auth or API keys.

^{Written by Cursor Bugbot for commit 1b049e7. Configure here.}

[vercel]

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

A member of the Team first needs to authorize it.

[greptile-apps]

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

Filename	Overview
apps/sim/app/api/workflows/middleware.ts	New centralized validateWorkflowAccess function with good structure; the allowInternalSecret default coupling to requireDeployment is misleading and should be cleaned up.
apps/sim/app/api/workflows/[id]/route.ts	DELETE and PUT handlers perform a redundant second authorizeWorkflowByWorkspacePermission call after validateWorkflowAccess already authorized the user, creating unnecessary DB round-trips and a race-condition window.
apps/sim/app/api/workflows/[id]/deploy/route.ts	Session-authenticated callers are double-validated: validateWorkflowAccess completes auth and permission checks, then validateLifecycleAdminAccess discards the result and re-runs validateWorkflowPermissions for session users.
apps/sim/app/api/workflows/[id]/deployed/route.ts	Clean internal-caller bypass with JWT verification; the allowInternalSecret: false option passed to validateWorkflowAccess is dead code and should be removed.
apps/sim/app/api/workflows/[id]/status/route.ts	Clean migration to shared validateWorkflowAccess; no issues found.
apps/sim/app/api/workflows/[id]/deployments/route.ts	Straightforward use of shared middleware for deployment list read access; no issues found.
apps/sim/app/api/workflows/[id]/deployments/[version]/route.ts	Good use of per-action permission escalation (read vs admin for activation); validateDeploymentVersionLifecycleAccess wrapper is clean but slightly redundant given it only forwards to validateWorkflowAccess unchanged.
apps/sim/app/api/workflows/[id]/deployments/[version]/revert/route.ts	Clean admin-only guard via shared middleware; actor identity checked before mutation; no issues found.

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

Loading

Comments Outside Diff (1)

1. apps/sim/app/api/workflows/[id]/route.ts, line 170-192 (link)

   Redundant double authorization check

   validateWorkflowAccess at line 150 already calls checkHybridAuth followed by authorizeWorkflowByWorkspacePermission with the same action: 'admin'. If that first check passes, the userId is guaranteed to have workspace admin permission. Re-running authorizeWorkflowByWorkspacePermission here with the same userId and action creates:

   1. A redundant DB round-trip on every request.
   2. A window for a race condition — if the workspace membership changes between the two calls, the second check could return a different result, leading to inconsistent behaviour (e.g. the first check passes but the second returns authorization.allowed = false, causing a 403 even though the user was legitimately authorised).

   The workflow object is already available via validation.workflow and the access is already verified, so the second authorizeWorkflowByWorkspacePermission call (and the canDelete guard that depends on it) should be removed in favour of using validation.workflow directly:

   const workflowData = validation.workflow
   if (!workflowData) {
     return NextResponse.json({ error: 'Workflow not found' }, { status: 404 })
   }
   

   The same pattern applies to the PUT handler at lines 403–424.

_{Last reviewed commit: 73c1328}

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Mar 19, 2026 0:32am

[icecrasher321]

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

[icecrasher321]

@PlaneInABottle can you rebase against staging

[icecrasher321]

bugbot run

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Auto-generated Next.js file committed in auth PR

Low Severity

The next-env.d.ts file is auto-generated by Next.js (as noted by its own comment: "This file should not be edited"). It appears as an entirely new file in a PR focused on auth hardening, suggesting it was generated during local development and accidentally staged. While harmless, it adds unrelated noise to the diff and could mask meaningful changes during review.