If your team runs AI agents or background jobs on Trigger.dev, treat the secrets stored as environment variables there as potentially exposed until the company confirms your status, and plan to rotate the important ones. Trigger has not said which customers were affected, so you cannot rule yourself out from the public record. The real cost sits in the downstream services those keys unlock, not in Trigger itself.
What happened
According to The Register, Trigger.dev disclosed a security incident on Sunday. Its report said the investigation found exposure across “a subset of organizations” and that an attacker gained unauthorized access to environment variables belonging to them.
Trigger says it has blocked the exploit and has notified affected customers of the steps they should take. The company declined to give The Register more detail and pointed to a full incident report still to come. It has not named the affected organizations.
Trigger.dev is a platform for building AI agents and workflows in TypeScript. It sells durable execution: retries, queues, elastic scaling and long-running tasks that survive crashes and redeploys. Its site lists Emporio Armani, GovSignals and Cal.com among its customers.
Why it matters
Workflow and agent platforms sit in a sensitive spot. To do useful work they need credentials for payment systems, databases, messaging tools and model providers, and teams commonly keep those as environment variables. A breach of the platform can therefore reach many separate systems.
The product’s strengths could also raise the stakes. The Register notes that automated retries, elastic scaling and high concurrency could compound the consequences of compromised API keys, depending on what those keys allow. Trigger also recently added webhook support for services such as Stripe, Supabase and Slack, which could widen the set of integrations affected if their credentials were exposed.
This resembles a pattern we have covered before: a single vendor holding data or access for many companies becomes a concentrated target, as we discussed in our Bullhorn analysis. It suggests buyers may start asking harder questions about how agent platforms store and isolate secrets. The Register also points out that Trigger is open source and can be self-hosted, which may tempt some teams, though self-hosting moves the security work onto your own staff.
What it means for you
If you use Trigger.dev, act now rather than waiting for the full report.
- Check your status. Look for a notice from Trigger and ask its support team to confirm whether your organization was affected.
- Inventory secrets. List every environment variable in every Trigger project and environment, including staging.
- Rotate, starting with the most powerful. Payment keys, database credentials, cloud access keys and webhook signing secrets come first.
- Review logs at the other end. Check Stripe, Supabase, Slack, model providers and your own APIs for unusual calls, unfamiliar IP addresses or spikes in usage.
- Follow the vendor’s instructions. If you received a notice, complete the listed steps and keep a record for any compliance obligations.
- Cut the blast radius. Issue narrowly scoped, short-lived keys per workflow, with spending limits and IP restrictions where providers allow.
Buyers should also ask any workflow vendor how it encrypts secrets, who inside the company can read them, and how quickly it tells customers about exposure. Consider scheduling rotation drills, because a rotation that takes days may point to a design weakness. Check which dependencies on your SaaS list hold live credentials. If you weigh self-hosting, cost it honestly, including patching, monitoring and secret management.
What to watch
- Trigger’s full incident report, especially the root cause, the time window and how many organizations were affected.
- Whether Trigger changes how it stores or exposes environment variables, for example stronger isolation or integration with external secret managers.
- Reports of misuse of keys at connected services, which would show whether the exposure led to real abuse.
- Customer reactions, including any move toward self-hosted deployments of the open source platform.
