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 lifecycle/deployment auth and permission checks across multiple API routes, so mistakes could block legitimate access or inadvertently widen access. Adds non-fatal error handling for post-deploy side effects, which may hide operational issues if not monitored.

Overview
Unifies workflow API authorization by migrating multiple lifecycle/deployment endpoints (deploy, deployments list/version, deployed-state, status, workflow CRUD) from validateWorkflowPermissions/ad-hoc checks to validateWorkflowAccess with explicit action (read/write/admin) and requireDeployment options.

Hardens API-key behavior and auditing: workspace-scoped API keys now return 404 when targeting workflows in other workspaces, API key auth results now include userName/userEmail, and audit logging in deploy/undeploy/activate/revert/delete now uses shared getAuditActorMetadata so API-key actors are recorded consistently.

Improves deploy/activation/revert robustness by treating MCP sync, webhook cleanup, and MCP tool cleanup failures as non-fatal (log-and-continue) after the primary operation succeeds; adds restoreWorkflowDraftState to revert a deployment snapshot back into draft (including variables) via a single transaction.

Adds/updates targeted Vitest coverage for the new middleware and the updated auth/audit paths, and clarifies docs that lifecycle/deployment endpoints can be used programmatically with session auth or API keys where supported.

^{Written by Cursor Bugbot for commit 7fdff82. This will update automatically on new commits. 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

[cursor]

Non-null assertions on potentially undefined actorUserId variable

Low Severity

actorUserId is assigned via auth?.userId (making it string | undefined) then used with non-null assertions (actorUserId!) at multiple call sites. While the earlier guard if (!auth?.userId) return ensures it's defined at runtime, TypeScript can't narrow across the two separate if (isActive) blocks. Extracting the validated actorUserId once after the guard or using a definite assignment would eliminate all the ! assertions and make the code resilient to future refactoring of the guard.

Additional Locations (2)

• apps/sim/app/api/workflows/[id]/deployments/[version]/route.ts#L196-L197
• apps/sim/app/api/workflows/[id]/deployments/[version]/route.ts#L327-L328

 

[cursor]

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

There are 2 total unresolved issues (including 1 from previous review).

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

[cursor]

Removed graceful null fallback for deployed state loading

Medium Severity

The previous code wrapped loadDeployedWorkflowState in a try-catch that returned deployedState: null inside a 200 response on failure. The new code removed that inner try-catch, so any throw from loadDeployedWorkflowState (e.g., no active deployment, race condition during undeploy) now propagates to the outer catch and returns a 500 error. Internal callers authenticated via Bearer token bypass the validateWorkflowAccess check entirely and go straight to loadDeployedWorkflowState, so they lose the graceful null-state fallback and will now receive 500 errors in cases that previously succeeded.