SafeBreach’s Evolution into an AI-First Development Team: Part 5

When we began our “AI-First” journey at SafeBreach, we viewed it primarily through the lens of the development lifecycle. Our goal was to redefine the role of the engineer, moving from manual coding to a more disciplined role as a system architect and validator.

Over the first four parts of this series, we’ve documented the foundational pillars of this transformation:

• Part 1: We defined what AI-First actually means—a “do-or-die” shift where engineers become the reviewers and approvers of AI-generated work, rather than just the authors.
• Part 2: We explored the operational workflow required to standardize AI usage across a global team, ensuring that speed never comes at the expense of quality.
• Part 3: We discussed the resurgence of the Product Requirements Document (PRD) as the essential “control surface” to eliminate ambiguity, prevent model drift, and control intent.
• Part 4: We examined how Test-Driven Development (TDD) acts as the ultimate safety net, using automated tests to validate that AI-generated implementations align perfectly with our intent.

But as we’ve progressed in this journey at SafeBreach, one thing became increasingly clear: the transformation to AI-First does not stop at the development team. It extends to every function that produces structured output and those functions often face many of the same AI-based challenges: hallucinations, “vibe-based” outputs, and the need for human accountability. And in many ways, the stakes get higher the closer you get to the customer.

In this fifth installment, we’re stepping outside the development team to see how these principles are being applied throughout our organization and, specifically, within the SafeBreach Customer Success team. I sat down with Andrew Kozma, leader of the SafeBreach Technical Account Manager (TAM) team, and Brady Cotton, a SafeBreach TAM, to discuss how they’ve adapted our AI-First discipline to create the Anti-Hallucination Protocol. This framework ensures that the intelligence we provide to our customers is not just fast, but fundamentally verifiable. It also further proves that whether you are writing code or generating threat intelligence reports, the lesson remains the same: AI doesn’t remove responsibility—it forces us to formalize it.

Same Problem, Different Domain

Yossi

When we talk about AI in development, we worry about bugs and technical debt. What happens when AI enters TAM workflows?

Andrew

The short answer? You get outputs that look extremely authoritative, but are sometimes wrong. In our case, we’re generating things like MITRE ATT&CK mappings, coverage verdicts, and threat intelligence reports.

These go directly to customers and influence real decisions. A fabricated technique ID or a misattributed behavior is not just a mistake—it can send a customer in the wrong direction entirely.

Yossi

So, the same problem as dev—just with higher consequences.

Brady

Exactly. And the root cause is the same. AI is very good at being statistically correct. But statistically correct and factually accurate are not the same thing.

From Vibe Usage to Protocol

Yossi

Let me guess: the first phase looked similar to what we originally experienced. People just started using AI organically on your team?

Andrew

Exactly. We called it “vibe reporting.” Ask a question, get a nice-looking answer, refine it a bit, move on.

It worked… until it didn’t. But I want to be clear—this wasn’t just an ad hoc reaction. The team has been operating with a deliberate philosophy.

One framework we’ve been refining is what we call the 3 I’s: Impact, Influence, and Initiative. It’s how we think about where AI activity should be directed and how the team takes ownership of that work.

We’ve also been using Anthropic’s AI fluency framework as a guide—Delegate, Describe, Discern, and Diligence to think about how we actually engage with AI at each stage of a workflow.

Those two frameworks together are what’s been driving the TAM team forward. Brady’s protocol is a direct product of that thinking.

Brady

That context matters, because the protocol didn’t come from frustration alone. When we began working with AI, the outputs looked great. Clean tables. Confident language. And then we would start digging and wonder: where did this information actually come from?

That’s when I started building what became known as the Anti-Hallucination Protocol. It was originally designed to put guardrails on two specific AI-assisted workflows: a threat actor tactic, technique, and protocol (TTP) mapping project and an attack-scoped coverage assessment project.

Both workflows produced customer-facing outputs. Both had real consequences if something was wrong. They became the proving ground. But as I built the protocol, I realized the underlying pattern applies to any AI workflow where the output influences a real decision.

