Documentation Portal

Security stays explicit across auth, policy, filtering, and audit.

The current secure platform slice already separates human auth, agent auth, and runtime auth while keeping workspace identity auth-derived and every execution outcome audit-visible.

Documentation map

The docs portal stays in the same application as the product shell so setup, deployment, connector, and developer guidance can evolve with the codebase.

In-repo docs7 foundation routes5 developer routesCurrent: Security

Foundation docs

  • OverviewRoute

    Start with the current architecture, product surfaces, and the stable documentation sections.

  • Getting StartedRoute

    Install the workspace, configure local env files, and run the first verification flow.

  • DeploymentRoute

    Use the managed bridge deployment order, health checks, migrations, and workspace bootstrap flow.

  • ConnectorsRoute

    Understand the Figma reference connector, Satellite runtime, and explicit session routing model.

  • SecurityOpen

    Review auth lanes, workspace isolation, policy controls, rate limiting, and audit semantics.

  • API ReferenceRoute

    Browse the stable HTTP route groups, shared envelopes, auth lanes, and machine-readable errors.

  • TroubleshootingRoute

    Use the current operational failure patterns for readiness, auth, session liveness, policy, and MCP issues.

Developer docs

  • DevelopersRoute

    Developer-facing entry point for HTTP, MCP, connector, and shared-contract guidance.

  • Developer QuickstartRoute

    Bring up the bridge, connect one runtime, and make the first explicit authenticated calls.

  • HTTP GuideRoute

    Use the bridge HTTP transport with the correct auth lane, shared envelopes, and explicit targetSessionId routing.

  • MCP GuideRoute

    Use the Streamable HTTP MCP endpoint, LIST_CAPABILITIES, and the same connector-neutral tool catalog.

  • Connector ModelRoute

    Understand connector definitions, capability metadata, data scopes, and high-risk policy presets.

Auth lanes

The platform now uses different auth paths for different actors without collapsing them into one mode label.

Human: Supabase bearer tokenAgent: API keyRuntime: runtime_token or supabase_jwt

Human account session: GET /api/v1/account/session resolves bridge-owned workspace memberships from a Supabase user token.

Automation and agent execution: authenticated routes such as POST /api/v1/tools/execute use API keys.

Runtime handshake: connector runtimes authenticate through the runtime-auth boundary while workspace ownership is validated through bridge-side membership checks.

Workspace isolation and policy

Secure execution paths derive workspace identity from auth context before routing, policy evaluation, and audit writes.

  • Workspace-scoped routes require one explicit workspace id and validate that the caller still belongs to that workspace.
  • Capability and data-scope policies are enforced before or after execution depending on the control point, with deny and redaction outcomes remaining machine-readable.
  • High-risk Satellite workflows stay fail-closed through both bridge-side policy presets and runtime-side allowlists.

Audit and rate limiting

Trust-control work is only considered complete when success and failure paths stay visible in the audit layer.

Audit covers auth outcomes, authorization allow or deny decisions, filtering actions, validation failures, routing failures, runtime failures, and successful command execution.

The secure backend also applies Redis-backed per-workspace rate limiting so one noisy workspace does not consume another workspace's quota.

The current product shell already exposes the baseline audit feed at /app/audit and event detail at /app/audit/[eventId].