Nineteen security agents, one findings folder: how we AI-fied our security program

In November 2025, I turned our security architecture reviews into a repeatable workflow. That’s the whole origin story. No mandate came down to build an agent fleet. I got tired of running the same design review by hand and wrote a workflow for it instead.

By February, the same instinct hit vulnerability triage. That workflow became a real agent, and it needed a name. I called it Tank. Trinity, who audits identity and access across Okta, GitHub, and AWS IAM, and The Architect, who runs the security review on every PR, shipped the same week. The Matrix theme stuck before I even noticed it was a pattern. So did the habit behind it — every time a manual security process got tedious enough, I AI-fied it instead of filing a headcount request.

Now there are 19, and the number that matters landed early: the roster produces 5 to 10 tickets every business day — each flagging a specific high-risk item, whether a vulnerability, a piece of security news, or an internal or external activity that needs attention — from a security team the same size it was before Tank shipped. That’s measured, not vibes: over the past month, the median is six agent-filed tickets per business day — and zero on weekends, because the roster files tickets when there’s a team to read them.

Beyond Tank, Trinity, and The Architect, the roster covers red-team pentesting, shadow IT hunting, dollar-denominated risk quantification, incident response, compliance, chaos engineering, and more. Every agent, with its runbook, lives in the-construct on GitHub. (The names aren’t random, either — each is picked to match the security discipline to the closest-fitting Matrix character.)

What makes the roster work isn’t any one of them. It’s the thing connecting them.

The protocol is a findings folder

Every agent in the roster reads and writes to the same place: a shared, git-tracked findings/ directory. One schema, structured as YAML frontmatter plus a body:

schema_version: 1
agent: trinity
severity: high
domain: 5 — Identity & Access Mgmt
subject: okta-user:jdoe@montecarlo...
owner: unknown
status: open
evidence: [okta, github]
suggested_next: [morpheus]

The body is read as data, never as instructions — evidence links to the system of record, never raw secrets or PII. The field that matters most is suggested_next. That’s the handoff. Trinity finds an Okta account with no MFA on an identity that also has GitHub write access, writes the finding, and Morpheus picks it up to draft a just-in-time nudge with a deadline.

If you’ve looked at Google’s A2A protocol, the mapping is almost embarrassingly direct: finding ≈ artifact, suggested_next ≈ task, the 19-agent roster ≈ skills. I didn’t set out to implement A2A. I set out to stop losing findings between people who didn’t talk to each other, and ended up rebuilding the same shape from first principles.

Real example — the Vercel incident (April 2026)

In April 2026, Vercel — a web-hosting service several Monte Carlo teams used to build and share internal tools — disclosed a breach. Attackers didn’t hit Vercel directly: they compromised a third-party AI tool, Context.‌ai, via malware on an employee’s personal laptop, then pivoted into Vercel through an OAuth “login with Google”-style connection Context.‌ai had into Vercel’s environment. From there they reached deployment configuration, including environment variables that commonly hold API keys and DB credentials.

Our direct exposure was limited, but the incident surfaced a real problem. The primary attack vector — Context.‌ai’s OAuth app — had never been approved in our Google Workspace, so it was blocked before this even happened, and we received no breach notification. But when we swept for our own footprint, we found 7 internal tools MC employees had built and shipped on Vercel without going through security review — several storing live API credentials for SaaS and AI services we use, one publicly reachable with no login, and a few with passwords pasted in plaintext into Slack.

How we ran the investigation. We didn’t do that sweep by hand — we drove it through the Matrix roster, composing the specialists above against the incident:

• John Wick (incident response — Okta, Slack, Wiz, Aikido, Linear) led the investigation as a research-and-synthesis agent: he correlated the timeline, pulled the Google Workspace OAuth grants to check for the Context.‌ai IOC app ID, and synthesized intelligence for the humans to act on — he surfaces, we make the calls.
• Oracle (shadow IT & exposure — Aikido, Wiz, Slack, GitHub, Notion) did the actual footprint hunt: 70+ targeted Slack searches, GitHub code searches across the org, and DNS probes of MC-pattern subdomains to build the confirmed-exhaustive inventory of the 7 apps.
• The Merovingian (asset security & data classification) and Seraph (risk quantification — FAIR) sized the blast radius — including an exposed customer renewal portal tied to dozens of customer accounts and six figures of recurring revenue — so we could rank what to shut down first.
• Security Steve is the concierge that routes a request like this to the right agents in the first place.

Every step of that ran through the findings folder: John Wick’s timeline, Oracle’s inventory, and the blast-radius numbers each landed as findings with suggested_next pointing at whichever agent should act next — the same handoff protocol described above, exercised under real incident pressure.

