cleanup: accessibility, emcn design tokens, react best practices across workspace UI

- Add sr-only ModalDescription to dialogs/modals for accessibility
- Replace hardcoded colors and z-indices with design token CSS variables
- Apply emcn design review fixes across tables, knowledge, logs, settings, workflows

Author: waleedlatif1

.deepsec/.gitignore

@@ -0,0 +1,9 @@
+node_modules/
+.env*.local
+
+# Scan output — regenerated by `deepsec scan` / `process`. INFO.md
+# and SETUP.md (manually edited) stay tracked.
+data/*/files/
+data/*/runs/
+data/*/reports/
+data/*/project.json

.deepsec/AGENTS.md

@@ -0,0 +1,23 @@
+# Agent setup
+
+This is a deepsec scanning workspace. Each registered project has its
+own setup prompt at `data/<id>/SETUP.md` — open the relevant one when
+asked to set a project up.
+
+## Common tasks
+
+- **Set up a project for scanning**: read `data/<id>/SETUP.md` and
+  follow it (read `node_modules/deepsec/SKILL.md`, then fill
+  `data/<id>/INFO.md` from the target codebase).
+- **Add a new project**: run `deepsec init-project <root>` — it
+  scaffolds `data/<id>/` and prints/writes the setup prompt for the
+  new project.
+- **Write a custom matcher** (only after a real true-positive shows you
+  a pattern worth keeping): read
+  `node_modules/deepsec/dist/docs/writing-matchers.md`.
+
+## Reference
+
+The deepsec skill is at `node_modules/deepsec/SKILL.md` (after
+`pnpm install`). The full docs ship at
+`node_modules/deepsec/dist/docs/`.

.deepsec/README.md

