Trigger.dev Breach Exposes Customer Secrets

Customers of Trigger.dev who run their AI workflows on the hosted version of the platform got an unwelcome message this week: someone else may have been reading their configuration secrets. In a Sunday security incident report, the company said an attacker had gained unauthorized access to environment variables belonging to some of its users, and that affected organizations were being notified individually.

The disclosure was terse. Trigger said its investigation identified “exposure across a subset of organizations,” and that the exploit used to get in has since been blocked. It did not say how many customers were affected, what the entry point was, or how long the unauthorized access lasted.

A short note and a lot of gaps

The incident report offers little beyond the core admission. Trigger confirmed that environment variables belonging to a subset of organizations were accessed without authorization, stated that the vulnerable path has been closed, and said customers who were affected have been given steps to follow to prevent further security problems. That is essentially the full public account so far.

When The Register asked for more detail, a company spokesperson declined to elaborate and said a full incident report would come later. Until that document appears, the scope of the intrusion, the identity of the attacker, and the nature of the exploit remain unknown outside Trigger and the customers it has contacted.

“Exposure across a subset of organizations” is doing a lot of work in that sentence, and it is the only characterization the company has offered of how widely the problem spread.

Why environment variables matter here

Environment variables are the place cloud services stash configuration values that code needs at runtime, and in practice that frequently means credentials — API keys, tokens, connection strings, and secrets for third-party services. Anyone who ends up holding those values can often act with the same privileges the application itself was granted.

What makes the exposure more consequential for Trigger specifically is what the platform does. Trigger.dev is a durable execution platform for building AI agents and workflows in TypeScript. It handles retries, scaling, queues, and keeps long-running tasks alive through crashes and redeployments, while giving customers tools to monitor what those tasks are doing.

The company's own site pitches it as a way to “build durable AI agents that survive refreshes, redeploys, and crashes,” aimed at “long-running tasks with retries, queues, AI observability and elastic scaling.” Customers choose it precisely so that their automation keeps running without babysitting — which means the credentials behind those workflows are wired into a system designed to keep executing things on its own.

What stolen keys could reach

Trigger recently added webhooks to its offering, including support for services such as Stripe, Supabase, and Slack. That widens the set of integrations whose credentials could be sitting in a customer's environment configuration, and therefore the range of connected services an attacker with stolen secrets might be able to interact with.

An attacker holding a customer's exposed credentials could potentially interfere with that customer's connected services or its workflows. The platform's features that make it attractive — elastic scaling, automated retries, and the ability to run many concurrent operations without timeouts — could compound the consequences depending on what those credentials are permitted to do.

None of this has been confirmed as having happened. Trigger has not said that any affected customer's third-party accounts were misused, only that environment variables were accessed. The distinction matters: exposure creates the opportunity, and what an attacker does with it is a separate question the company has not addressed.

A customer list with recognizable names

Trigger's public roster of customers includes some recognizable organizations. The company's site lists fashion brand Emporio Armani, Pentagon-supporting AI acquisitions platform GovSignals, and SaaS calendar platform Cal.com, among others.

Trigger has not publicly identified which organizations were affected by the intrusion. The customer names on its website are a marketing list, not a disclosure of who received a notification, and the company has not connected the two. Readers should not assume that a logo on the homepage means that company was among the affected subset.

The self-hosting escape hatch

One detail worth noting for anyone weighing their options after this disclosure: Trigger is open source and can be self-hosted. That means organizations that want to keep running its workflow engine but are uncomfortable with secrets living in a vendor's hosted environment have a path to run the software on infrastructure they control.

Self-hosting is not a fix for every class of problem, and the source article does not claim it is. It does change who holds the environment variables, and for teams that treat credentials as the crown jewels of their automation stack, that shift in custody may be the deciding factor.

What affected customers should be doing

Trigger says it has notified affected customers and provided them with steps to take. The company has not published those steps, so the specifics are between Trigger and the organizations it contacted. What is clear from the nature of the exposure is the category of work involved: anything that lived in an environment variable and could grant access to something else is a candidate for review.

That generally means rotating credentials that were stored in the platform, checking logs on connected services for activity that doesn't match expectations, and reviewing what the exposed keys were actually permitted to do. Because Trigger supports webhooks into services like Stripe, Supabase, and Slack, the blast radius question extends beyond Trigger itself to whatever those credentials unlocked.

The company's guidance that the exploit has been blocked addresses the entry path, not the credentials that were already read. Those two things are separate, and the second one is the reason for the notification.

The report Trigger hasn't written yet

For now, the full incident report is the missing piece. It would normally be expected to cover how the attacker got in, when the access began, which organizations were touched, and what data specifically was taken. Trigger has promised that document but has not said when it will arrive.

Until then, the public record consists of a Sunday disclosure confirming unauthorized access to environment variables for a subset of organizations, a statement that the exploit is blocked, and notices sent to affected customers. That is a thin account for an incident involving credentials on a platform built to keep automation running unattended.

Why this matters beyond Trigger's customer base

The uncomfortable lesson here is about concentration. Organizations increasingly hand their automation — including AI agents that are meant to run continuously — to hosted platforms, and those platforms necessarily hold the keys their customers' workflows use. When a vendor's environment variables are compromised, the customer's own security posture is only as good as the vendor's, no matter how carefully the customer manages its own infrastructure.

This suggests that buyers of durable execution and AI workflow services may want to ask harder questions about how secrets are stored and scoped on the vendor side, and whether self-hosting is a realistic fallback. For Trigger's customers specifically, the practical takeaway is that a terse disclosure about “a subset of organizations” leaves each one to determine for itself whether it is in that subset, and to act on the assumption that its credentials may need replacing.

Trigger has said a fuller report is coming. How much it explains — and how quickly — will shape how much confidence customers can place in the hosted model going forward. For now, the safest posture for anyone running sensitive integrations through the platform is to treat exposed secrets as spent and rotate them.