Because every agent authenticates through shared service accounts (mostly read-only) rather than a personal login, the whole investigation ran with clean, attributable audit trails and no single-person dependency.

The takeaway: the breach itself barely touched us; the ungoverned shadow deployments it forced us to go find were the real risk — and the roster is what let two people inventory and triage that footprint in hours instead of days.

Standardization was the unlock, not the model

Nobody needed a better model to make this work. What I needed was one finding format, one naming convention, and one shared place every agent looks before deciding what to do next. That’s what let a design-review habit turn into 19 agents without turning into 19 incompatible scripts that only I could maintain. When Monte Carlo restructured engineering, Lior wrote that standardization isn’t bureaucracy — it’s what lets autonomy scale. The security roster is that thesis, proven on one team.

A better model is not a safer agent.

So what’s actually running these 19 agents? Security Steve — the concierge — ships as a GitHub Action, a skill in Claude Desktop, and an agent on our internal Agent Hub, and any employee can trigger it directly. By default it also runs every morning on its own, building tickets for the security team without anyone asking. From there, Steve spins up whatever agents and sub-agents the request needs — with one hard rule about blast radius. Low-risk analysis agents run automatically; consequential ones — incident response, red team, outreach to employees, anything critical — are staged for human approval before they act. Autonomy scales the investigating. Humans still gate the acting.

Agents reach real systems through MCP servers, and every credential they use — API keys, tokens, service account secrets — lives in a 1Password vault rather than in code or config. The model layer runs on Anthropic (Claude Fable 5 by default), with GPT-5.5 as a fallback if Anthropic is unavailable.

There’s no separate “agents watching agents” layer scoring every run. Agents know what to do next because of the same handoff framework described above — the findings folder tells them what’s expected — and they know when something’s gone wrong because their guardrails break during execution instead of failing silently. That’s a lighter answer than a full eval harness, and it’s one of the places this is still maturing.

None of this added headcount. What changed is turnaround time — over the past month, the median agent-filed ticket closed in about two hours, versus roughly eighteen for tickets humans filed in the same window — and how much ground a small team can cover.

What I got wrong

My biggest mistake was trying to cram too much into one agent. The early instinct was consolidation: why maintain separate specialists for identity, vulnerabilities, and network security when one omniscient security agent could do it all? Because context windows are finite and attention degrades — that’s why. Every capability I bolted on consumed more of the context budget, and past a threshold the quality didn’t dip, it cratered: Claude would drift mid-investigation, conflate domains, and confidently apply the wrong runbook. The failure mode wasn’t a crash — it was context rot, which is worse, because it still looks like work.

The fix was aggressive decomposition. One agent, one security domain, one job it can hold in its head end to end. That’s how a plan for a handful of agents became 19 and counting — not ambition, just the single-responsibility principle asserting itself at the agent layer. The roster is big because the agents are small.

What’s not solved yet

The honest answer is that this isn’t a finished system, and it probably never will be. The harder problem right now isn’t any individual agent — it’s adoption: getting the rest of Monte Carlo to use agents and skills as consistently as the security team does, and to hand off information between them with the same discipline. There’s no clean number that proves it’s “done,” because software isn’t done, it’s maintained. What I can say is that the roster has now carried four real investigations inside the security team end to end and held up each time — battle-tested, not theoretical, but still a work in progress.

It’s open source

The full roster shipped as a public GitHub project. It’s the-construct — Apache 2.0, public for a while now, long enough that the part worth borrowing, if you’re building something similar, is the pattern more than the code. Though the license means you’re welcome to the code too.

One more thing worth saying plainly: I designed, built, and operate this roster while keeping pace with the rest of Monte Carlo’s security asks largely solo. That’s not a complaint — it’s the proof of concept. More agents are already in the pipeline — agent #20, The Analyst, will validate and triage fired Panther detections — but the next phase isn’t about growing the roster. It’s about maturing it.

Why now

Attackers automated first; most defense teams are still trying to hire their way back to even. The economics have flipped — a specialist agent now costs an afternoon to stand up, and every quarter you wait, the gap compounds. Our own next moves are deliberate rather than flashy: we’re using OWASP SAMM as the maturity yardstick to harden each agent in the roster, while expanding the agents’ integrations across the entire business where it makes sense — not everywhere, just wherever a handoff gets dropped today.

If your security team is still routing findings by tagging people in Slack and hoping someone follows up, you don’t need a bigger team. You need one shared place every process looks before deciding what happens next.

github.com/monte-carlo-data/the-construct

Our promise: we will show you the product.