Should organisations prioritise containment or discovery in AI security?

Why This Matters for Security Teams

AI security decisions are not just about model quality. They shape whether an AI system can reach data, invoke tools, write to production, or expose secrets through prompts and outputs. In that environment, discovery alone creates a false sense of control because it identifies exposure without limiting what the system can do next. Containment is the faster risk reducer when an agent or LLM has operational reach.

That distinction matters because AI deployments often move from pilot to production before control ownership is fully settled. Security, platform, and product teams may each assume the other is handling guardrails, while the system is already connected to internal APIs or sensitive workflows. Current guidance suggests treating AI as a runtime trust problem, not only a cataloguing problem. For threat modelling and governance context, the CSA MAESTRO agentic AI threat modeling framework is useful because it pushes teams to map tool use, autonomy, and escalation paths rather than stopping at inventory.

In practice, many security teams encounter AI risk only after an assistant has already been granted access to sensitive systems, rather than through intentional design review.

How It Works in Practice

The practical sequence is simple: first identify where the AI system can observe, decide, and act; then restrict those actions; then expand discovery to improve assurance. Discovery answers what exists. Containment answers what can happen now. For AI systems, that usually means classifying prompts, model endpoints, tool integrations, retrieval sources, and output channels by blast radius. A system that can only summarise public content is not in the same risk class as one that can create tickets, approve payments, or query secrets.

Containment typically combines several controls:

• Limit tool permissions to the smallest workable scope.
• Require policy checks before high-impact actions are executed.
• Segregate production, test, and evaluation environments.
• Block direct access to secrets, tokens, and privileged admin functions.
• Log prompts, tool calls, and model outputs for investigation and replay.

Discovery still matters, especially for shadow AI, unapproved model usage, and unknown integrations. But it is most valuable when it feeds control placement. For example, inventorying every assistant in the estate is less useful than knowing which ones can modify records, call external services, or retrieve regulated data. That is why organisations should treat discovery as a map for containment, not as a substitute for it. The Anthropic Project Glasswing material is relevant here because it highlights the operational challenge of securing agentic systems that can take actions, not just generate text.

These controls tend to break down when teams connect agents to broad internal toolchains without per-action approval gates because the system inherits the permissions of the most privileged integration.

Common Variations and Edge Cases

Tighter containment often increases friction, requiring organisations to balance reduced blast radius against slower workflows and more review overhead. That tradeoff is real, especially in customer-facing copilots, developer assistants, and internal automation where users expect immediate results. Best practice is evolving, but there is no universal standard for how much autonomy an AI system should have before stronger enforcement is mandatory.

Some environments justify discovery-first work for a short period, such as early-stage experiments, low-risk summarisation tools, or models with no access to internal systems. Even there, discovery should be time-boxed and paired with an explicit path to containment once the use case expands. In regulated or high-impact settings, waiting for a complete inventory before enforcing guardrails can leave a gap large enough for data leakage, prompt injection, or unsafe tool execution.

Edge cases also appear when AI is embedded inside existing business applications. In those cases, the model may not look powerful on its own, but inherited permissions from the host application can create hidden reach. Security teams should therefore assess the combined behaviour of the application, the model, and the connected identity. Discovery without action controls can miss that compound risk, especially when tool permissions are delegated through service accounts or shared backend identities.

Related resources from NHI Mgmt Group

• Should organisations prioritise discovery or access restriction first for shadow AI?
• Should organisations prioritise remediation or discovery first in SaaS security?
• How should organisations prioritise fixes for AI agent security findings?
• How should security teams prioritise vulnerabilities when AI speeds up attack discovery?