Do you retain Slack messages or Asana task content?

No. Slack messages and selected Asana task or project fields stay on the live request path and are not retained as product analytics, prompt logs, generated reports, or connected-content telemetry.

How are connector credentials stored?

Official Slack and Asana OAuth credentials use tenant-bound AES-256-GCM encrypted storage with Cloudflare secrets-managed keys. The legacy Slack session-token fallback can remain ephemeral or be stored only with explicit consent.

What analytics are enabled?

Hosted web pages use Cloudflare Web Analytics plus limited first-party funnel events. Workflow operations record content-free outcome metadata such as workflow kind, success or bounded error code, plan, and duration. Neither layer stores Slack messages, Asana task content, prompts, generated reports, or source identifiers as analytics.

Where should buyer security or procurement questions go?

Use this page plus deployment review for buyer-facing security, rollout, support-envelope, and procurement questions. GitHub remains the self-host surface.

Security

Know what is stored, what stays transient, and how delivery is verified.

This buyer-facing trust surface covers Slack and Asana OAuth, encrypted storage, content-free workflow measurement, zero-write analysis, signed downstream delivery, analytics disclosure, and the route for deeper rollout review.

Request deployment review Open live status

Security summary

HTTPS/TLS on all hosted traffic
Official Slack and Asana OAuth with tenant-bound state
PKCE S256 on the Asana authorization-code flow
AES-256-GCM encryption at rest for stored connector credentials
No Slack message or Asana task-content retention as product analytics

Request deployment review Open /status

Token and storage model

Official OAuth: Slack and Asana access is encrypted, tenant-bound, and revocable
Legacy Slack fallback: ephemeral by default; persistent only when the operator explicitly consents
Bearer keys: tenant-scoped API keys gate MCP access
Connection surface: reconnect and disconnect stay available through /setup and authenticated APIs

Data boundary

Slack and Asana requests pass through the hosted worker and return directly to the MCP client or validated report
Slack messages, files, channel history, and Asana task or project content are not stored as analytics payloads
The Slack-to-Asana report reads one selected project, caps incomplete tasks at 100, and performs zero external writes
Workflow measurement tracks kind, outcome, bounded error code, plan, and duration — never connected content, prompts, generated reports, source identifiers, or webhook URLs
Full data-handling detail stays in privacy

Encrypted profiles and signed downstream delivery

Saved profiles are tenant-scoped and contain only the configuration an operator explicitly submits
Webhook URLs and P-256 private signing keys are AES-256-GCM encrypted at rest
Public P-256 verification keys can verify each timestamped payload without exposing private signing material
Webhook targets must be public HTTPS endpoints; private hosts, IP literals, embedded credentials, redirects, and nonstandard ports are rejected

Website measurement

Cloudflare Web Analytics covers the hosted website only
First-party funnel events cover pricing, deployment, checkout, setup, and account actions
Neither layer changes connector credential handling or connected-content retention
Use this page and privacy for procurement review, not GitHub issues

Support and incident envelope

Solo: managed endpoint plus standard hosted support routing
Team: adds shared workflow outcomes and higher usage ceilings
Turnkey Team Launch: rollout and buyer review envelope
Managed Reliability: ongoing operational support boundary when Slack context is business-critical

Procurement questions this page answers

Where tokens live and how they are protected
What data is and is not retained
Which routes are public versus authenticated
How support, rollout, and reliability expectations are scoped

Ops engagement (SOC2 + custom retention) Hosted docs

Deployment review scope

Use deployment review when the team needs buyer review, rollout sequencing, support-envelope clarification, or premium fit guidance. That keeps the commercial and operational conversation on the hosted surface.

Open deployment review Open support

When self-host is the better answer

If procurement or operations require full runtime ownership, local transport control, and direct token handling under your own environment, the OSS/self-host path remains available with 21 tools.

Review self-host Official vs managed