Security
This page describes Task Machine's current security boundaries and operating practices for the website, application, local daemon, and managed execution.
Last updated:
Infrastructure security
Task Machine runs on managed infrastructure for application hosting, PostgreSQL, object storage, transactional email, observability, networking, and backups. Production access is limited to the operator and systems that need it, and infrastructure changes are managed as reviewed code.
Public traffic is served over HTTPS. Managed PostgreSQL encryption at rest is enabled, object-storage buckets holding private product data are private, and application access uses scoped infrastructure identities. Provider backup schedules and retention remain part of the underlying managed-service configuration.
Data in transit
Traffic to taskmachine.io and the application uses HTTPS through Cloudflare's reverse proxy and managed web application firewall. Cloudflare terminates client TLS and inspects proxied traffic, then uses a separate TLS connection with strict certificate validation to the Scaleway origin. This is not end-to-end encryption that hides application content from Cloudflare. Managed daemons and model-gateway requests use TLS with credentials scoped to the workspace, machine, run, and route where applicable. Plaintext public requests are redirected to HTTPS in production.
Data at rest
Application data is stored in Scaleway Managed Database for PostgreSQL. Uploads, generated artifacts, skill bundles, static assets, and backup material use Scaleway Object Storage according to their purpose. Vault secrets are encrypted before storage with key material separated from the database.
Task Machine automatically stores private checkpoints of Local Worker and managed cloud sandbox working directories in Scaleway Object Storage in Amsterdam, Netherlands. Gitignored files are excluded when the directory has a remotely reachable Git base. Other directories are copied in full, including hidden files and credentials present there. Scratch files are not included.
Private working-file checkpoints are the source of truth for Local Workers and managed cloud sandboxes. Sandbox disks are temporary caches. Task working files expire 14 days after the last update, or 7 days after completion, cancellation or archiving, whichever comes first. Chat working files expire 14 days after last activity or 7 days after archiving, whichever comes first. Other work scopes expire after 14 days without activity. Repeating an archive request does not restart the clock. Restoring a Task or Chat removes its archive-based deadline but cannot recover deleted working files. Active or queued Runs prevent cleanup. These rules apply to existing working files. Chats already archived when the archive clock is introduced use the migration time for that clock, without extending an earlier inactivity deadline. Already-expired files may be removed without another checkpoint. Deleting working files does not delete product records or transcripts. This is not a permanent-backup or crash-recovery guarantee. Workspace deletion removes checkpoints, with unreferenced bytes removed by background cleanup. Confirmed local caches become eligible for immediate removal for completed, cancelled or archived Tasks and archived Chats. Other confirmed idle caches are removed after seven days. Offline or customer-controlled copies may remain. A later Run discards an unconfirmed crash copy and restores the last committed checkpoint.
Authentication and access control
People authenticate through verified magic links, Google, or an optional password they set themselves. Passwords are stored only as one-way hashes, passwords found in known data breaches are rejected, sign-in attempts are throttled, setting or changing a password signs out the account's other browsers, and sign-ins from new browsers and password changes are emailed to the account with a one-time link that secures it without signing in. Browser sessions use signed, Secure production cookies with SameSite protection, and forms use cross-site request forgery protection. Workspace roles and permission checks hide unavailable actions in the interface while server-side domain authorization remains the security boundary.
Agents and managed daemons do not receive a human user's general-purpose session. They use purpose-bound, short-lived, revocable credentials scoped to the workspace and active run. Vault grants and connector access are limited to the credentials and actions assigned to the work.
Application security
The application sets security headers including a content security policy, validates provider webhooks before processing them, records payment events idempotently, bounds growing reads and rendered payloads, separates secrets from analytics and logs, and applies framework and dependency security updates through the normal release process.
Browser recording
Automatic screenshots of pages visited by agents are enabled by default. Workspace owners and admins can disable future screenshots and may choose to delete existing images when disabling them. Browser action history continues, and images already delivered to a viewer or retained in backups may remain.
Password, payment, one-time-code and Vault-filled fields and known exact secrets are masked before an image is kept. If masking fails, the image is withheld. Masking cannot recognize every sensitive item, including transformed secrets, canvas content, or information outside recognized controls, so images may still contain personal or confidential information.
Local daemon boundary
Task Machine gives each local run a task-specific work directory and isolated coding-tool configuration. This prevents automatic reuse of unrelated tool settings, plugins, skills, connectors, and sessions, but it is not an operating-system or filesystem sandbox.
A coding tool allowed to use shell or filesystem capabilities runs with the access of the operating-system user that runs tama. It may reach other files, processes, credentials, and network services available to that user. Customers should use a dedicated operating-system user, virtual machine, or container when stronger isolation is needed and should expose only required repositories and credentials.
Managed execution boundary
Cloud Runs execute in managed cloud sandboxes with Task or Chat working files. Managed cloud sandboxes use infrastructure in the EU. Depending on the cloud provider, Task Machine requests Frankfurt, Germany, or the provider reports sandbox locations in Germany, Finland, and France without a datacenter choice. These infrastructure locations do not confine network routing, logs, backups, support access or model-provider processing to those locations. Runtime credentials are supplied through ephemeral storage or process memory rather than the checkpoint-backed working directory, and a Run receives a short-lived Task Machine credential instead of a human session or the workspace's upstream model key.
Prompts, files, tool calls, outputs, and network requests may still be processed by our cloud providers, OpenRouter, the selected model developer, and customer-selected connectors such as Exa. Provider isolation and security practices remain part of the complete boundary.
Provider API keys remain backend-only and are not supplied to managed workers. Task Machine-managed AI, including structured evaluations, uses OpenRouter. Product-side content-bearing requests require zero-data-retention routing.
Logs, analytics, and retention
Task Machine's operational logs are designed to exclude credentials, prompts, file contents, and raw provider bodies. Scaleway Cockpit application logs are configured for 30 days and infrastructure metrics for 15 days. These origin-side logging controls and retention periods do not govern Cloudflare's processing of proxied traffic, caches, or provider-side security records. Product transcripts and run history are separate customer records and follow the Privacy Policy rather than log retention.
Compliance and independent assurance
Task Machine is operated from Spain and handles personal data under applicable EU data-protection law. The Privacy Policy, Data Processing Addendum, and Subprocessor Schedule describe the applicable roles and providers.
Task Machine does not currently claim SOC 2, ISO 27001, penetration-test, or other third-party certification status. Provider certifications do not automatically certify Task Machine. Security and compliance evidence can be discussed for a qualified customer request.
Incident response
We investigate suspected security incidents, contain affected access, preserve relevant evidence, remediate the cause, and notify affected customers, people, Link, or authorities when applicable law or a contract requires notice. The Data Processing Addendum states the processor notification commitment for customer personal data.
Responsible disclosure
Report a suspected vulnerability privately to [email protected] . Include enough detail to reproduce the issue, avoid accessing data that is not yours, do not disrupt the service, and allow a reasonable period for investigation and remediation before public disclosure.
Contact and related terms
For security questions, email [email protected] . Read the Privacy Policy, Data Processing Addendum, and Subprocessor Schedule.