The Compliance Fire Drill I Refuse to Run Again: Building Trent's GRC Program With Our Own AI Security Engineer

By Julien Brouchier, MTS @ Trent (Agentic AI Security)

A few months ago I wrote about becoming the first security engineer at a startup, living the interview scenario I used on more than a hundred candidates. Here is the sequel: the moment that scenario stops being about the product and starts being about the paperwork. This is how I used the Trent AI Security Engineer for Governance, Risk Management, and Compliance (GRC) to build Trent's own compliance program, why the gaps it found were more valuable than the coverage it confirmed, and how a Senior Security Director at a bank turns the same output into budget.

Two Weeks to Produce a Year of Evidence

As a senior security engineer at one of the GAFAM, I lived through the seasonal pressure of "we need evidence for this compliance framework audit IN THE NEXT TWO WEEKS." If you only ever respond to that time-bounded pressure, you end up permanently reactive: you sprint, you assemble screenshots and exports, you survive the audit, and you swear it will be different next year.

Once you've been through it once, you do prepare a bit more. But then a second problem shows up: too many frameworks and too many tools with overlapping capabilities. Which of your fifteen tools proves which of your four hundred controls? Usually the answer lives in one veteran's head, or in a spreadsheet last updated two audits ago.

The question every security org must answer is deceptively simple: given the compliance frameworks I'm accountable for, do I have the right tools in place to cover every required capability? Answering it properly means reading hundreds of pages of framework documents, translating each control into a capability (SAST, DAST, CSPM, PAM), and checking whether your tools deliver that capability for the stack you run. Most startups don't do it at all; the gaps go undetected until an auditor finds them.

The Tables Turned, Again

When I joined Trent as the first security engineer, I knew this moment was coming. A security startup selling to security teams gets asked about its own posture early. SOC 2 questionnaires, GDPR obligations, and customer security reviews: the GRC clock starts with the first enterprise-shaped prospect.

In my interview role-play, the surprise card was: "The CEO calls you at 6pm and asks if we can achieve SOC2 compliance by the end of the week." Now I'm the one taking that call. We had just extended the Trent AI Security Engineer into GRC with the Security Program Mapper, so I pointed it at Trent itself.

Three Lists In, One Map Out

The design principle is that the user should never need control IDs or subsections. You supply three plain lists: frameworks (GDPR, SOC 2, NIST CSF v2, PCI DSS, CIS, ISO/IEC 42001), security tools, and tech stack.

Trent reads the frameworks, extracts and de-duplicates every capability they require, maps your tools onto those capabilities against your stack, and produces a structured matrix. Every row carries category, capability, plain-language requirement, tool(s) in place with gaps called out, sources (frameworks and control IDs), and notes on why coverage is or isn't complete.

Two example rows: SAST may show Partial when Apex is uncovered (PCI 6.2.3, NIST SA-11(1), CIS 16.12). DAST may show Gap when you have API DAST and a manual pentest but no automated web-UI DAST (PCI 6.4.1 / 11.3.1). An LLM does roughly 95% of this in minutes instead of weeks. The remaining 5% is you: reviewing and refining. That's deliberate.

The tech stack is not decorative

The question is never "Do you have SAST?" It's "Does your SAST cover Apex?" A scanner that handles JavaScript beautifully but has never heard of the Salesforce code in your revenue path is a Partial, not a Full. That blind spot survives multiple audit cycles when nobody cross-references tool coverage against the stack inventory. The mapper does that on every row.

Citations, or it didn't happen

Every capability maps back to specific control IDs. Vague claims like "PCI requires this" die in front of an experienced auditor. When you argue for budget, you're presenting a named control deficiency with a paper trail, not abstract risk.

What Came Back When I Ran It on Trent

I fed the mapper our frameworks, tooling, and stack, and got several dozen capability rows. Reviewing took an afternoon. The handmade equivalent is a multi-week project you keep deprioritizing until an auditor forces it.

Three observations from dogfooding:

1. The gaps are the product. Gap and Partial rows became a prioritized backlog with framework citations, before any auditor asked.
2. The Notes column earns its keep. "Tool X covers three of four stack components; Y needs a stack-native scanner" is actionable on Monday morning.
3. It's opinionated output, not automation. A couple of verdicts I overruled because deployment details the input lists missed. This is practitioner-grade output a human reviews, not an audit-ready attestation.

From Gap Table to Budget

A senior cyber security leader in a financial institution funds programs with the same kind of map: translate maturity gaps into defensible control deficiencies mapped to NIST CSF or CIS, then sequence remediation with before-and-after metrics.

Example: only 68% of internet-facing assets in vulnerability scanning, critical vulns averaging 32 days against a 15-day SLA. The funding request bundles attack-surface management, process work, and one analyst, targeting 95% coverage and sub-14-day critical remediation within 12 months.

"This shifts the conversation from general security spend to measurable risk reduction tied to business impact."

That method needs a defensible map of required capabilities, coverage, named deficiencies, and framework citations. Row for row, that is what the Trent Security Program Mapper produces. Same artifact, two audiences: build the program, or defend the spend.

What This Is Not

Let me be as blunt as I was in our ClawHub analyses: an LLM-generated mapping is not a certified compliance attestation. Real coverage depends on configuration, license tiers, and deployment details no tool-name list fully captures. The mapper compresses weeks of framework reading into an afternoon of expert review, so no capability silently falls through the cracks.

That's the difference between finding your gaps in July on your own schedule, and finding them in November because an auditor did.

By Julien Brouchier, MTS @ Trent AI