The Core Principle

Yossi

So what is the core idea?

Brady

It’s actually simple. Claude must never assert a claim it cannot cite. Every output, whether it’s a technique ID, a verdict, or a narrative statement, must be traceable to a tool call or a retrieved source. If that citation doesn’t exist, the claim is not presented as fact. It’s flagged.

Yossi

So instead of trying to eliminate hallucinations completely…

Brady

You make them impossible to hide.

The Two-Layer System

Yossi

You mentioned this works on both sides, AI and human. What does that mean?

Brady

Most people think of this as just a human-in-the-loop framework. But it actually starts earlier.

First, we constrain what the AI is allowed to do before anything reaches a human. Then, we give the human a structured way to review what’s left. The important shift is that humans aren’t hunting for hidden mistakes. They’re reviewing explicitly flagged uncertainty. That’s a very different cognitive load and a much more reliable process.

Making Uncertainty Visible

Yossi

So you’re not forcing everything into correct vs. incorrect.

Brady

Right. We make uncertainty part of the output itself. Every claim carries a confidence state. Verified by a tool call. Inferred from reasoning. Or based on thin sourcing.

The specific labels we use are tuned to these workflows, but the concept is universal. Any AI workflow can define its own confidence taxonomy based on what types of uncertainty matter most in that domain.

And more importantly, it forces action. Anything flagged as uncertain must be reviewed before delivery. The protocol makes that non-negotiable.

Yossi

Interesting, so a possible application of the same concept in the development process might be a guideline to the AI coding agent along the lines of:

If you’re not sure about the correctness or expected output of a code block you wrote, make sure the uncertainty is documented using an inline comment in the code. 

Right?

Brady

Exactly. We are accepting that Claude knows it isn’t always 100% certain, so at least that uncertainty becomes visible and manageable by the developer.

The Human Role (Revisited)

Yossi

This feels very similar to what we discussed with developers. AI doesn’t remove responsibility, it makes it more explicit.

Brady

Exactly. We formalized that through a required sign-off step. Claude produces the output. The TAM must explicitly verify it. And Claude is not allowed to pre-fill that verification.

Yossi

That’s basically saying: you are still accountable—we’re just making it impossible to forget.

The Audit Trail

Yossi

One thing that stood out to me was the evidence log.

Brady

Yes, that’s a required deliverable in every session. Every claim has a traceable record: what was asserted, what source or tool call was used, what data was returned, and what the confidence level is. It’s an audit trail for truth.

The specific implementation is tuned to our workflows. But the concept of a machine-readable audit trail for AI-generated claims? That’s something any team producing AI-assisted outputs for external consumption should be thinking about.

The Big Lesson

Yossi

If I connect this to the previous blogs in this series: 

• The PRD reduces ambiguity
• TDD validates behavior
• This protocol…

Brady

Controls truth.

Andrew

Without it, AI doesn’t just make you faster. It makes you wrong faster.

And that’s exactly why the 3 I’s and the AI fluency framework matter. Impact, Influence, and Initiative tell the team where to focus. Delegate, Describe, Discern, and Diligent tell them how to engage. The protocol is what makes the output trustworthy enough to act on.

Closing

The Anti-Hallucination Protocol started as a solution to a specific problem in TAM workflows. But the pattern it represents is broader:

• Constrain what AI can assert. 
• Surface uncertainty explicitly. 
• Require human sign-off. 
• Maintain an audit trail.

Those four things apply whether you are generating threat intelligence reports, writing engineering specifications, producing compliance documentation, or summarizing customer data. Different domains. Same discipline. Again, it reinforces the idea that AI does not remove responsibility. It forces us to formalize it.

Stay tuned for future installments as we continue to explore our journey and the ways in which we adapt our methodologies, tools, and environments based on lessons learned. Specifically, we’ll share some of the in-house innovations we have created to support our progress and will continue to explore the impact of AI on other disciplines like product documentation, competitive analysis, and more.