Guard Result Aggregator with Weighted Scoring — lab audio overview

Host: Welcome back to AI Security Engineering. You're in the chapter on prompt injection defense — that's the discipline of stopping attackers from hijacking your language model through cleverly worded input. You work in security engineering, so you already know: defense in depth is the name of the game. This final exercise is where all that theory becomes a production-grade decision engine. Expert: Picture this. You're on a platform team at a mid-sized fintech, maybe thirty engineers, running a customer-facing AI assistant. You've already deployed several independent checkers — small pieces of software that each look at an incoming message and try to spot attacks. One checker looks for known malicious patterns. Another uses a small language model to judge intent. A third scans for suspicious instructions hidden in documents the user uploaded. Each one returns a score, a confidence level, and a verdict. And now you have a problem. What if two checkers say "this is fine" and one says "this is an attack"? What if the fast pattern-matcher is only forty percent sure, but the slower, smarter checker is ninety percent sure? Somebody — or rather, some piece of code — has to make the final call. And that call needs to be fast, auditable, and tunable, because the security team is going to want to adjust the sensitivity without redeploying the whole system. That's the gap this exercise fills. Host: So this is the capstone of the objective. In the previous exercise you built short-circuit logic — the idea that if one fast checker is extremely confident a message is an attack, you block it immediately and skip the slower checkers downstream. Now we're building the other half. What exactly are we constructing here? Expert: You're building the final decision-maker — the piece of code that takes results from multiple checkers and combines them into one verdict: allow, block, or flag for review. And the key idea, the conceptual heart of this exercise, is called weighted scoring. Here's what that means in plain language. Not all of your checkers are equally trustworthy. The pattern-matcher is fast but blunt — it catches obvious stuff but misses clever attacks. The language-model-based checker is slow but subtle — it catches nuanced attacks but occasionally flags harmless messages. So when you combine their opinions, you don't treat them as equal votes. You give each checker a weight — a number that reflects how much you trust it — and you compute a weighted average of their confidence scores. Then you compare that final score against thresholds — numbers you set that say, for example, "above eighty percent, block it; between fifty and eighty, flag it for a human; below fifty, allow it." And crucially, these weights and thresholds live in configuration, not in code, so the security team can tune them as attack patterns evolve. On top of all that, every decision gets recorded as a metric — a numeric data point — that gets sent to Prometheus, which is an open-source monitoring system that lets you build dashboards and alerts. That way you can see, in real time, how your defenses are performing. Host: Alright, before listeners dive in — what's the tricky part? Where do people stumble on this one? Expert: The trap is treating the aggregator as just a math problem. It's not. It's a configuration problem wearing a math problem's clothes. People write beautiful scoring logic, and then they hard-code the weights and the thresholds as fixed numbers inside the function. Six months later, when attack patterns shift and the security team wants to raise sensitivity, there's a code change, a review, a deploy. That's too slow. So watch out for this: as you build, keep asking yourself, "could a security engineer change this behavior without touching the code?" The weights, the thresholds, the list of which checkers feed into the decision — all of those should be read from configuration at startup. The second gotcha is the monitoring piece. It's tempting to treat the metrics as an afterthought, something you bolt on at the end. Don't. The metric labels — the little tags you attach to each data point, like which verdict was issued and which checker contributed most — those labels are what make your dashboards useful later. Think about them up front. Host: Great warning. So let's close the loop. What will listeners walk away able to do? Expert: After this exercise, you'll be able to take raw outputs from a fleet of independent security checkers and turn them into a single, tunable, observable decision — the kind of decision engine that sits at the front door of a production AI system. You'll know how to weight different detectors by trust level, how to expose thresholds as configuration, and how to instrument every decision so your operations team has real visibility. For your team, this is the missing piece that turns a collection of security experiments into an actual defense system — something you can point to in an architecture review and say, "here's how we make the call, here's how we tune it, here's how we watch it." And because this is the final exercise in the objective, when you finish, you'll have a complete, working prompt injection defense system — orchestration, short-circuiting, and weighted aggregation — a reference implementation you can bring back to your team's security architecture discussions. Good luck, and thanks for listening.