Share a workspace with Squad

01Two senses of "team"

The Team screen in the sidebar carries two distinct capabilities. It helps to keep them straight, because only one of them sends anything off your machine.

Local multi-analyst attribution. Several analysts working in one shared workspace each see the others' work, tagged by who did it — Crusader describes it as "Shared workspace — everyone sees each other's work, tagged by who did it." This is purely local. It works without a license and nothing is uploaded.

Hosted workspace sync. This is the Squad feature: the desktop uploads a redacted manifest to a Team API so a distributed squad can pool findings, replayable tabs, and identity metadata. This is gated by TeamWorkspace and requires the Squad tier or higher.

02Publish a hosted workspace

Open Team from the sidebar (under SYSTEM), or go to Settings → Team. Point the desktop at a Team API and identify which slot in it you're writing to:

Then enable the share toggles you want (they all start OFF — see section 05) and click Sync now. On an unlicensed install the button reads Unlock Squad instead. A sync uploads the redacted manifest with a single call:

# the desktop posts the redacted manifest to your Team API
POST /api/team/sync

The desktop never connects to a public SQL database directly — all access goes through the Team API, which is also the source of truth for roles. Every successful sync emits a desktop.sync.created audit event carrying attribution for who pushed it.

03What a shared snapshot includes

A sync uploads a manifest — not your raw project database. Depending on which toggles are on, the snapshot can include:

• Findings, with provenance — who discovered each one and who confirmed it.
• Repeater tabs, as redacted raw request/response pairs.
• Intruder jobs, described by payload-set count and hash — never the raw payloads.
• Identities, as metadata plus an auth-material fingerprint — never the secret itself.
• Scan stats and audit events.

The distinction to internalize: Repeater tabs travel as redacted traffic, but Intruder payload sets and identity secrets are reduced to a hash or fingerprint before they ever reach the manifest. The team sees that an attack ran and which identity was used; it does not receive the wordlist or the credential.

04How redaction works

Redaction is always on for uploads. There is no switch to send raw traffic to the Team API. Before the manifest is built, the desktop scrubs:

• Secret headers, fully redacted — authorization, cookie, set-cookie, x-api-key, CSRF tokens, and similar.
• Sensitive query parameters.
• Body tokens — bearer/JWT, AWS, Google, and Stripe keys, plus PEM blocks, scrubbed out of request and response bodies.

On top of that, sharing defaults are OFF — every toggle is opt-in, so a fresh Squad workspace publishes nothing until you choose to. Before you sync, open the Sharing preview: it shows exactly what each enabled toggle will publish, so you can confirm what leaves the machine rather than trust it.

05The four sharing toggles

Sharing is governed by four independent switches in Settings → Team. All four default to off.

06Identity-secret consent

Identity sharing gets its own treatment because identities carry live auth material. By default, syncing an identity shares only its metadata and an auth-material fingerprint — enough for a teammate to know the identity exists and what it's for, but not enough to use it.

The Identity secret sharing toggle changes that, and it is deliberately hard to turn on:

• It is off by default.
• It is double-gated — it requires both the Squad tier and the TeamSecretControls entitlement.
• Even when enabled, only a vault reference is shared, not the credential. Raw cookies and tokens are NEVER uploaded.

In other words, "identity secret sharing" lets a teammate's desktop resolve a pointer to a shared secret store — it does not put your session cookie or bearer token into the manifest. The secret stays on the desktop.

07Roles and the audit trail

Squad adds role-based access control (TeamRbac). The two roles are Project Admin and Runner. The Hosted Team API is the RBAC source — roles are enforced server-side, and, as noted above, the desktop never connects to a public SQL store; all access flows through the Team API.

Squad also adds an audit trail (TeamAuditTrail). Every sync emits a desktop.sync.created event with attribution, so there's a record of who published what and when.

08Self-host the team server

If you'd rather keep the pooled data on infrastructure you control, run the self-hosted team server (Server/Crusader.TeamServer). It's a single-tenant, single-file binary that speaks the same /api/team/sync manifest, so no desktop changes are needed — you just point the Hosted Team API base URL at it. It ingests to a local SQLite database, de-dupes by stable IDs (last write wins), and serves the pool back to the squad.

Be clear about what it deliberately is not: the self-hosted server is token-gated and does not do SSO, SAML, SCIM, billing, or multi-org. It's a focused single-tenant pool, not an identity platform.

Publish, add a token, run

Build a self-contained single-file binary, mint a token for each teammate, then start it:

# 1. publish a self-contained single-file binary
dotnet publish -c Release -r linux-x64 --self-contained -p:PublishSingleFile=true

# 2. mint a token (the secret is shown ONCE — copy it now)
./crusader-team-server add-token "Alice"

# 3. run it (defaults: http://0.0.0.0:5079, DB ./crusader-team.db)
./crusader-team-server

Token management runs through the same binary: add-token "<name>" (shown once), list-tokens, and revoke-token "<name>".

Environment variables

Auth and endpoints

Every endpoint except /healthz requires a Bearer token. The desktop pushes to POST /api/team/sync; teammates' desktops read the pool back from the per-resource GET endpoints, scoped by org and project:

# write
POST /api/team/sync

# read (Bearer token required; scope by org & project)
GET  /api/team/findings?org=<org>&project=<project>
GET  /api/team/repeater?org=<org>&project=<project>
GET  /api/team/intruder?org=<org>&project=<project>
GET  /api/team/identities?org=<org>&project=<project>
GET  /api/team/scan-runs?org=<org>&project=<project>
GET  /api/team/audit?org=<org>&project=<project>
GET  /api/team/status?org=<org>&project=<project>

# health (no auth)
GET  /healthz

HTTPS is required

The desktop requires HTTPS for the API base by default (http://127.0.0.1 is allowed for purely local use). For any LAN or remote deployment, front the server with TLS — Caddy or nginx as a reverse proxy is the usual answer.

Want a guide that isn't here yet? Email hello@crusaderproxy.com.