They should do both, but adoption usually improves when approved tools arrive first. If security only blocks shadow usage, developers will route around the controls. A practical programme combines a safe catalog, clear policy boundaries, and enforcement for high-risk tools so the secure path is also the fast path.
Why “approved first” usually works better than “enforce first”
Security teams usually get better adoption when they make the safe path easier before they tighten the unsafe one. If developers can reach an approved tool quickly, they are less likely to bypass policy just to stay productive. That does not mean enforcement is optional, it means approval, usability, and guardrails need to move together.
The core issue is behaviour, not just control design. People route around friction when the sanctioned option is slow, vague, or incomplete. A good programme treats approved tools as the default path for ordinary work and reserves hard enforcement for tools, workflows, or capabilities that create unacceptable risk.
That balance is especially important when AI tools can touch code, data, prompts, connectors, or credentials. The more autonomy and access a tool has, the more important it is to define what is approved, what is restricted, and what requires review before use.
What the secure path needs to include
A useful approved-tool programme is more than a list of vendor names. It needs a catalog that tells users which tools are allowed, what data they may process, which integrations are permitted, and which use cases are out of bounds. If the catalog does not answer those questions, it will not reduce shadow usage.
Policy boundaries should be concrete enough to guide day-to-day decisions. Teams need to know whether an AI assistant may read source code, whether it may handle customer data, whether it may call external APIs, and whether it may retain conversation history. Ambiguity pushes users back to unsanctioned tools because they want a faster answer than security is giving them.
Enforcement still matters, but it should target the highest-risk cases first. If a tool can exfiltrate sensitive data, execute code, or operate with broad permissions, security should block or tightly constrain it rather than trying to socialize risk away. In practice, AI Security Platform Buyer’s Guide is useful because it frames tool evaluation around guardrails, governance, and PoC checks rather than name-only approval.
Where teams get the balance wrong
The most common failure is assuming that blocking unsanctioned usage will automatically create compliant usage. It usually does not. Users may fall back to personal accounts, browser-based AI services, unmanaged plugins, or copied snippets that sit completely outside the intended control plane.
Another mistake is approving tools without real operating boundaries. A tool that is “approved” but not scoped, monitored, or revocable can create a false sense of safety. Approval is only useful when it comes with enforceable settings, ownership, and a clear rollback path if the risk profile changes.
A third failure is treating enforcement as a one-time event. Tool ecosystems change quickly, especially in AI. New features, connectors, model updates, and agent capabilities can move a previously acceptable tool into a higher-risk category without changing the brand name on the login screen. That is why the approval process has to be continuously refreshed, not just published once.
Risk and Threat Considerations
When security only blocks, the main risk is shadow adoption: users keep working, but outside visibility, logging, and policy control. That increases the chance of sensitive data exposure, unsafe integrations, and unmanaged access paths, while also making incidents harder to investigate.
Failure mechanism: Friction in the sanctioned path drives users toward consumer AI, personal accounts, or unofficial connectors, which bypass review, logging, and data handling rules.
Impact: The organisation loses control over where data goes, which tools can touch it, and how quickly it can be contained if the tool or account is later compromised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Approved vs blocked AI tools hinges on tool access and misuse risk. |
| ASI02 — Tool Misuse | The question is about choosing safe tool paths over unsafe usage. | |
| Recommendation — Restrict agent and tool permissions to the minimum approved scope. Limit tools to sanctioned actions and monitor for unsafe tool invocation. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Approved AI tools must not retain excessive access when enforcement starts. |
| Recommendation — Reduce permissions before broad rollout and remove excess access quickly. | ||
| CIS Controls v8 | CIS-5 — Account Management | Approved tools and enforcement both depend on controlling which accounts may use them. |
| CIS-16 — Application Software Security | Safe AI tools need secure selection, testing and controlled deployment. | |
| Recommendation — Centralise account governance for sanctioned AI tools and revoke unsanctioned access. Validate approved tools before deployment and remove risky capabilities. | ||
Practitioner Guidance
What to prioritise: Start with a minimal approved catalog for the most common use cases, then pair it with explicit restrictions for high-risk data and high-risk actions. The goal is to make the compliant route obvious enough that users do not need to improvise.
Decision rule: If a tool can access code, secrets, customer data, or production-connected workflows, treat approval as a controlled onboarding decision, not a casual preference. If it cannot be safely bounded, do not “approve and hope” while waiting for enforcement to catch up.
What good looks like: Users can quickly tell which tool to use, security can explain why, and exceptions are visible rather than informal. Enforcement then becomes a backstop for genuinely risky cases, not the only thing standing between the organisation and shadow usage.
Practitioner takeaway: Security teams should optimise for secure adoption first, then enforce the boundary where the risk justifies it, because usable approval is what prevents policy from becoming a bypass incentive.
Related resources from NHI Mgmt Group
- How should security teams stop AI agents from using approved tools to exfiltrate data?
- What should teams prioritise first when aligning AI RMF with existing security programmes?
- How should security teams prioritise exposure cleanup when AI tools find more issues than they can fix immediately?
- How should security teams evaluate AI penetration testing tools for real-world coverage in developer-first environments?