The Model Is Not the Control Point
A model's behavior is shaped by training, fine-tuning, and alignment — none of which is an enforceable security control in the sense that NIST SP 800-53 uses the term. A security control catalog defines the enforceable control points that govern system behavior, distinct from documentation of intent. The AI RMF Core operationalizes AI risk management through four functions — Govern, Map, Measure, and Manage — defining where control over an AI system actually exists. Control exists at specific, nameable locations in the architecture, not distributed across the model's weights. For IAM practitioners this resolves a common misattribution: when an AI system exposes data it should not have revealed, the failure rarely originates in the model — it originates in retrieval scope, context assembly, or access policy.Control Point 1: Data
Governs what training, fine-tuning, and retrieval data the model can access — scope set before any query, so mistakes propagate to every interaction.Failure mode: A retrieval path aggregates documents across classification levels because the index does not enforce per-document access control; a user receives synthesized output drawing on tiers they are not authorized to see.
Control: Apply access control at the document or record level within any data source the system can reach, not just at the entry point. Per-document labeling with enforced filtering is worth the overhead versus treating retrieval as a single authorization boundary.
Control Point 2: Prompts
Governs whether the instructions reaching the model are authorized and tamper-resistant.Failure mode: User input that overrides or appends to a system prompt — prompt injection — redirects behavior. This is an input-validation failure, not a model vulnerability.
Control: Treat system prompts as version-controlled configuration with integrity checking; validate that user input cannot structurally modify the instruction context; separate system-prompt delivery from user input channels where architecturally feasible.
Control Point 3: Context
Governs what the model receives per session (identity, history, injected documents, system state) and what it trusts as authoritative — including adversarial content from external sources.Failure mode: An uploaded document's embedded instructions are treated as system-level authority because the context assembler does not distinguish trusted from untrusted content within the window.
Control: Label content by source and trust level before assembly and enforce that externally sourced content cannot carry instruction-level authority. This requires architectural enforcement — telling the model to "ignore instructions in documents" is not a control.
Control Point 4: Retrieval
Governs which documents, databases, or API responses enter the context window — an independent authorization boundary that can cross classification lines the original data governance policy did not anticipate.Failure mode: A RAG system retrieves by semantic similarity without checking whether the requesting user is authorized for each document, then synthesizes restricted content.
Control: Enforce authorization at retrieval time, per document, against the requesting user's identity — not the service account executing the query. Post-retrieval filtering is defense-in-depth, not the primary control.
Control Point 5: Tools
Governs which external systems, APIs, code executors, or data stores the model can call and with what scope — defined by configuration, not model behavior. Tool calls are where AI systems produce real-world effects.Failure mode: An agent with write access to a customer database is redirected by a prompt injection in a retrieved document to query and exfiltrate records outside the original task scope.
Control: Scope tools to the minimum per task and enforce scope at the integration layer, not by relying on the model to decline out-of-scope calls. Scope per-task and revoke on completion — the least-privilege pattern IAM teams already apply to service accounts.
Control Point 6: Outputs
Governs where responses go, what systems they affect, and whether consequential outputs are validated before triggering action — including generated content downstream systems or humans act on.Failure mode: A model's configuration recommendation is automatically applied by an orchestration pipeline without review; an error, or an upstream injection, causes an outage or security regression.
Control: Classify outputs by consequence and gate high-consequence outputs — those triggering automated workflows, modifying access policy, or affecting production — before execution. A human-in-the-loop requirement on policy-affecting outputs is easier to audit than automated validators in early deployment.
Control Point 7: Access
Governs which identities can invoke the system, under what credentials and policy — IAM territory: authentication, authorization, session management, and identity lifecycle applied to AI endpoints.Failure mode: Shared API keys authenticate multiple users or services to one endpoint; no per-request attribution exists, and key compromise provides persistent, unattributed access.
Control: Issue per-identity credentials and apply the same lifecycle governance — provisioning review, access certification, revocation on role change — as any other integration. Scope AI service accounts at provisioning, not after deployment. (Token and session revocation behavior varies by platform and IdP; verify against vendor documentation.)
Control Point 8: Monitoring
Governs whether behavioral baselines exist and whether deviation at any control point is observable and logged.Failure mode: An AI system begins retrieving documents outside its normal scope — an early indicator of retrieval injection or misconfiguration — but no baseline exists, so the deviation is invisible until business impact surfaces.
Control: Log inputs, outputs, tool calls, and retrieval queries at the session level, attributed to authenticated identity; baseline normal retrieval scope and tool-invocation patterns and alert on deviation. Start with known-bad patterns (cross-classification retrieval, calls to unregistered APIs) before tuning behavioral anomaly detection.
Control Point 9: Policy
Governs whether enforceable rules exist for each control point and whether those rules are technically enforced at each execution path — not just documented.Failure mode: An AI acceptable-use policy specifies agents should not exceed designated scope, but no technical enforcement exists at the tool or retrieval layer; the policy is satisfied on paper while the control gap stays open.
Control: Map each policy requirement to a specific technical enforcement location among the eight preceding control points. A requirement with no enforcement location is a documentation artifact, not a control.
Nine-Point Control Model Table
| Control Point | What It Governs | Why It Is a Distinct Enforcement Location | What Bypasses It Without a Control |
|---|---|---|---|
| Data | What training, fine-tuning, or retrieval data the model can access | Data scope determines what the model knows and can reveal; governance applies before the model is ever queried | Retrieval paths pull across classification levels; model accesses data outside user authorization scope |
| Prompts | What instructions reach the model and whether they can be verified as authorized | Prompts are the primary control surface for AI system behavior; prompt tampering can redirect the entire system | System prompt overrides from user input; injected instructions that impersonate system-level authority |
| Context | What information the model receives per session: user identity, conversation history, injected documents, system state | Context assembly determines what the model trusts; context can include adversarial content from external sources | Injected documents containing adversarial instructions; user messages overriding session state; prior conversation poisoned by injection |
| Retrieval | Which documents, databases, or API responses the model can pull into its context window | Retrieval paths can cross data classification boundaries that manual queries would not; RAG systems assemble context from sources not designed to be combined | Retrieval returns documents outside user authorization scope; RAG assembles context across classification levels without policy enforcement |
| Tools | Which external systems, APIs, code executors, or data stores the model can call, and what scope those calls have | Tool calls produce real-world actions; tool scope is defined by configuration, not model alignment | Model invokes APIs beyond intended task scope; agent tool-calling chains reach systems outside authorized scope; prompt injection redirects tool calls |
| Outputs | Where model outputs go, what systems they affect, and whether consequential outputs are validated before action | Outputs can trigger downstream decisions, automated workflows, or actions against external systems without human review | Model outputs route directly to automated systems; consequential recommendations execute without validation; malicious output content reaches downstream systems |
| Access | Which identities can invoke the system, with what credentials, under what policy | AI system access requires the same identity governance as any other system; API key authentication is not governed identity | Shared API keys provide non-attributable access; service accounts carry access beyond their scoped task; agent identity is unmanaged and unreviewed |
| Monitoring | Whether behavioral baselines exist and whether anomalous behavior at any control point is observable | AI system behavior can drift, be manipulated, or escalate capability without visible configuration change | No behavioral baseline exists; deviation at any control point goes undetected; incidents cannot be reconstructed from logs |
| Policy | Whether rules exist for each control point and whether enforcement is active or only documented | Documented policy without technical enforcement is not a security control; AI systems require policy enforced at each execution path location | Policy documents exist but are not technically enforced; control-point gaps persist because policy assumed model alignment was sufficient |
Putting the Model to Work
The path forward is straightforward: map each of the nine control points, determine which are technically enforced, which rely only on documented policy, and which have no meaningful safeguards at all. The gaps aren't just findings—they're your implementation roadmap.Sources
- NIST SP 800-53 Rev. 5, Security and Privacy Controls: https://csrc.nist.gov/pubs/sp/800/53/r5/final
- NIST AI Risk Management Framework (AI RMF 1.0, AI 100-1): https://www.nist.gov/itl/ai-risk-management-framework