What breaks when AI controls can only discover, not enforce?

Why This Matters for Security Teams

When AI controls stop at discovery, security teams gain inventory but not operational authority. That means they can see which models, agents, and integrations exist, yet they cannot reliably stop unsafe prompt handling, restrict tool invocation, or separate regulated data flows from general-purpose use. The result is a governance gap, not a monitoring gap. NIST’s NIST Cyber AI Profile (IR 8596) is useful here because it frames AI risk as something to manage across the full lifecycle, not only detect after the fact.

This matters most in environments where AI is already embedded into customer service, development, analytics, and internal workflow automation. Discovery can tell a team that an LLM endpoint exists, but it cannot distinguish whether that endpoint is being used for benign summarisation or for processing sensitive records. It also cannot prevent an agent from calling a high-risk tool once it has been authorised. Without enforcement, policy becomes advisory, and the control plane remains one step behind the data plane.

In practice, many security teams encounter the failure only after sensitive prompts, secrets, or regulated records have already moved through an AI workflow, rather than through intentional control design.

How It Works in Practice

Effective AI control requires more than identifying where AI is present. It needs decision points that can allow, deny, route, redact, or escalate based on the sensitivity of the request, the identity of the caller, and the risk of the action being taken. Discovery answers “what exists,” while enforcement answers “what is permitted now, under these conditions.” That distinction becomes critical in agentic ai, where an AI agent can chain tool calls, retrieve data, and trigger downstream actions with execution authority.

A practical implementation usually combines policy, identity, and telemetry:

• Classify prompts, outputs, and retrieved context before they reach the model.
• Enforce least privilege on tools, connectors, and runtime credentials.
• Route sensitive requests to approved models, isolated environments, or human review.
• Log model, agent, and tool actions so security teams can correlate usage with policy decisions.
• Block or degrade high-risk behaviour such as external data exfiltration, unsafe code execution, or unauthorised data retrieval.

This is where guidance from the OWASP Top 10 for Large Language Model Applications and the MITRE ATLAS framework becomes useful. OWASP highlights prompt injection, data leakage, and insecure tool use, while ATLAS helps teams think about how adversaries manipulate model behaviour and AI workflows. For identity-linked controls, that often means binding AI actions to strong authentication, workload identity, and short-lived credentials rather than static secrets.

Where mature enforcement exists, teams can apply different policies to different classes of data, users, and agents. For example, a general summarisation assistant may be allowed to process public content, while a finance workflow must reject unclassified prompts and require approved retrieval sources. The control point should sit close to the action, not just at the point of discovery. These controls tend to break down when AI is embedded in loosely governed SaaS plugins and unmanaged agent frameworks because policy cannot reliably inspect or mediate every downstream tool call.

Common Variations and Edge Cases

Tighter enforcement often increases friction, latency, and support overhead, requiring organisations to balance security assurance against user productivity. That tradeoff is especially visible in fast-moving AI programs where business teams want broad experimentation but security teams need auditable boundaries.

Best practice is evolving for agentic AI, and there is no universal standard for this yet. Some organisations begin with soft controls, such as alerting and approval workflows, then gradually move to hard enforcement once they understand normal usage patterns. Others enforce by environment, allowing experimentation in lower-risk sandboxes while requiring strict controls in production. Both approaches can work if the policy is explicit and measurable.

Edge cases usually appear where multiple systems share the same model or agent layer. A single AI service may support internal search, customer support, and regulated decision support, but each use case may have different data handling rules. In those environments, discovery alone is misleading because one inventory entry hides several distinct risk profiles. The same problem appears with shadow AI, vendor-managed copilots, and embedded agent features inside business applications, where the team may know the tool exists but cannot directly govern its behaviour.

Current guidance suggests the strongest programmes treat enforcement as the real control objective and discovery as an input to it. That is the practical test: if policy cannot stop, reroute, or constrain the interaction, it is not yet governance. For broader control mapping, see NIST’s AI risk guidance and the NIST AI governance work that emphasises managed AI lifecycles rather than passive visibility alone.

Related resources from NHI Mgmt Group

• What breaks when AI gateways do not enforce consistent controls across LLM and MCP traffic?
• What breaks when AI gateway controls are treated like ordinary API security?
• What breaks when AI agents are governed only with NHI and IAM controls?
• What breaks when organisations rely only on native AI safety controls?