Why a Baseline: The 80/20 of AI Security and the Cost of Having No Floor

Ask most teams shipping an AI feature what their security baseline is, and you will get one of two answers: a vague gesture at their cloud provider's defaults, or a genuinely thoughtful list of things they intend to do eventually. Almost no one has a written, agreed, enforced floor — a specific set of controls that must be present before an AI system reaches production, no exceptions. This absence is not a minor gap; it is the gap. The systems that suffer the worst AI security incidents are rarely the ones with a slightly imperfect baseline. They are the ones with no baseline at all — where a prompt injection reached a tool because nothing constrained it, where an over-privileged agent did damage because no one scoped its access, where an incident went undetected because nothing was logged. This article argues that the single highest-leverage move in AI security is the least glamorous one: define a floor. It shows that AI risk follows a Pareto distribution where a handful of boring controls prevent most realistic harm, quantifies what having no floor actually costs, and draws the line between a baseline and the more elaborate frameworks it is often confused with.

The two ways security programs fail

AI security efforts tend to fail in one of two symmetric ways, and naming both explains why a baseline is the remedy for each. The first failure is paralysis by comprehensiveness: a team looks at the full landscape of AI risks — prompt injection, data poisoning, model theft, tool misuse, supply-chain compromise — concludes that a complete program is enormous, and does effectively nothing while planning it. The second failure is sophistication without foundation: a team invests in an advanced capability — a fine-tuned classifier for adversarial inputs, an elaborate red-teaming program — while the basic controls that would stop the common attacks remain absent. Both failures ship systems that are wide open to the attacks that actually happen.

A baseline resolves both because it is deliberately small and deliberately mandatory. Against paralysis, it offers a floor you can actually reach — not the whole program, just the controls you must not ship without — so the team can act instead of planning indefinitely. Against misplaced sophistication, it insists the foundation exists before the advanced work, so effort is spent on the boring controls that prevent common harm before the exotic ones that address rare threats. The baseline is not the ambition of a security program; it is its precondition. Everything sophisticated a team might build later stands on it, and building the roof before the floor is how systems end up impressive and breachable at once.

The 80/20 of AI security

The empirical justification for a baseline is that AI security risk is not uniformly distributed — it follows a Pareto pattern, where a small fraction of controls addresses a large majority of realistic harm. This is not a precise measured constant but a well-observed shape: the attacks that actually befall production AI systems are dominated by a handful of recurring failure modes, and those failure modes are precisely the ones the boring controls address. The OWASP Top 10 for LLM Applications and the OWASP Agentic Security Initiative guidance exist because these failure modes recur; prompt injection, insecure output handling, excessive agency, and inadequate logging show up again and again, not because they are sophisticated but because so many systems have no control against them at all.

The practical consequence is a prioritization rule that inverts the usual instinct. Instead of asking what is the most advanced defense we could build, ask what small set of controls would prevent the most common realistic harm — and build exactly those first. A control that blocks the most frequent attack class is worth more than a sophisticated defense against a rare one, even if the sophisticated defense is more intellectually satisfying. The baseline is the operationalization of this rule: it is the short list of controls that sit at the fat end of the Pareto distribution, the ones whose absence explains most incidents. Getting them in place is not the ceiling of a security program, but it is the steepest part of the risk-reduction curve, and skipping it to build something advanced is optimizing the wrong end of the graph.

What a baseline actually is

Precision matters here because a baseline is routinely confused with things it is not. A security baseline is a fixed, explicit set of controls that every AI system in scope must have before it reaches production — a floor, enforced as pass/fail. Three properties define it. It is minimal: it contains only the controls whose absence would be negligent, not everything that would be nice to have. It is mandatory: a system that lacks a baseline control does not ship, which is what distinguishes a baseline from a recommendation. And it is universal within its scope: every system meets the same floor, so security does not depend on which team happened to care.

The pass/fail nature is the crux, and it separates a baseline from a maturity model or a posture score. A posture score grades how good a system's security is on a continuous scale — useful for tracking improvement, but a system can score poorly and still ship. A baseline asks a binary question: does this system have the mandatory controls, yes or no? A system either clears the floor or it does not go to production. These two artifacts compose — the baseline is the must-have floor, the score is the how-good measure above it — but conflating them is dangerous, because a graded score lets a team feel progress while shipping systems that never cleared the floor. The baseline's whole value is that it is not negotiable and not graded; it is the line beneath which a system is simply not allowed to exist in production.

The cost of having no floor

The argument for a baseline is only as strong as the cost of not having one, so it is worth being concrete about what the absence produces. Without a floor, security becomes a function of individual initiative — some teams implement strong controls, others none, and the organization's real security is set by its weakest system, because an attacker targets the softest entry point. This is the structural problem: without a mandatory baseline, the variance across systems is enormous, and variance is what an adversary exploits. A single unlogged, over-privileged, unconstrained AI system is a foothold regardless of how well-secured its siblings are, and with no floor there is nothing preventing that system from existing.

