Privacy Policy

2.1 Account Data

When you register for an account, we collect information provided through our authentication provider (currently Clerk) and our application:

• Email address
• Full name
• Profile photo (if provided)
• Organization/Teamspace name
• Authentication identifiers issued by our identity provider

2.2 Workspace Metadata

As you use the Platform, we store your workspace data including:

• Project and workflow names
• Node configurations (visual graph JSON)
• Plugin settings and connections
• Deployment configurations

2.3 Connected Third-Party Accounts (OAuth & Integrations)

When you connect third-party services under Connections (for example Slack, GitHub, Google, Linear, or MCP providers), we process:

• OAuth authorization codes and access tokens (encrypted at rest; used only to perform actions you configure)
• Workspace or installation identifiers needed to route events (e.g. Slack team_id, GitHub App installation id)
• Scopes you grant and connection metadata (display name, status, provider)
• Event payloads delivered by those providers when a workflow trigger is subscribed (e.g. Slack messages, GitHub webhooks, Google Sheets change notifications)

Tokens are stored encrypted. We do not use connected-account data for advertising. You may disconnect a provider at any time; we will stop using that connection for new runs. Event content is processed to execute your workflows and may appear in run logs/history according to your retention settings.

2.4 AI & Model Provider Inputs

If you use AI agent nodes or other LLM-powered features, prompts, tool outputs, and related context you configure may be sent to the model provider(s) you select or that are required to run the node (for example OpenAI, Anthropic, or other providers configured in your workspace).

• We do not use your prompts or workflow content to train Tensorify-owned foundation models.
• Third-party model providers process data under their own terms and privacy policies; review those before enabling AI features with sensitive data.
• You control which providers and keys are used via Connections and environment configuration.

2.5 Trigger Ingress & Webhook Data (All Modes)

Most workflow triggers are received on Tensorify-operated endpoints first (for example managed webhook URLs, Slack Events, GitHub App delivery, Google push notifications, and similar provider callbacks). That is true whether the run later executes on Tensorify Cloud or on a self-hosted Runner.

For those triggers we process:

• HTTP request method, path, headers needed for routing and verification (including signatures), and query parameters
• Request body / event payload required to start the workflow
• Verification challenges and subscription handshake data from providers
• Our HTTP response to the provider (status and any acknowledgment body we return)

Choosing a self-hosted Runner does not bypass this ingress path: the event still hits Tensorify so we can authenticate it, match it to your workspace and deployment, and queue a job. The Runner then pulls or receives that job and executes your graph on your machine.

2.6 Execution Data (Cloud Runs)

When a run executes on Tensorify Cloud, we also process:

• Node inputs and outputs needed for the run, debugger, and variable picker (subject to retention settings)
• Execution logs (timing, status, errors, stack traces where applicable)
• Secrets and connection tokens as required to perform the actions you configured (encrypted at rest; injected for the run)

2.7 Execution Data (Self-Hosted Runner)

When a run executes on a self-hosted Runner, Tensorify still processes trigger ingress as described in §2.5. For the run itself we typically also receive:

• Job dispatch data required for the Runner to execute the workflow (including the trigger payload needed by your graph)
• Node execution status (started, completed, failed)
• Node output snapshots when the debugger / variable picker features are enabled
• Run identifiers, timing metadata, and plugin errors reported by the Runner

Environment variables and secrets that exist only on the Runner host are not required to be uploaded to Tensorify for local execution. File-system contents, databases, and other services your Runner reaches directly on your network are not automatically collected by us—only what your workflow is configured to send back (status, outputs, errors) and what already arrived through managed trigger ingress.

2.8 CLI Telemetry

The Tensorify CLI may send limited operational telemetry separate from run payloads:

• Runner heartbeat (online / offline)
• CLI version and operating system type
• Aggregate execution counts (not full business payloads)

2.9 Payment Data

Payment processing is handled entirely by Stripe, Inc. We do not store your credit card number, CVV, or full billing details. We retain only your subscription plan type, Stripe customer ID, and subscription status for account management.

2.10 Usage Analytics

We collect analytics data via PostHog including page views, feature usage patterns, and session recordings on our web application. This data helps us improve the product experience. You can opt out of analytics tracking at any time.

2.11 Technical Data

We automatically collect technical data including IP address, browser type and version, device type, operating system, referring URL, and access timestamps. This data is used for security, abuse prevention, and service optimization.

5.1 Data in Transit.

Traffic between clients, providers, and Tensorify services is encrypted in transit (TLS).

5.2 Data at Rest.

Account data, workflow definitions, connection tokens (encrypted), and retained run logs are stored with encryption at rest on our hosting providers.

5.3 Payload & Log Retention.

Trigger payloads and node outputs may be retained in run history and logs so you can debug and re-use variables. Retention follows product settings and operational needs (including abuse investigation). We do not treat every payload as purely ephemeral in-memory only.

5.4 No Model Training on Your Content.

We do not use your workflow definitions, run payloads, or connected-app content to train Tensorify-owned foundation models. Third-party model providers you enable process data under their own policies when AI nodes call them.

5.5 Geographic Processing.

Managed execution is currently processed in United States data centers (US East, hosted on Railway). We will notify you in advance if processing locations change.

6.1 Data Visibility.

All resources within a Teamspace (workflows, projects, execution history, API keys) are visible to all members of that Teamspace. Owners and Admins can view all team execution history and manage access.

6.2 Member Removal.

When a member is removed from a Teamspace, their access is revoked immediately. Data they contributed to the Teamspace remains with the Teamspace and is not deleted.

6.3 Isolation.

Data is strictly scoped to Teamspaces. There is no cross-Teamspace data sharing, visibility, or access. Each Teamspace operates as an independent data boundary.

8.1 Essential Cookies.

Required for authentication, session management, and CSRF protection. These cannot be disabled without losing access to the Service.

8.2 Analytics Cookies.

PostHog analytics cookies help us understand usage patterns and improve the product. You can opt out of analytics tracking through the cookie consent banner or your browser settings.

8.3 Marketing Analytics.

Ahrefs web analytics is used on our marketing site only to understand traffic sources and page performance. It does not track individual users across sessions.

8.4 No Advertising Cookies.

We do not use advertising cookies, retargeting pixels, or any third-party advertising trackers. We do not participate in ad exchanges or programmatic advertising.

Incident Response.

In the event of a data breach that affects your personal information, we will notify affected users within 72 hours of confirming the breach, in compliance with GDPR Article 33. Notification will include the nature of the breach, data affected, measures taken, and recommended actions.