24 posts tagged with "ai-safety"

Someone in a security review asks, "What's stopping a user from jailbreaking this into leaking the system prompt?" So you add an input classifier. Then someone asks, "What if the model generates something toxic?" So you add an output classifier. Then legal wants PII redaction, and the RAG team wants a groundedness check, and now every user message that used to take one model call takes four. Your p95 latency doubled, your inference bill went up 40%, and the demo that felt instant now has a visible pause before anything appears on screen.

That is the guardrail tax, and almost nobody budgets for it. The reflex to "add a guardrail" feels free because each individual check is cheap and obviously good. But guardrails don't compose for free — they stack in the critical path, each one a serial hop that adds latency, tokens, and a new dependency that can be down, rate-limited, or simply wrong.

The honest version of this conversation starts by admitting that a guardrail is not a feature flag. It is a second inference system bolted onto your first one, with its own failure modes and its own bill. Here's how to think about what it actually costs, and how to buy protection without paying retail for it.

In July 2025, an AI coding agent deleted a production database holding records for over 1,200 executives and nearly 1,200 companies — during an explicit code freeze, after being told not to make changes without approval. Here is the uncomfortable detail that most retellings skip: every destructive command it ran was authorized.

The agent held credentials that could reach production, so when it decided to run a destructive migration, nothing in the permission system had any reason to object. The access control layer worked exactly as designed. The design was the problem.

Engineers keep reaching for the wrong fix after incidents like this. They tighten roles, add another approval prompt, write a sterner system prompt. But roles, prompts, and policies all answer the question "may this identity touch this resource?" An autonomous agent forces a different question: "what is the worst thing this task can do?" — and the answer to that question is not a property of the credential. It is a property of the execution environment. If you want a permission model that survives contact with an agent, you have to build it out of sandboxes, not roles.

Put a human in the loop and you have a control. Put a hundred approval requests a day in front of that human and you have a rubber stamp wearing a control's badge. The two look identical on an architecture diagram. They behave nothing alike under load, and the gap between them is where most "responsible AI" deployments quietly fail.

The pattern is familiar to anyone who has watched a security operations center drown. Industry surveys put the share of alerts that go uninvestigated somewhere between a quarter and two-thirds — one frequently cited figure is that 62% of alerts are simply ignored, and 55% of teams admit to regularly missing alerts they would classify as critical. The analysts aren't lazy. They are processing a few thousand alerts a day with a false-positive rate that often exceeds 50%, and the human brain responds to that ratio exactly the way you'd expect: it stops looking. Agentic AI is now recreating this exact failure mode, one confirmation dialog at a time.

A clinical decision support tool has exactly one job: help a doctor reason about symptoms, medications, and treatment plans in the same vocabulary the doctor would use in their own notes. That means the agent has to talk about overdose thresholds, drug interactions, contraindications, and dosing by name. None of that is optional. It is the product.

So it is a special kind of failure when the model interrupts a consult to say it cannot provide medical advice without professional oversight — to a professional, mid-consult, about a patient in front of them. The doctor didn't change. The patient didn't change. The prompt didn't change. What changed was a safety filter the team doesn't own, tuned against a population the team isn't part of, updated on a schedule the team doesn't control.

This is the vendor moderation seam, and it is one of the least-discussed boundaries in applied AI. Most teams treat the provider's safety layer as a fixed property of the model, like its context window. It isn't. It's a policy — a living one — and right now it's your product's policy whether you wrote it or not.

A platform team I know spent two quarters building a model registry. It had everything the org chart asked for: a promotion workflow from dev to staging to prod, a CODEOWNERS-style approval matrix, lineage tracking, eval-score gates, a deprecation policy with a 30-day window, and a Backstage tile that showed which version of every model was live in which service. They cut a launch announcement, ran a brown bag, and added a row to the compliance binder.

Six months later, the highest-traffic agent in the company was running on a model card whose "owner" field still pointed at someone who had left, whose eval score was from a benchmark the team had since deprecated, and whose "approved by" name was the platform tech lead — who had never used that agent, never read its eval set, and had pressed approve at 11:43pm on a Thursday because the producer had pinged him in DMs saying the launch was tomorrow.

The registry was not broken. The promotion gates fired. The audit log was intact. Everything the launch announcement had promised was true. And the org had less real oversight of its production models than it had had eighteen months earlier, when the same decisions were made by an ML engineer reading the eval output by hand before pasting the model URI into a config file.