The cost also compounds over time in a way that makes retrofitting expensive. A control that is cheap to add at design time — scoping an agent's tool access, adding structured logging, constraining a retrieval boundary — becomes costly and disruptive to add after a system is in production and depended upon. Without a baseline enforced up front, controls are deferred, and deferred controls are often never added at all, because the system works and adding security to working software feels like risk without reward. So the absence of a floor is not a static gap that stays the same size; it is a debt that accrues, and the incident that eventually forces the issue costs far more than the baseline would have. The cheapest time to have a floor is before the first system ships; the second cheapest time is now.

Why an imperfect floor beats a perfect plan

A recurring objection is that a minimal baseline is not enough — that real security needs far more than a short list of controls. This is true and beside the point. The baseline is not claimed to be sufficient; it is claimed to be necessary and achievable, which is exactly what a comprehensive plan is not. The systems that get breached are overwhelmingly not the ones with an imperfect baseline — they are the ones with no baseline at all, sitting in the paralysis or sophistication-first failure modes while a comprehensive program is perpetually forthcoming. An imperfect floor that exists prevents the common attacks today; a perfect plan that does not exist prevents nothing.

This is a judgment about effort allocation on a risk-reduction curve, and the curve is steep at the start. The first few controls buy an enormous fraction of the available risk reduction; each subsequent control buys less. So the highest-return use of a limited security budget is to get the whole baseline in place across all systems before deepening any single system's defenses, because a mandatory floor everywhere removes more risk than an excellent ceiling somewhere. The instinct to build the impressive thing is precisely the instinct to resist. A boring, mandatory, universal floor is the highest-leverage security investment available, and its lack of sophistication is a feature — it means it can actually be adopted, enforced, and relied upon, which no comprehensive plan that remains a plan ever can.

What the baseline is not

Guarding against over-claiming is part of making the baseline credible, so it is worth stating plainly what it is not. It is not a complete security program — it is the floor beneath one, and a team that stops at the baseline has done the necessary minimum, not the sufficient maximum. It is not a maturity model — it does not describe stages of increasing sophistication; it describes a single line that is either met or not. It is not a substitute for threat modeling, red-teaming, or the deeper controls each risk deserves — those are the hardening and advanced work that build on the floor. And it is not static — the baseline evolves as the threat landscape and the standards that inform it evolve, so a control that is advanced today may be baseline tomorrow.

The baseline is also not a claim that the listed controls are individually sufficient against a determined attacker. A boundary can be bypassed, a log can be tampered with, a scoped permission can still be misused within its scope. The baseline's value is not that each control is impregnable but that their collective absence is what explains most incidents, and their collective presence removes the easy wins that dominate real-world compromise. It raises the floor from anything-goes to a defined minimum, which is a large and cheap improvement, without pretending to be the ceiling. Holding both of those truths — necessary but not sufficient, high-leverage but not comprehensive — is what keeps the baseline honest and keeps a team from either dismissing it as too little or mistaking it for the whole job.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

baseline_gate:
  mode: pass_fail          # NOT a score — binary
  scope: all_production_ai_systems
  mandatory_controls:
    - scoped_tool_access
    - structured_audit_logging
    - input_output_boundaries
    - retrieval_boundary
    - human_in_the_loop_for_irreversible
    - verifiable_identity
  on_missing_control: block_release   # does not ship
  review_cadence: quarterly           # floor evolves

Glossary

Security baseline

A fixed, explicit set of controls every AI system in scope must have before production, enforced as pass/fail.

Pass/fail floor

A binary requirement — a system either has the mandatory controls or does not ship — as opposed to a graded measure.

Posture score

A continuous grade of how good a system's security is; useful for tracking improvement but not a shipping gate.

Pareto distribution

The pattern in which a small fraction of causes accounts for a large majority of effects — here, a few controls preventing most harm.

Excessive agency

An AI system granted more capability or autonomy than its task requires, a recurring baseline gap catalogued by OWASP.

Maturity model

A description of successive stages of increasing security sophistication — distinct from a single pass/fail baseline.

Retrofit debt

The compounding cost of adding a control after a system is in production rather than at design time.

Weakest-system risk

The principle that an organization's real security is set by its least-secured system, because attackers target the softest entry.

References

1. OWASP Top 10 for LLM Applications (2025)
2. OWASP Agentic Security Initiative, Agentic AI Threats and Mitigations (2025)
3. NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
4. NIST Cybersecurity Framework (CSF) 2.0
5. NIST SP 800-53 Rev. 5, Security and Privacy Controls
6. MITRE ATLAS (Adversarial Threat Landscape for AI Systems)
7. ISO/IEC 42001, AI Management System (2023)