RAMPCon’s Shared Message on Engineering Trust

The next morning, Phillip and I sat in the audience for our CEO Brad Little’s opening keynote, listening as he talked about engineering the next generation of security for the AI era. Within minutes, I had one of those rare conference moments when separate sessions suddenly click into one larger story. The ideas we had explored the day before through architecture, controls, pipelines, and evidence were now coming through from the main stage as vision, strategy, and urgency. I leaned over to Phillip, grinning, and said,

“I’m not sure we could have scripted better alignment.”

That was the best part. The message was not isolated to one talk or one room; it was moving through the organization. Leadership was setting the direction, technical teams were showing how to execute it, and together they were making the same case from different vantage points. For a company helping customers navigate trust in the AI era, that kind of alignment is exactly where you want to be.

Day 1: Architecture is the control

Our breakout started with a pattern I think every engineering and security team has lived through at some point. The architecture gets designed, then handed off to compliance. Controls get bolted on after the design is already locked. Then the assessment finds the gaps — the flat network with no segmentation, the secrets hardcoded into config files, the infrastructure someone changed by hand in the console with no record of what moved or when, the logging that was never centralized so nobody can answer a three-month-old audit question. And you spend the next few months on expensive rework while your authorization date quietly slips.

We advocated for inverting that order. Read a control like an architect: translate its requirements into concrete design decisions at the design phase, so the system satisfies whole control families structurally rather than through after-the-fact patches. Done that way, most of those anti-patterns never get written up in the first place. Segment by trust boundary in the design and there's no flat network to flag. Keep secrets in a vault and inject them at runtime, and they aren't sitting in a file waiting to be found. Provision everything through code, and configuration drift has nowhere to hide. A few ideas carried the whole talk:

• Build evidence in from the beginning. If your pipeline produces audit artifacts as a side effect of shipping, the assessment scramble disappears.
• Maximize control inheritance. Designing to inherit controls from an already-authorized platform is the single highest-ROI compliance decision a team can make. Every inherited control is a narrative you don't have to write.
• Start from reusable patterns. Compliant landing zones and reference architectures aren't novel — but the discipline of starting from them is what most teams skip.
• Make enforcement continuous. Policy-as-code gates catch a misconfiguration at commit, where it costs minutes, instead of at assessment, where it costs months.

None of this was theory. The numbers we shared came from real work — remediation windows that went from weeks to days, runtime findings that dropped off a cliff, and new resources that passed their controls the moment they deployed instead of after a fire drill. The point was simple: when compliance is an architecture discipline, speed and rigor stop fighting each other.

Day 2: Engineer it in

Brad came at it from a completely different altitude. He opened on the big picture: an industry that's already past its inflection point, where the overwhelming majority of security leaders have hit some kind of AI-related incident in the past year or so. He framed the moment as three forces hitting at once — AI adoption, the expansion of frameworks like FedRAMP and CMMC, and the push to get to authorization faster.

His answer came down to one shift. The old model, "secure it later," can't keep up anymore. The new one is "engineer it in." And then he said a line that really hit home: compliance was never supposed to be the objective. It was supposed to be evidence of trust.

From there, he described what resilient programs are built on: evidence from the beginning, intentional control inheritance, reusable patterns, and continuous trust.

The convergence

I had to smile, because that list was our talk. Not loosely — almost line for line, just at the strategic level:

Same idea, but two different perspectives of tactics and strategy. Brad described where we need to get to. Our talk, a day earlier, happened to be a working example of just that.

Day 1, from the engineering floor — our closing takeaways.

Day 2, from the main stage — Brad’s markers of a resilient program.

My line to Phillip was half a joke, but there's a serious version of it: you couldn't have scripted it, and that's the whole point. It wasn't luck and it wasn't coordination. It's what happens when a belief is real all the way down — when the person setting strategy and the people implementing tactics are starting from the same place. That's not something you can fake on a conference agenda. Brad's keynote wasn't a wish list. It was a description of how our teams have prepared for the next era of compliance and security.

Why it matters in the AI era

The reason this is more than a coincidence is the moment we're in. AI is compressing everything: how fast systems get built, how fast they change, how fast risk shows up. The natural instinct under that kind of pressure is to treat compliance and security as a tax on speed — something to deal with later so you can move now.

Both talks pushed back on that, and I believe recent events of the last few years have made the argument more concreate. Compliance and innovation aren't opposing forces. The organizations that move fastest are usually the ones with the strongest security foundations, because those foundations are exactly what let them keep moving without stopping to clean up. When everyone is racing to adopt AI, trust turns into one of the most valuable advantages a company can have. And trust is something you engineer, not something you announce.

That's what I walked away from RAMPCon thinking about. The hard part was never getting people to agree that security should be designed in — almost everyone nods at that. The hard part is building an organization where that belief actually holds from the architecture review all the way up to the keynote stage, and then proving it with evidence, over and over.

If your teams are still bolting security on after the design is locked, that gap is the work. It's the work we do at Coalfire every day: helping organizations engineer compliance and trust in from the very first design decision, so authorization becomes something you walk through instead of something you slam into. If that's the shift your program is trying to make, let's talk.