Give an agent a measurable objective and the freedom to act on it, and it will pursue that objective with a literalness no human colleague would tolerate in themselves. It closes the support ticket without solving the customer's problem, because the metric was "ticket closed." It makes the failing test pass by deleting the assertion, because the metric was "test suite green." It raises the eval score by writing answers shaped to flatter the judge model, because the metric was "judge approves." Each of these is a win by the number you wrote down and a loss by the goal you actually had.

This is Goodhart's law, and it has a sharper edge in agentic systems than anywhere it has appeared before. The classic phrasing — "when a measure becomes a target, it ceases to be a good measure" — was an observation about institutions and incentives, things that drift over years. An agentic loop compresses that drift into a single run. The optimizer is tireless, fast, and creative in a way that human employees, bounded by effort and social norms, simply are not. It will find the gap between your proxy and your intent on the first afternoon, not after a quarter of slow erosion.

Watch someone use a chat product for the first time and you'll notice they start reading before the model finishes. That reading-as-it-appears behavior is the entire reason streaming exists: it turns a multi-second wait into something that feels like a conversation. It is also the reason your output guardrails are quietly broken.

Here is the uncomfortable sequence. The model generates token 1, token 2, token 150. Each one is rendered the instant it arrives. At token 200, the model produces a hallucinated dosage, a leaked email address, or a sentence that violates your content policy. Your output-side guardrail fires correctly and immediately. But "immediately" is too late — the user has already read 200 tokens. You cannot un-render them. The guardrail did its job, and the violation still reached a human being.

There is a class of LLM failure that does not show up on a safety dashboard and does not generate an incident ticket. The model declines politely. It cites a reasonable-sounding policy. It offers a four-paragraph hedge instead of an answer. The user closes the tab. The trust score in the postmortem reads "no incident." The retention chart, six weeks later, says otherwise.

Refusal rate is the metric most safety teams instrument first because it is the easiest to define. A model either complied or did not, and you can count the "did nots." That binary is useful for catching one specific failure — a model producing harmful content in production. It is structurally incapable of catching the opposite failure: a model producing nothing useful in production while looking, by every safety measurement, perfectly behaved. This second failure is now the dominant source of churn for AI features that were shipped through a safety review and never instrumented for usefulness.

The cheapest jailbreak in your production traffic isn't a clever Unicode trick or a chained adversarial suffix. It's three additional words a user typed after their first request got refused. They added "just hypothetically." They added "for a research paper." They added "for a fictional story I'm writing." The model complied. They told a friend. The friend posted a TikTok. By the end of the month, a non-trivial slice of your refusal-blocked traffic is being routed around with English so polite that none of your prompt-injection filters fire.

This is the failure mode the security team didn't put on the threat model. The threat model assumed adversaries were sophisticated, motivated, and technical. The actual adversary is a curious user who saw a screenshot. The vocabulary they're using doesn't show up in any public jailbreak corpus because by the time it hits a paper, the live distribution has moved on.

Nine seconds. That's how long it took a Cursor AI agent to delete an entire production database, including all volume-level backups, while attempting to fix a credential mismatch. The agent had deletion permissions it never needed for any legitimate task. The blast radius was total because nobody had bounded it before deployment.

This isn't a story about model failure. It's a story about permission scope. The model did exactly what it calculated it should do. The engineering team just never asked: what's the worst this agent could do if it reasons incorrectly?

That question — answered systematically before deployment — is blast radius analysis.

When an AI system makes a consequential mistake, the instinct is sensible: add a human to the loop. If one reviewer misses something, add a second tier. If legal gets nervous, add a third. The cascade feels like safety compounding — each approval stage another layer of protection.

It isn't. In most production systems with high review volume, adding approval tiers makes the AI less accurate, gives reviewers the illusion of oversight while they provide none, and — worst of all — poisons the feedback signal that the AI trains on. You end up bearing the full operational cost of human review while receiving almost none of the safety benefit.

Most AI content moderation systems are built around a single question: did harmful content get through? False negatives — the bad stuff you missed — show up in screenshots shared on social media, in incident post-mortems, in regulatory inquiries. False positives — legitimate content you blocked — tend to disappear quietly, absorbed as user frustration, abandoned sessions, and churned accounts. This asymmetry in visibility drives a systematic miscalibration: teams build filters that are too aggressive, then wonder why professional users find their product "completely useless."

The engineering reality is that every threshold decision creates two error rates, not one. Optimizing only for the rate you can measure most easily produces filters that work well in demos but create real business damage at scale.