A defense you haven't tested is a hope, not a control. The final discipline of LLM security is treating your guardrails as a system to be measured, attacked, and monitored continuously — because the threat evolves, your application changes, and a defense that worked last quarter can silently rot. This closing post covers red-teaming your own system, operating it in production, and the honest state of the art.
A defense you haven't tested is a hope, not a control. The final discipline of LLM security is treating your guardrails as a system to be measured, attacked, and monitored continuously — because the threat evolves, your application changes, and a defense that worked last quarter can silently rot. Red-teaming, production monitoring, and the honest state of the art.
A governance policy written in a PDF is a suggestion; a policy written as code is a control. The difference between the two is the difference between hoping teams comply and knowing they do, because the policy runs automatically and blocks what violates it. Governance as code applies the lessons of infrastructure-as-code and policy-as-code to AI governance — turning principles into executable, version-controlled, automatically-enforced checks. This post is about making governance something the system does, not something a document asks for.
A policy in a PDF is a suggestion; a policy as code is a control. Governance as code makes policy imperative — version-controlled, executable rules that run automatically at deploy, at runtime, and at registration, failing closed on what matters. What you can encode as gates, and what still needs human judgment.
Assembling a computer-use agent means wiring together perception, grounding, action, and the loop into a system that can reliably (enough) operate software — and doing it with the safety and reliability discipline the previous posts demand. This post covers the architecture of a computer-use agent and places it in the larger story of GUI automation: how it evolves from, and improves on, decades of brittle scripting. It's the practitioner's assembly view.
Assembling perception, grounding, action, and the loop into a system — with reliability and safety wrapping as first-class. The architecture of a computer-use agent, and the evolution from brittle scripted RPA to intelligent, adaptive, natural-language-directed automation (with the determinism trade-off).
Mixture of Experts saves compute but not memory — and that single fact reshapes everything about how these models are trained and served. All the experts must exist in memory even though only a few run per token, which turns MoE into a distributed-systems problem as much as a machine-learning one. This post covers the trade MoE actually makes and the parallelism it forces.
Mixture of Experts saves compute but not memory — and that single fact reshapes everything about how these models are trained and served. All the experts must exist in memory even though only a few run per token, which turns MoE into a distributed-systems problem as much as a machine-learning one. The trade MoE makes and the expert parallelism it forces.
The two D's in CD/CD get used interchangeably, but they name genuinely different practices with different risk profiles and different prerequisites. Getting the distinction right — and knowing which one your system is actually ready for — is the difference between a mature delivery pipeline and a dangerous one. This post draws the line clearly and covers what it takes to cross it.
The two D's in CD get used interchangeably, but they name genuinely different practices with different risk profiles and prerequisites. Continuous Delivery keeps a human approval before production; Continuous Deployment removes it. This post draws the line clearly, covers environment promotion, and helps you decide which your system is actually ready for.
"Guardrails" is the umbrella term for the runtime checks that sit around a model and screen what goes in and comes out — content classifiers, moderation models, topic and format validators, PII detectors. They're a real and useful layer, distinct from the architectural defenses, and they come with their own design rules: layer them, fail safe, and never mistake them for a wall.
"Guardrails" is the umbrella term for the runtime checks around a model — content classifiers, moderation models, topic and format validators, PII detectors. They're a real and useful layer, distinct from architectural defenses, with their own design rules: layer them, fail safe, and never mistake them for a wall. This post covers building the layered defense in practice.
Governing a model that answers questions is hard; governing one that takes actions is a different problem entirely. Agentic AI — systems that plan, call tools, and execute steps toward a goal with limited human oversight — moves AI from producing outputs to producing consequences. The governance frameworks built for predictive models and even for chatbots don't fully cover an agent that can send an email, move money, or modify a system. This post is about the controls that specifically matter when AI can act.
Governing a model that answers is hard; governing one that acts is a different problem — a wrong action escapes into the world. Why agents break the usual frameworks, and the controls that bound authority and consequences: least privilege, human-in-the-loop for consequential actions, bounded execution, agent identity, and fail-safe defaults.
A computer-use agent can do anything a human can do at a computer — which is exactly why it's dangerous. An agent operating your screen can click the wrong irreversible button, be hijacked by malicious content it sees, or take consequential actions you didn't intend. Safety isn't an add-on for computer-use agents; it's a precondition for using them at all. This post is about bounding an agent that's loose on a real computer.
A computer-use agent can do anything a human can at a computer — which is why it's dangerous: broad power, imperfect reliability, and exposure to prompt injection via on-screen content. Why safety is a precondition, and the controls: least privilege, sandboxing, approval gates, injection defense, and a kill switch — containment by design.
The router is where Mixture of Experts succeeds or fails. Left to its own devices, it tends to collapse — sending most tokens to a handful of favorite experts while the rest starve, wasting the model's capacity. Making routing spread load evenly, without hurting quality, is the central engineering challenge of MoE, and the techniques for it are what separate a working sparse model from a broken one.
The router is where Mixture of Experts succeeds or fails. Left alone it tends to collapse — sending most tokens to a handful of favorite experts while the rest starve, wasting the model's capacity. Making routing spread load evenly, without hurting quality, is the central engineering challenge of MoE: load-balancing losses, expert capacity, and token dropping.
The build and test stages are the engine of a pipeline — the part that decides, on every change, whether it's safe to proceed. Get them fast and trustworthy and the whole pipeline flows; get them slow or flaky and the pipeline becomes something developers route around. This post is about designing tests and builds that give a fast, reliable verdict.
The build and test stages are the engine of a pipeline — the part that decides, on every change, whether it's safe to proceed. Get them fast and trustworthy and the pipeline flows; get them slow or flaky and it becomes something developers route around. This post covers the test pyramid, deterministic tests, fail-fast staging, build-once-promote, caching, and parallelism.
Injection defense usually focuses on what goes into the model. But an equally dangerous class of bug lives on the way out: whatever the model produces gets passed to another system — a browser, a shell, a database, another service — that trusts it. If the model can be made to emit a malicious payload, and your code renders or executes it, the injection escapes the model and lands in your infrastructure.
Injection defense usually focuses on what goes into the model, but an equally dangerous class of bug lives on the way out: whatever the model produces gets passed to another system that trusts it. If the model can be made to emit a malicious payload and your code renders or executes it, the injection escapes the model and lands in your infrastructure — XSS, SQLi, SSRF, exfiltration.
Banks have managed the risk of models being wrong for decades, under a formal discipline called model risk management. AI didn't invent the problem of a model that's confidently incorrect — it industrialized it. The good news is that a mature, battle-tested framework already exists, and adapting it to machine-learning and LLM systems is one of the highest-leverage moves in AI governance. This post is about treating "the model might be wrong" as a managed risk, not a hope.
Banks have managed 'the model might be wrong' for decades under model risk management (SR 11-7). Its lifecycle — documented development, independent validation, risk-tiered approval, ongoing monitoring, revalidation/retirement — maps onto AI, which then stresses it with opacity, un-inspectable foundation models, open-ended generation, and scale.