Slack and Enterprise Compliance

This page is written for IT, security, and compliance reviewers evaluating workgraph for use with workplace Slack and local work context. workgraph is local-first software: captured events, connector credentials, settings, and memory files are stored on the user's device by default.

workgraph does not provide a trust center, third-party audit report, SOC 2 report, ISO 27001 certificate, or enterprise DPA. This page documents the implemented technical controls and the remaining boundaries so reviewers can decide whether workgraph is appropriate for their environment.

Architecture summary

• workgraph runs as a local CLI and optional local daemon on the user's device.
• Captured event data is stored in a local SQLite database at ~/.workgraph/workgraph.db.
• Slack connector credentials and selected connector options are stored locally at ~/.workgraph/slack.json.
• User settings are stored locally at ~/.workgraph/settings.json.
• Admin-managed settings, when deployed, are read from a fixed platform path named managed-settings.json and override locked local options.
• LLM features are optional. Core capture, storage, today, and resume workflows do not require an LLM.

Slack access model

workgraph uses Slack OAuth and requests read-oriented user scopes so it can capture messages visible to the approved Slack user and store local work context. It does not request Slack write scopes, and it does not post messages, add reactions, update Slack content, or perform Slack actions automatically.

Slack direct-message control

Direct-message and group-direct-message capture is off by default. Users must explicitly opt in with workgraph slack connect --include-dms. Slack OAuth scopes are additive, so removing DM access requires disconnecting workgraph from Slack and reconnecting without DM scopes.

On managed devices, administrators can lock Slack DM capture off with managed settings:

{
  "connectors": {
    "slack": {
      "include_dms": {
        "value": false,
        "locked": true
      }
    }
  }
}

When connectors.slack.include_dms is locked to false, workgraph refuses Slack DM opt-in before generating an OAuth URL and refuses capture startup if stored Slack settings would poll direct messages.

Managed settings

Managed settings are intended for company-managed devices where an administrator can write a local policy file. At runtime, workgraph reads managed settings from fixed platform-managed paths only; users cannot override the managed settings path with CLI flags or environment variables.

• macOS: /Library/Application Support/workgraph/managed-settings.json
• Windows: %ProgramData%\workgraph\managed-settings.json
• Linux and other Unix-like systems: /etc/workgraph/managed-settings.json

Managed settings can disable hosted LLM providers, restrict OpenAI-compatible model base URLs to approved local or company endpoints, and lock high-risk connector options such as Slack DM capture.

LLM and external AI use

workgraph does not require an LLM for local capture or storage. If a user configures an LLM provider, workgraph may send selected local context to that configured model endpoint for user-requested LLM commands. Organizations should decide which model endpoints are approved for workplace data.

Managed settings can disable hosted LLM providers or restrict model destinations. A common policy is to disable hosted providers and allow only a local OpenAI-compatible endpoint such as http://localhost:11434/v1.

Network destinations

workgraph contacts network services only for connectors and optional features the user enables. Depending on configuration, destinations may include:

• Slack Web API over TLS when Slack is connected.
• Cloudflare Pages for the Slack OAuth redirect helper at workgraph.pages.dev/slack/callback.
• Cloudflare Workers OAuth token relays for providers such as Google or Notion when those connectors are connected.
• Provider APIs for explicitly connected services such as Google, Microsoft, Notion, GitHub, Azure DevOps, and Jira.
• Optional LLM endpoints configured by the user or controlled through managed settings.

Local data and credential storage

workgraph stores local state under ~/.workgraph by default. Important files include:

• ~/.workgraph/workgraph.db: SQLite event store for captured work events.
• ~/.workgraph/settings.json: user settings such as watch roots and ignore rules.
• ~/.workgraph/slack.json: local Slack connector credentials and Slack connector options.
• ~/.workgraph/connectors.json: local connector runtime status, enabled state, and polling intervals.
• ~/.workgraph/memory or configured memory files: local user-owned work memory.

Connector credential files are written with local-user-only file permissions when supported by the operating system. SQLite encryption at rest and operating-system credential-store backed encryption keys are planned but not yet implemented.

Automation and write behavior

workgraph's current connector posture is read-oriented. Slack capture does not create, update, archive, reorder, post, react, or delete Slack content. Future features that draft responses or actions should follow the workgraph rule: suggest, draft, approve, then act. No silent automation should perform external writes without explicit user approval.

Review boundaries

• workgraph is local software, not a hosted SaaS control plane.
• There is no centralized admin dashboard for fleet-wide enforcement.
• Managed settings depend on the organization's endpoint management system to deploy and protect the managed settings file.
• Local users with sufficient device privileges may still access local files outside workgraph's control.
• Optional LLM usage must be governed by the organization's approved endpoint and data-use policy.

Related documents

See the workgraph Privacy Policy and workgraph Terms of Service.

Return to workgraph