Security Policy

This Policy explains how to report a vulnerability safely, what is in scope, and the security boundary you control when Worktable runs on your machine or infrastructure.

Last updated
On this page
  1. 01Reporting a security issue
  2. 02Scope
  3. 03Good-faith research and safe harbor
  4. 04The local security model
  5. 05Your responsibilities
  6. 06Contact and updates

Reporting a security issue

Please report vulnerabilities privately. Use GitHub’s private vulnerability reporting or email security@worktable.dev. Do not open a public issue for an undisclosed vulnerability.

Include the affected Worktable version, platform, URL or component, a clear description and potential impact, and safe reproduction steps where possible. Do not send passwords, access tokens, private keys, or another person’s data.

We aim to acknowledge useful reports within a few business days, investigate them, keep you informed when we have material progress, and coordinate disclosure after a fix is available.

Scope

This Policy covers the Worktable local server and web app, CLI, MCP endpoint, Desktop application, installer, official release artifacts, worktable.dev, and docs.worktable.dev.

Report issues in Worktable Cloud or Reva Labs-operated Cloud infrastructure under the Worktable Cloud Security Policy. Do not test GitHub, Vercel, an agent provider, or other third-party infrastructure under this Policy.

Good-faith research and safe harbor

If you make a genuine effort to follow this Policy, avoid harm, respect privacy, and report the issue promptly, we will treat your research as authorized and will not pursue legal action for accidental, good-faith violations of this Policy.

  • Test only systems, accounts, and data you own or have explicit permission to test.
  • Stop and report immediately if you encounter another person’s data or production secrets.
  • Access only the minimum information needed to demonstrate the issue.
  • Do not use denial of service, destructive testing, social engineering, phishing, physical attacks, or high-volume automated scanning.
  • Give us a reasonable opportunity to investigate and fix the issue before public disclosure.

This safe harbor does not authorize unlawful activity. Worktable does not currently operate a bug bounty or promise financial rewards.

The local security model

By default, Worktable binds to 127.0.0.1 and behaves like a local application. The web app and local API are owner-open on that machine. The MCP endpoint may use a local bearer token.

When Worktable is made reachable from another device, it refuses to enter the supported reachable posture without an owner password. The web app and API then require a signed owner session, and MCP requires scoped bearer tokens.

Worktable serves plain HTTP locally. Put it behind a trusted HTTPS tunnel or reverse proxy before exposing it beyond your machine. An open loopback API on the machine running Worktable is part of the documented local design, not by itself a vulnerability.

Your responsibilities

Local and self-hosted operators are responsible for:

  • the security and updates of the host and network;
  • owner passwords, agent tokens, tunnels, proxies, and TLS;
  • filesystem permissions, exports, repositories, and backup access;
  • reviewing the permissions granted to connected agents; and
  • installing supported Worktable security updates.

See the security model and remote-access guide for configuration details.

Contact and updates

We may update this Policy as Worktable or its distribution path changes. Material changes to the reporting process or safe-harbor terms apply prospectively.

Security reports: security@worktable.dev
Other legal questions: legal@worktable.dev

Reva Labs
an Ontario-registered business