WorldModel
SECURITY

Secure defaults, reviewable evidence.

This page describes safeguards implemented in the current product—not certifications or controls that are merely planned.

Last updated July 13, 2026 · Pre-commercial pilot

Access and tenant isolation

  • Protected workspace data requires an application-managed signed-in session; public marketing and policy pages expose no tenant data.
  • Every workspace mutation performs a server-side membership and role check.
  • Cross-tenant operations require an explicit server-side operator email allowlist. The operator console provides no customer impersonation or secret access.
  • Project, run, report, integration, support, and audit queries are scoped to the current workspace.
  • Viewers cannot create projects, run simulations, change settings, or invite members.

Team invitations

  • Invitation links use high-entropy random material; only a SHA-256 digest is stored.
  • Links are bound to the invited email, expire after seven days, and can be accepted only once.
  • Pending invitations reserve plan seats and can be revoked immediately by an authorized administrator.
  • Owner and administrator boundaries are enforced server-side for invitations, role changes, and removals, with durable rate limiting and audit events.

Automation credentials

  • Developer API keys are generated from high-entropy random material and only the SHA-256 digest is stored.
  • The full credential is displayed once; it cannot be recovered later.
  • Keys have explicit project-read, run-read, and run-write scopes, optional expiry, immediate revocation, and a durable per-minute request limit.
  • API requests remain tenant-scoped and create audit events for simulation changes.

Provider integrations

  • GitHub connections use a hosted Composio OAuth link plus one-time, expiring tenant-bound state. The callback accepts only the expected GitHub auth configuration and WorldModel user identity.
  • Repository operations use the scoped Composio connected account. WorldModel does not ask for or store long-lived GitHub user tokens.
  • Draft publication requires an approved repair and a second explicit action; it writes only the bounded tenant-owned evidence packet and never merges the pull request.
  • Stripe collects payment details on Stripe-hosted Checkout. WorldModel does not receive card numbers.
  • Billing management uses short-lived Stripe-hosted portal sessions created only for an authenticated owner or administrator linked to the workspace customer record.
  • Subscription changes require a fresh matching Stripe raw-body webhook signature and event IDs are processed idempotently.

Simulation and change safety

  • WorldModel validates a bounded execution manifest before approval. The configured GitHub Actions runner remains responsible for enforcing its network policy, isolation, and teardown.
  • Failure scenarios preserve fingerprints and seeds for identical replay.
  • Repairs remain candidates until an owner or administrator records a review decision; pull-request handoff is blocked until approval.
  • Material actions create append-only tenant audit events.

Current limitations

WorldModel has not completed an independent penetration test, SOC 2 audit, formal business-continuity exercise, or published vulnerability-response SLA. The pilot should not be used to store secrets or regulated data. External CI evidence must not be enabled until the public HTTPS callback, runner token secret, campaign orchestrator, and GitHub Actions adapter are configured and reviewed. Report security concerns through the authenticated support workflow.