Trigger.dev, a cloud-hosted platform for building AI agents and long-running workflows in TypeScript, disclosed a security incident on Sunday in which an attacker gained unauthorized access to environment variables belonging to a subset of its customer organizations. The company has not said how many customers were affected.
What Trigger.dev Has Confirmed About the Incident
In its incident report, the company said its investigation found exposure across a subset of organizations and that an attacker reached the environment variables those organizations had stored with the service. Trigger.dev said the exploit used in the attack has been blocked and that affected customers were notified of steps to take.
The company declined to share more details and said a full incident report would follow. It has not named the vulnerability, the method of access or the attacker, and it has not stated how long the unauthorized access lasted.
Trigger.dev Has Not Named Affected Customers or Variables
The number of affected customers and the exact variables exposed remain undisclosed. Trigger.dev lists Emporio Armani, GovSignals and Cal.com among customers on its website, but affected organizations have not been named, and nothing in the disclosure ties those companies to the incident.
Why Trigger.dev Environment Variables Are a High-Value Target
Environment variables on a workflow platform commonly hold API keys and cloud credentials, because the jobs the platform runs need those secrets to call outside services. An attacker who obtains them can act against the connected services directly, without needing to compromise those services’ own defenses.
Trigger.dev has recently added webhook support for services including Stripe, Supabase and Slack, which widens the range of integrations a customer might connect. Each integration adds credentials that could sit in a project’s variables, and so extends the set of downstream systems that stolen keys could reach.
Exposed Trigger.dev Variables Put Downstream Services at Risk
Stolen keys could allow attackers to interfere with customers’ downstream services. The exposure therefore extends beyond Trigger.dev itself: a customer whose variables were read may need to treat every credential stored in the affected project as potentially compromised, until the company’s full report says otherwise.
Trigger.dev Is Open Source and Can Be Self-Hosted
Trigger.dev is open source and can be self-hosted. The disclosure concerns its cloud service, and the report does not indicate that self-hosted deployments were affected. Organizations running their own instances hold their own variables on infrastructure they control, which separates their exposure from the hosted incident.
Trigger.dev’s Promised Full Report Leaves Key Questions Open
Several questions remain until the promised report arrives: how the attacker got in, how many organizations were touched, which categories of variables were read, and whether the attacker used any of them. The company’s decision to publish a short notice first and the full account later follows a common sequence in SaaS incidents, where customers need to act quickly on credential rotation before an investigation completes.
Trigger.dev Shows Workflow Platforms Concentrate Customer Credentials
The incident fits a broader pattern in which developer platforms become attractive because they aggregate secrets from many customers in one place. A breach at a single provider can hand an attacker credentials for dozens of unrelated downstream services, each owned by a different organization with its own logging and its own response process.
For AI-agent builders in particular, the secrets stored with a workflow service often include keys for model providers, databases and payment systems. Because the platform executes code on the customer’s behalf, it needs access to those keys when jobs run.
Trigger.dev has said only that the exploit is blocked and customers have been told what to do. The details that determine how far the damage spreads are still to come.