@@ -0,0 +1,74 @@
+# deepsec
+
+This directory holds the [deepsec](https://www.npmjs.com/package/deepsec)
+config for the parent repo. Checked into git so teammates inherit
+project context (auth shape, threat model, custom matchers); generated
+scan output is gitignored.
+
+Currently configured project: `sim` (target: `..`).
+
+## Setup
+
+1. `pnpm install` — installs deepsec.
+2. Add an AI Gateway / Anthropic / OpenAI token to `.env.local`. If
+   you already have `claude` or `codex` CLI logged in on this
+   machine, you can skip the token for non-sandbox runs (`process` /
+   `revalidate` / `triage`); deepsec auto-detects and reuses the
+   subscription. See
+   `node_modules/deepsec/dist/docs/vercel-setup.md` after install.
+3. Open the parent repo in your coding agent (Claude Code, Cursor, …)
+   and have it follow `data/sim/SETUP.md` to fill in
+   `data/sim/INFO.md`.
+
+## Daily commands
+
+```bash
+pnpm deepsec scan
+pnpm deepsec process     --concurrency 5
+pnpm deepsec revalidate  --concurrency 5                  # cuts FP rate
+pnpm deepsec export      --format md-dir --out ./findings
+```
+
+`--project-id` is auto-resolved while there's only one project in
+`deepsec.config.ts`. Once you've added a second project, pass
+`--project-id sim` (or whichever id you want) explicitly.
+
+`scan` is free (regex only). `process` is the AI stage (≈$0.30/file
+on Opus by default). Run state goes to `data/sim/`.
+
+## Adding another project
+
+To scan another codebase from this same `.deepsec/`:
+
+```bash
+pnpm deepsec init-project ../some-other-package   # path relative to .deepsec/
+```
+
+Appends an entry to `deepsec.config.ts` and writes
+`data/<id>/{INFO.md,SETUP.md,project.json}`. Open the new SETUP.md
+in your agent to fill in INFO.md.
+
+## Layout
+
+```
+deepsec.config.ts        Project list (one entry per scanned repo)
+data/sim/
+  INFO.md                Repo context — checked into git, hand-curated
+  SETUP.md               Agent setup prompt — checked in, deletable
+  project.json           Generated (gitignored)
+  files/                 One JSON per scanned source file (gitignored)
+  runs/                  Run metadata (gitignored)
+  reports/               Generated markdown reports (gitignored)
+AGENTS.md                Pointer for coding agents
+.env.local               Tokens (gitignored)
+```
+
+## Docs
+
+After `pnpm install`:
+
+- Skill: `node_modules/deepsec/SKILL.md`
+- Full docs: `node_modules/deepsec/dist/docs/{getting-started,configuration,models,writing-matchers,plugins,architecture,data-layout,vercel-setup,faq}.md`
+
+Or browse on
+[GitHub](https://github.com/vercel/deepsec/tree/main/docs).

.deepsec/data/sim/INFO.md

@@ -0,0 +1,37 @@
+# sim
+
+## What this codebase does
+
+Sim is a Next.js 15 (App Router) TypeScript monorepo — the `apps/sim` package is the main web app. It lets teams build, deploy, and manage AI agents visually. Users connect 1,000+ external integrations (OAuth, API keys) and run AI workflows against real services. The backend exposes ~735 API routes, a server-side workflow executor, and a public REST API (`/api/v1/**`) protected by user-managed API keys. The database is PostgreSQL via PlanetScale (Drizzle ORM). Auth is `better-auth`.
+
+## Auth shape
+
+- `getSession()` — cookie-session lookup (server side). Primary guard for web UI routes.
+- `checkHybridAuth(request)` — resolves one of: session cookie, `X-API-Key` header, or internal JWT (`Authorization: Bearer <token>`). Used on most internal API routes.
+- `checkSessionOrInternalAuth(request)` — session + internal JWT only; explicitly rejects API keys. Used for routes that must not be externally reachable.
+- `checkInternalAuth(request)` — internal JWT only (executor-to-server). Rejects both session and API key.
+- `verifyCronAuth(request)` — `Authorization: Bearer $CRON_SECRET` for cron endpoints.
+- `authorizeCredentialUse(request, { credentialId, workflowId? })` — workspace credential + `credentialMember` membership check.
+- `getUserEntityPermissions(userId, 'workspace', workspaceId)` — returns permission level or `null` (no access). Used for workspace RBAC.
+- `withRouteHandler(handler)` — mandatory wrapper around every export; provides request-ID context and error logging. Routes missing this wrapper skip error observability.
+- `authenticateV1Request(request)` from `/api/v1/auth` — public API key gate used by the v1 middleware (`checkRateLimit` + rate limiting).
+
+## Threat model
+
+An attacker would most want: (1) to run arbitrary workflows under another user's identity or with another user's OAuth credentials, since workflows can exfiltrate data from connected services; (2) to inject tool/block definitions or custom tool code that executes server-side; (3) to escalate within an organization (workspace RBAC bypass); (4) to abuse the public `/api/v1` endpoints at scale without triggering rate limits.
+
+## Project-specific patterns to flag
+
+- **Auth check ordering in routes**: Several routes call `parseRequest` (body parsing) *before* auth — if the auth check is later, untrusted input is parsed before the caller is authenticated.
+- **Internal JWT fallback**: `checkHybridAuth` prefers internal JWT before session. A valid internal JWT bypasses session auth entirely — flag any route that accepts internal JWT but shouldn't (e.g., user-facing mutation endpoints).
+- **Custom tool execution**: `/api/tools/custom` and related endpoints accept user-defined code/config; ensure these go through `checkSessionOrInternalAuth` and not API keys.
+- **`workflowId` used as implicit auth**: Several routes resolve `workspaceId` from a caller-supplied `workflowId` without confirming the caller owns the workflow — look for `db.select(...).from(workflow).where(eq(workflow.id, workflowId))` without a subsequent `userId` check.
+- **Cron routes**: `verifyCronAuth` returns `null` if `CRON_SECRET` is unset and logs a warning but still returns 401 — confirm every cron route calls this and checks the return.
+
+## Known false-positives
+
+- `apps/sim/app/api/auth/[...all]/route.ts` — better-auth handler; intentionally public, handles its own auth.
+- `apps/sim/app/api/health/route.ts` — public health-check endpoint, no auth expected.
+- `apps/sim/app/api/webhooks/[id]/route.ts` — inbound webhook receiver; intentionally unauthenticated (validated by HMAC/provider signature inside the handler).
+- `apps/sim/app/api/v1/**` — external public API; auth goes through `authenticateV1Request` + v1 middleware, not `getSession`.
+- `apps/sim/lib/auth/auth.ts` — Stripe webhook handler embedded inside better-auth; raw `request.json()` is expected here.

.deepsec/data/sim/SETUP.md

@@ -0,0 +1,55 @@
+# Agent setup for `sim`
+
+This is a deepsec scanning workspace. Project `sim` was just registered
+(target: `..`). Setup is incomplete — `data/sim/INFO.md`
+still has placeholder sections.
+
+## What to do
+
+1. **Read the deepsec skill.** After `pnpm install`, the file is at
+   `node_modules/deepsec/SKILL.md`. It maps every doc topic to a file
+   under `node_modules/deepsec/dist/docs/`. Read `getting-started.md`,
+   `configuration.md`, and `writing-matchers.md` (skim the rest).
+
+2. **Fill in `data/sim/INFO.md`.** It's auto-injected into the AI
+   prompt for every batch — keep it short and selective.
+
+   **Length budget: 50–100 lines total.** Verbose context dilutes
+   signal in the scanner's prompt window. The goal is "what would a
+   reviewer miss if they didn't read this?", not exhaustive enumeration.
+
+   **Per-section rubric**:
+   - Pick 3–5 representative items per section. **Don't list every
+     file, helper, or callsite** — pick the patterns.
+   - Name primitives by their public name (e.g. `withAuthentication`,
+     `auth.can()`, `isTeamAdmin`). **No line numbers.** Don't enumerate
+     more than 5 paths in any list.
+   - Skip generic CWE categories — built-in matchers already cover
+     "SSRF", "SQL injection", "XSS". Cover what's *project-specific*:
+     internal auth helpers, custom middleware names, fork-specific
+     stubs, intended-public endpoints.
+   - One short paragraph or 3–5 short bullets per section. Not both.
+
+   Source material (read in this order, stop when you have enough):
+   - `../README.md`
+   - any `AGENTS.md` / `CLAUDE.md` in `..`
+   - `../package.json` (or `go.mod`, `pyproject.toml`, etc.)
+   - 5–10 representative code files (entry points, auth helpers) — not
+     a full code tour.
+
+3. **(Optional) Add custom matchers** for repo-specific patterns the
+   built-in matchers won't catch. Read
+   `node_modules/deepsec/dist/docs/writing-matchers.md` first; the
+   workflow there starts from a confirmed finding and grows the matcher
+   from it. Don't add matchers speculatively — wait for a real TP.
+
+## When you're done
+
+The user will run:
+
+```bash
+pnpm deepsec scan    --project-id sim
+pnpm deepsec process --project-id sim
+```
+
+You can delete this file once setup is complete.

.deepsec/data/sim/tech.json

@@ -0,0 +1,6 @@
+{
+  "tags": ["bun", "github-actions", "node"],
+  "sentinels": ["bun.lock", "package.json"],
+  "detectedAt": "2026-05-10T18:53:22.646Z",
+  "rootPath": "/Users/waleed/SimRegistry/sim"
+}

.deepsec/deepsec.config.ts

@@ -0,0 +1,8 @@
+import { defineConfig } from 'deepsec/config'
+
+export default defineConfig({
+  projects: [
+    { id: 'sim', root: '..' },
+    // <deepsec:projects-insert-above>
+  ],
+})

.deepsec/findings/BUG/sim-cross-tenant-id-fb07f07b64.md

@@ -0,0 +1,21 @@
+# [BUG] configurePolling trusts caller-supplied credentialId without ownership check
+
+**File:** [`apps/sim/lib/webhooks/providers/gmail.ts`](https://github.com/simstudioai/sim/blob/fix/react-doc/blob/fix/apps/sim/lib/webhooks/providers/gmail.ts#L28-L87) (lines 28, 29, 30, 31, 32, 33, 34, 35, 36, 56, 58, 87)
+**Project:** sim
+**Severity:** BUG  •  **Confidence:** medium  •  **Slug:** `cross-tenant-id`
+
+## Owners
+
+**Suggested assignee:** `walif6@gmail.com` _(via last-committer)_
+
+## Finding
+
+configurePolling reads `credentialId` from `providerConfig` (L30) and uses `resolveOAuthAccountId` + a direct `account` table lookup (L44-47) to derive `effectiveUserId` from the credential owner — then stores that userId on the webhook record (L87). There is no check that the user creating/owning the webhook actually owns the credential. If the upstream webhook-creation API doesn't independently enforce that the caller owns `providerConfig.credentialId`, a workspace member (or attacker with workspace write access) could create a Gmail webhook that polls another user's Gmail using that user's stored credentials, with the workflow run attributed to (and billed/audited against) the credential owner. The polling job (`refreshAccessTokenIfNeeded` at L58-62) then mints access tokens against the credential owner's account. This file alone cannot determine if upstream validation exists, but configurePolling should defense-in-depth verify ownership rather than trust the user-controlled providerConfig.credentialId.
+
+## Recommendation
+
+In configurePolling, additionally verify that the credential identified by `credentialId` is owned by (or shared with) the webhook's owning workspace/user before deriving effectiveUserId from it. The webhook record already provides workspaceId via the caller chain — pass it in via PollingConfigContext and assert that the resolved credential row's workspaceId/userId is accessible to the webhook owner. Confirm the upstream webhook-creation route (`/api/webhooks` POST) explicitly validates credential ownership via `authorizeCredentialUse`.
+
+## Recent committers (`git log`)
+
+- Waleed <walif6@gmail.com> (2026-04-06)

.deepsec/findings/BUG/sim-js-sql-raw-97fd70a543.md

@@ -0,0 +1,23 @@
+# [BUG] sql.raw() interpolates Date.toISOString() into JSONB value — currently safe but brittle
+
+**File:** [`apps/sim/lib/workflows/executor/human-in-the-loop-manager.ts`](https://github.com/simstudioai/sim/blob/fix/react-doc/blob/fix/apps/sim/lib/workflows/executor/human-in-the-loop-manager.ts#L1336) (lines 1336)
+**Project:** sim
+**Severity:** BUG  •  **Confidence:** high  •  **Slug:** `js-sql-raw`
+
+## Owners
+
+**Suggested assignee:** `vikhyathvikku@gmail.com` _(via last-committer)_
+
+## Finding
+
+Line 1336 builds the `resumedAt` JSON value with `'"${sql.raw(now.toISOString())}"'::jsonb` inside a `drizzle-orm` `sql` tagged template. `sql.raw(...)` bypasses parameter binding and splices the string directly into the SQL fragment. Here `now` is locally constructed as `const now = new Date()` (line 1321) and `Date.prototype.toISOString()` is spec-guaranteed to return a fixed `YYYY-MM-DDTHH:mm:ss.sssZ` form with no SQL metacharacters, so this is not exploitable in its current form. However, the pattern is fragile: any future refactor that derives `now` from external input (a header, a body field, a record from another query) would turn this into a JSONB/SQL injection. The fix is purely defensive — the same value is trivially parameterizable.
+
+## Recommendation
+
+Replace `'"${sql.raw(now.toISOString())}"'::jsonb` with a parameterized form: build the JSON string in JS (`const resumedAtJson = JSON.stringify(now.toISOString())`) and interpolate it as a normal parameter — e.g., `ARRAY[${contextId}, 'resumedAt'], ${resumedAtJson}::jsonb`. This removes the only `sql.raw` in the file and makes the SQL future-proof against accidental injection if the time source ever becomes external.
+
+## Recent committers (`git log`)
+
+- Vikhyath Mondreti <vikhyathvikku@gmail.com> (2026-05-05)
+- Theodore Li <theo@sim.ai> (2026-05-05)
+- Waleed <walif6@gmail.com> (2026-05-02)

.deepsec/findings/BUG/sim-object-injection-13fc75fdd5.md

@@ -0,0 +1,28 @@
+# [BUG] User-controlled custom tool property names assigned without dangerous-key filtering
+
+**File:** [`apps/sim/tools/utils.ts`](https://github.com/simstudioai/sim/blob/fix/react-doc/blob/fix/apps/sim/tools/utils.ts#L200-L217) (lines 200, 217)
+**Project:** sim
+**Severity:** BUG  •  **Confidence:** low  •  **Slug:** `object-injection`
+
+## Owners
+
+**Suggested assignee:** `vikhyathvikku@gmail.com` _(via last-committer)_
+
+## Finding
+
+In `createParamSchema` (lines 193-222), the function iterates `Object.entries(customTool.schema.function.parameters.properties)` and assigns each `key` to a fresh result object via `params[key] = paramConfig`. The custom tool schema is validated by `customToolSchemaSchema` in `lib/api/contracts/tools/custom.ts`, which uses `z.record(z.string(), z.unknown())` for `properties` — this does NOT filter prototype-pollution keys (`__proto__`, `constructor`, `prototype`).
+
+If a user creates a custom tool with `properties.__proto__: {...}`, the bracket assignment `params['__proto__'] = paramConfig` triggers the prototype setter and rewires `params`'s prototype chain. The pollution is local to that object (no global Object.prototype impact), but it can cause confusing/incorrect property lookups when downstream code does `tool.params.someKey` and the key isn't an own property — JS will then walk the planted prototype.
+
+Similarly, `applyDynamicSchemaForWorkflow` in `params.ts` (line 642-648) uses `propertySchema.properties[field.name] = …` with `field.name` from workflow definitions. While more constrained, the pattern is the same.
+
+No concrete exploitation path was identified, but this is fragile and an obvious bug class. `safeAssign` already exists in `tools/safe-assign.ts` and should be used here.
+
+## Recommendation
+
+Reject or strip dangerous keys (`__proto__`, `constructor`, `prototype`) when constructing `params`. Either tighten `customToolSchemaSchema` to refuse such keys via `z.record(z.string().refine(k => !['__proto__','constructor','prototype'].includes(k)), z.unknown())`, or use `safeAssign` from `@/tools/safe-assign` when building the schema record. The same fix should apply anywhere `Object.create(null)` or `safeAssign` could replace direct bracket assignment over user-controlled keys.
+
+## Recent committers (`git log`)
+
+- Vikhyath Mondreti <vikhyathvikku@gmail.com> (2026-05-06)
+- Waleed <walif6@gmail.com> (2026-04-06)