What AI Control Points Actually Govern

An IAM practitioner's guide to the nine enforcement locations that determine whether an AI system is actually governed

An AI agent with access to a CRM, a code executor, and an email API can exfiltrate customer data, deploy malicious code, and launch phishing campaigns—all without a configuration change, a model exploit, or a single security alert. This isn't a model failure; it's a control failure. Without enforced tool permissions, output validation, and behavioral monitoring, an agent can misuse legitimate capabilities while appearing to operate normally.

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

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