Verify whether the host is managed, what access the machine has, and whether the client can reach sensitive data or credentials. Then decide whether to block, isolate, or formally approve the software through the same workflow used for other unauthorized applications.
What teams should do first when they find an unsanctioned AI client
Start with exposure, not debate. Determine whether the client is running on a managed host, what that machine can reach, and whether the software can access sensitive data or credentials. That first triage tells you whether the issue is merely an unapproved tool or a potentially material access path that needs immediate containment.
Use the same first-pass logic you would apply to any unauthorized application, because the security question is not the label on the software but the reach of the host and the data it can touch. If the client sits on a managed endpoint with broad network access or local secret material, treat it as a higher-priority investigation than a consumer-style tool on an isolated machine.
Where the client is tied to identity-bearing material, the priority is to determine whether it can read, cache, transmit, or reuse secrets, tokens, certificates, or session material. That is the point at which a shadow AI client becomes an access problem, not just an inventory problem, and it should be handled with the same care you would use for any application that could expose credentials or privileged session state.
Why the host and access path matter more than the tool name
An unsanctioned AI client is risky because many clients are built to connect to accounts, APIs, files, browser sessions, and local development tooling. If the host is managed, the device may already be inside a corporate trust boundary, which means the client can inherit far more practical access than its user intended. The key question is whether it can operate as a bridge into sensitive systems or data, even if it was installed casually.
That is why teams should ask what the software can actually do on the machine, not only whether it was approved. A client that can access source code, cloud credentials, chat history, browser-stored tokens, or synced documentation creates a materially different situation from a disposable demo app. At that point, the control decision is about blast radius, containment, and whether the software can remain in place without creating avoidable exposure.
In practice, the same triage also tells you whether the issue can be governed into compliance. Some tools can be moved into an approved workflow if they have a clear owner, known data flows, and acceptable authentication patterns. Others should be blocked or isolated because their operating model depends on broad access that cannot be made safe enough for the environment.
How to choose between blocking, isolating, and approving
The decision should follow the exposure assessment, not a blanket policy reaction. If the client can reach sensitive data or credentials, the safest first move is usually containment while you confirm what it touched and how it authenticates. If the software is harmless but simply unsanctioned, formal approval may be possible, but only after the owner, data handling path, and access pattern are understood.
When teams rush straight to approval, they often miss the real issue, which is that the client may already have been used on a device with privileged access. That is why the workflow should mirror the one used for other unauthorized applications: classify the host, verify the reachable assets, decide on containment, and only then consider whether the tool can be accepted with controls. Shadow AI and AI Agent Discovery Guide is useful here because the discovery step is inseparable from the governance decision.
If the client’s behaviour suggests autonomous or semi-autonomous use of accounts, prompts, or tool access, the review should be stricter than for a simple productivity app. That pattern can create hidden data movement, excessive permissions, or uncontrolled external calls, especially when users connect it to work accounts without understanding what is being shared. For threat framing, the MITRE ATLAS Guide helps teams think about abuse of AI systems as an attack surface rather than a novelty.
Risk and Threat Considerations
An unsanctioned AI client can turn a normal workstation into an unintended data exfiltration path, especially when it can see browser sessions, local files, or development secrets. The risk is not limited to the client itself, because the practical exposure comes from the host’s existing access and the user’s habit of pasting or syncing sensitive material into it.
Failure mechanism: The client inherits the host’s trust context, then reads, forwards, or reuses information that was never meant for an external AI service or an unmanaged plugin chain.
Impact: Sensitive data, credentials, or internal content can leave the environment without a clear audit trail, and the machine may need investigation, containment, or credential rotation depending on what the client could access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Unauthorized AI clients often inherit risky account and access conditions. |
| Recommendation — Review and restrict local and connected accounts before allowing the client to remain in use. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The question hinges on how much access the client and host can reach. |
| AU-6 — Audit Review, Analysis, and Reporting | Teams need visibility into whether the client touched sensitive data or credentials. | |
| Recommendation — Limit the client's reachable resources to the minimum necessary. Review logs to determine what the client accessed before containment or approval. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | AI clients commonly connect through tokens and app auth flows that can be abused. |
| Recommendation — Validate client authentication and revoke compromised tokens or sessions. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The discovery question focuses on whether the client can reach sensitive credentials. |
| Recommendation — Hunt for exposed secrets and rotate any credentials the client could access. | ||
Practitioner Guidance
What to verify: Confirm whether the client is installed on a managed endpoint, whether the user had elevated access, and whether any browser sessions, API keys, or local secrets were available to the process. If those conditions exist, treat the discovery as an access review, not a simple software inventory event.
Decision rule: If the client could reach credentials or sensitive data, contain first and ask whether the software can be approved later under controlled use; if it cannot, remove or block it and investigate for any data exposure that may already have occurred.
Practitioner takeaway: The right first move is to map the client’s real blast radius. Approval is a governance outcome, but containment depends on whether the software had a path to data, credentials, or other trusted resources.