The Baseline Control Set: The Minimum Controls Every AI System Must Have

The objection to any proposed baseline is always the same: who decided these controls and not others? It is a fair question, and the answer determines whether a baseline carries authority or is just one team's preference. The strongest possible answer is that no single party decided — the baseline is the intersection of what the major public frameworks already independently demand. When the OWASP Top 10 for LLM Applications, the OWASP Agentic Security Initiative, the NIST AI Risk Management Framework, the NIST Cybersecurity Framework, and ISO/IEC 42001 are laid side by side, they use different vocabularies and different structures, but they converge on a small core of controls that every one of them requires in some form. That convergence is the baseline. This article names that control set, organizes it into six categories that correspond to the ways an AI system can fail, and shows how each category is demanded by multiple frameworks at once. The point is not to invent a new standard but to distill the agreement that already exists into a list short enough to enforce as a floor.

The selection principle

Before naming controls, fix the rule for what qualifies, because a baseline that grows without a principle becomes the comprehensive plan it was meant to avoid. A control belongs in the baseline if, and only if, two things hold: its absence explains a recurring class of real incidents, and it is demanded in some form by multiple independent frameworks. The first criterion keeps the set tied to actual harm rather than theoretical completeness — a control earns its place by preventing attacks that actually happen, not attacks that could be imagined. The second criterion keeps the set authoritative rather than opinionated — a control that only one framework mentions is a candidate for hardening, not a floor.

This principle has a useful consequence: it makes the baseline defensible against both directions of pressure. When someone argues a control is unnecessary, the answer is that its absence is a documented cause of real incidents and that multiple standards require it. When someone argues an additional control should be mandatory, the test is whether its absence explains recurring harm and whether the frameworks agree — and most proposed additions fail the convergence test, belonging instead to the hardening layer above the floor. The principle is what keeps the baseline both minimal and non-arbitrary, which are the two properties that let it function as an enforceable pass/fail gate rather than a wish list.

Six categories of baseline control

Applying the principle yields a set that organizes naturally into six categories, each corresponding to a distinct way an AI system can fail. First, input and output boundaries: controls that constrain and sanitize what enters the model and what its output is allowed to do, addressing prompt injection and insecure output handling. Second, tool and action boundaries: scoping what an agent is permitted to do, addressing excessive agency — the recurring failure of granting a system more capability than its task requires. Third, retrieval and data boundaries: constraining what a system can read and where its context comes from, addressing data poisoning and leakage. These three are the runtime floor — the controls that govern the system as it operates.

The other three categories form the governance floor. Fourth, identity and access: every agent and every tool call has a verifiable identity and least-privilege access, so authority is attributable and bounded. Fifth, logging and observability: the system records what it did in a form that lets an incident be detected and reconstructed, because an unlogged system is one you cannot defend after the fact. Sixth, human oversight: a defined point at which a human must be in the loop for consequential or irreversible actions, so the system cannot take an unrecoverable step entirely on its own. Six categories, each a failure mode with a matching control — this is the whole shape of the baseline, and its brevity is deliberate, because a floor you cannot remember is a floor you cannot enforce.

How the frameworks converge

The authority of the set comes from showing that the major frameworks already demand each category, in their own terms. The OWASP Top 10 for LLM Applications names prompt injection, insecure output handling, and excessive agency directly — which are exactly the input/output and tool-boundary categories. The OWASP Agentic Security Initiative extends this to multi-step agent behavior, emphasizing constrained tool use and oversight. The NIST AI Risk Management Framework, though structured around govern-map-measure-manage functions rather than specific controls, requires exactly these capabilities: it cannot manage a risk it cannot observe (logging), cannot govern authority it has not bounded (identity and access), and calls explicitly for meaningful human oversight.

The convergence extends to the general-purpose standards. The NIST Cybersecurity Framework's core functions — identify, protect, detect, respond, recover — map onto the baseline: identity and access is protect, logging is detect and respond, and the runtime boundaries are protect. ISO/IEC 42001, the AI management-system standard, requires the organizational controls that make these technical ones stick — defined responsibility, documented controls, and review. The striking result is that five frameworks with different origins, audiences, and structures all demand the same six categories. That is not a coincidence; it reflects that these categories are the irreducible ways an AI system fails, and any framework serious about AI security must address them. The baseline is simply the name for what they already agree on.

Where each control sits

The six categories are not a flat list; they layer, and seeing the layering clarifies how they compose into defense in depth. At the data layer sit retrieval and data boundaries — controlling what enters the system's knowledge. At the model-interaction layer sit input and output boundaries — controlling the exchange with the model itself. At the action layer sit tool and action boundaries and the human-oversight gate — controlling what the system is allowed to do in the world. And spanning all layers sit identity and access and logging — identity because every layer's actions must be attributable, logging because every layer's behavior must be observable. This is why the set is minimal but not shallow: five of the six categories address a specific layer, and two of them cut across all layers because attribution and observability are properties the whole system needs.

