When should organisations block an AI service rather than permit it?

Why This Matters for Security Teams

Blocking an AI service is not just a policy decision; it is a risk containment decision. If a service can ingest secrets, retain sensitive prompts, or operate with unclear telemetry, permission can turn into persistence for an attacker or an ungoverned data path for the business. This is especially important when the service is tied to non-human identity controls, because the identity may be valid while the behaviour is still unacceptable. Guidance from NIST Cybersecurity Framework 2.0 and NHI-focused analysis such as the DeepSeek breach both point to the same practical issue: access decisions must account for data handling, visibility, and retention, not just authentication.

Security teams often get this wrong by treating an AI service like a normal SaaS app with a standard allow or deny decision. Agentic systems and LLM-backed services can call tools, cache context, and reuse credentials in ways that are difficult to predict after approval. If there is no evidence that secrets are compartmentalised, telemetry is complete, and retention is bounded, the safer choice is to block or heavily constrain the service until those controls exist. In practice, many security teams encounter the blast radius only after a prompt leak, shadow deployment, or credential exposure has already occurred, rather than through intentional governance.

How It Works in Practice

Start with a minimum approval gate that checks three things: credential handling, logging visibility, and data retention. If the service cannot prove that secrets are short-lived, prompts are not stored beyond business need, and usage can be monitored end to end, it should not be treated as approved for production. That is consistent with the control logic in NIST Cybersecurity Framework 2.0, which emphasises governance, access control, and continuous oversight rather than one-time trust.

For autonomous or semi-autonomous services, the better pattern is not permanent permission but conditional use. JIT credential provisioning, workload identity, and runtime policy checks let teams issue access only for the task at hand. In agentic environments, static RBAC is often too blunt because the agent’s next action is not fully knowable in advance. Current guidance suggests combining intent-based authorisation with short-lived secrets, so the service can only do what it is trying to do right now, not what it might infer later. That is where controls such as policy-as-code, strong audit logging, and strict token lifetime become operationally useful. The DeepSeek breach illustrates why this matters: once data exposure or secret sprawl is inside the service boundary, removal is far harder than prevention.

• Block first when the service cannot prove where credentials go, how long they live, or who can inspect its telemetry.
• Permit only with constrained scope when the use case is narrow and the service supports JIT or ephemeral access.
• Escalate to full approval only after logs, retention, and secret handling are independently verified.

These controls tend to break down in agentic pipelines that chain multiple tools because one approved step can silently create the next privilege need.

Common Variations and Edge Cases

Tighter blocking often increases friction for product teams, requiring organisations to balance speed of adoption against the cost of investigation and control tuning. That tradeoff is real, especially when the AI service is experimental, business-critical, or provided by a vendor with limited transparency. There is no universal standard for this yet, so best practice is evolving rather than settled.

Some services should be constrained rather than fully blocked. For example, a low-risk internal summariser may be allowed with redacted inputs, no external tool access, and no retention. But if the same service can browse, write, or trigger workflows, the risk profile changes sharply because autonomous behaviour creates unexpected paths for data movement and privilege escalation. In those cases, the question is not whether the service is useful, but whether it can operate under NIST Cybersecurity Framework 2.0 style governance and the NHI controls recommended by DeepSeek breach lessons learned. If it cannot, blocking is a valid security outcome, not a failure to adopt AI.

Related resources from NHI Mgmt Group

• What makes agentic AI an NHI governance issue?
• Why is NHI governance critical in the age of AI attacks?
• How do organisations operationalise NHI ownership at scale?
• Why is single-provider AI agent governance not enough for enterprise security?