Codifying Trade-offs: Security, Cost, and Compliance as Agent Guardrails

Every agent demo ends the same way: the agent does the thing, the audience claps, nobody asks what happened to the security review.

I didn’t just theorize about codifying trade-offs. I built an open-source multi-agent system that does it. Git-Ape (github.com/Azure/git-ape) is a platform engineering framework where specialized agents plan, validate, and deploy Azure infrastructure — and where nothing reaches production without passing through explicit guardrails enforced by the system itself.

Here’s how it actually works. A requirements gatherer agent interviews the human. A template generator produces infrastructure-as-code. Then, before anyone confirms anything, a security analyzer runs a blocking gate — deployment is structurally impossible until issues are resolved. A cost estimator prices the deployment so humans confirm with real numbers, not vibes. A Principal Architect agent runs a Well-Architected Framework review across all five pillars. Only after all of that does a human see the full picture and explicitly approve. After deployment, a drift detector closes the evidence loop: did what we deployed stay the way we deployed it?

The key insight isn’t that we added checks. It’s that we made trade-offs consumable by agents. Security policy isn’t a PDF — it’s policy-as-code that agents evaluate natively. Cost thresholds aren’t guidelines — they’re hard constraints. Compliance isn’t an audit you do later — it’s a gate you pass through now.

I’ll walk through the architecture, the failures that shaped it, and the design principles that transfer to any multi-agent system where the stakes are real. If your agents can deploy but can’t be told no, you don’t have guardrails. You have a demo.