The layering also explains why the baseline is genuinely defense in depth rather than a single wall. An attack that slips past the input boundary still meets a tool boundary that limits what it can do; an action that clears the tool boundary still hits the human gate if it is irreversible; and whatever happens, identity makes it attributable and logging makes it visible. No single control is assumed to be perfect — the boundaries can be bypassed, the gate can be misconfigured — but the collective structure means an attacker must defeat several independent controls at different layers to cause serious harm, and the baseline's absence is precisely the condition where defeating one is enough. The floor is not a wall; it is a set of thin walls at every layer, which is far harder to walk through than a single one.

The control set as a system

Assembled, the six categories wrap an AI system on every side an attacker can approach. Picture the model at the center. Between the outside world and the model sits the input boundary; between the model and its data sits the retrieval boundary; between the model and its effects on the world sit the tool boundary and the human gate. Around the whole thing, identity attributes every action to a bounded principal, and logging records every action for detection and reconstruction. An attacker trying to reach a consequential effect must pass the input boundary, operate within the retrieval boundary, stay inside the tool boundary, and — for anything irreversible — get past a human, all while being attributed and logged. That is the baseline: not a single defense but an enclosure.

The systemic view also makes the baseline's completeness claim precise and honest. It does not claim to stop every attack; it claims to close the approaches that dominate real incidents. Each category corresponds to an entry an attacker actually uses — a malicious input, a poisoned document, an over-broad tool grant, an unlogged action, an unrecoverable step taken without oversight. Closing all of them removes the easy compromises, which is the whole ambition of a floor. What it deliberately does not do is address the sophisticated, system-specific threats that hardening and threat modeling exist for — those build on the enclosure once it is in place. The control set is the minimum enclosure that turns a system from open on all sides into one an attacker must work to breach, and that transformation is available cheaply, which is exactly why it is the floor.

Keeping the set minimal, and honest limits

The hardest discipline in maintaining a baseline is resisting growth, because every real incident tempts a team to add a control, and a baseline that absorbs every lesson becomes the unenforceable comprehensive plan. The selection principle is the guard: a proposed addition must both explain recurring harm and command framework consensus, and most do not — they are valuable hardening for a specific system, not universal floor. The right home for a system-specific lesson is that system's hardening layer, not the shared baseline. Keeping the floor at six categories is not laziness; it is what keeps it memorable, enforceable, and universally achievable, which are the properties that make it function at all.

Honesty requires stating the limits plainly. The baseline is a set of categories, not a set of implementations — each category can be implemented well or badly, and a poorly-implemented input boundary is a checkbox that provides little real protection, so the baseline's presence is necessary but its quality still matters. The categories are also framed at the level of what must be controlled, not how, because the how is technology-specific and evolves; a baseline that mandated a specific product would ossify. And the convergence argument, while strong, is a synthesis of how these frameworks align rather than a formal proof that these six are exhaustive — a genuinely novel class of AI system might reveal a seventh category, at which point the baseline should grow by exactly one. The set is the current floor, derived from current consensus, held minimal on purpose, and revised only when the evidence and the frameworks both move.

Practitioner Toolkit

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

baseline_categories:
  input_output_boundary:
    owasp: [LLM01_prompt_injection, LLM05_insecure_output]
    nist:  [CSF_Protect]
  tool_action_boundary:
    owasp: [LLM06_excessive_agency]
    nist:  [AI_RMF_Manage]
  retrieval_data_boundary:
    owasp: [LLM08_vector_weakness, data_poisoning]
  identity_access:
    nist:  [CSF_Protect]
    iso:   [42001_access_control]
  logging_observability:
    nist:  [CSF_Detect, AI_RMF_Measure]
  human_oversight:
    nist:  [AI_RMF_Govern_meaningful_oversight]

Glossary

Baseline control set

The minimum categories of control every AI system must have before production, derived from framework convergence.

Input/output boundary

Controls that constrain what enters the model and what its output is permitted to do, addressing injection and insecure output handling.

Tool/action boundary

Scoping of what an agent may do, addressing excessive agency — more capability than the task requires.

Retrieval/data boundary

Constraints on what a system can read and where its context comes from, addressing poisoning and leakage.

Identity and access

Verifiable identity and least-privilege access for every agent and tool call, making authority attributable and bounded.

Logging and observability

Recording the system's actions so an incident can be detected and reconstructed.

Human oversight gate

A defined point where a human must be in the loop for consequential or irreversible actions.

Framework convergence

The agreement of independent standards on the same core controls, which gives the baseline its authority.

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. ISO/IEC 42001, AI Management System (2023)
7. MITRE ATLAS (Adversarial Threat Landscape for AI Systems)