Synthesia Deploys Agent Swarm to Secure Its Syren Product in Real Time

A launch with no room for shifting left

According to Synthesia, Syren was built the way much software is built now: by engineers directing coding agents. In the first couple of days, the main repository saw around 170 pull requests, all written by agents and merged by humans. There was no threat model and no security review, while the launch date was, in the company's words, "set in stone".

Gianluca Brindisi, Application Security Engineer at Synthesia, writes that the traditional approach of shifting security left does not work in this setting, because there is no left to shift to when the design changes faster than a review cycle. The security team therefore had to work while the system was being built. That meant giving guidance in real time, contributing fixes directly, deploying continuously to a test environment for quick validation, and tuning every guardrail as it went in.

Captains and workers: how the agent hierarchy works

Synthesia had previously written about scaling vulnerability management after issues ship and about automating code security reviews before changes merge. Both are pipelines with fixed phases. Here, the company says, the aim was to help the human operator keep a current and correct mental model of the system, which it calls the "meat context". For this it used a local agents orchestrator built in-house, which arranges agents in a hierarchy of small teams.

There are two kinds of agents:

• Captains: smart, long-running agents on the host, each owning an area of work. They can read Slack, Linear and observability tools, use the GitHub CLI, start other agents and open pull requests when allowed. The operator, the security engineer running the fleet, can join any captain at any time.
• Workers: disposable, sandboxed agents that each receive one written brief and return one result, such as a report, commits or a validation. They have a fixed network allow-list, no access to internal systems, no push rights and no access to production. Their captain checks their output before it is used.

This creates two trust tiers: full autonomy where the blast radius is small, and supervision where an agent can act on shared systems. Feature flags, the cloud console and a logged-in browser stayed out of reach of every agent. Synthesia also says it right-sizes the model to each task, and that because current frontier models refuse many cybersecurity tasks, it delegated those to near-frontier open models.

From context gathering to operations

The first agent started was a context gatherer. It watched the product team's engineering activity and pull requests, built a map of the system covering components, owners and fast-moving areas, and pinged the team when something security-relevant happened. Synthesia says it flagged several risky changes over the week. It was not perfect, and some pings overstated issues, but the signal-to-noise ratio improved. Once engaged, the median time from a ping to the team acting on it was about 13 minutes.

Each uncharted area is then assigned to a new captain, starting with a short brief to map data flows and review the current implementation. That captain decides how to split work across parallel workers or sub-captains, which model to use, how to validate results, and how to design, implement, deploy and monitor a fix. The process is recursive, so captains grow their own teams over time.

Synthesia describes four stages of maturity, and says one area can move through all of them in a few days, even back and forth:

• Understand: agents explain components, draw architecture and help validate bigger issues in the testing environment.
• Design: agents act as design partners for threat modeling and for deciding how a control should behave, including when it fails open or closed. The company calls an hour of this "some of the highest-leverage time of the week".
• Engineer: the captain writes a plan, workers implement it, and the captain reviews and opens a pull request. According to Synthesia, a design session in the afternoon could become a merged control by the evening.
• Operations: agents monitor the test environment, root-cause failures, run bespoke integration tests, set up alerts and keep evals running.

What it means for security teams

The post presents the approach as a response to a specific condition: products built by engineers directing coding agents, where review cycles cannot keep up. Synthesia's position is that security work has to mirror the way the builders work, with agents doing the reading and implementation while a human operator holds the mental model and makes the calls.

The company also says it measured the cost of the approach in money and in human attention. The text available here is cut off before those figures and before the section on evaluating guardrails, so they are not reported in this article. The post notes that the systems being secured are themselves increasingly agentic.