Security teams should start with discovery, not questionnaires. Build an inventory of AI vendors, tools, and agents from browser, endpoint, OAuth, and SaaS data. Then map what sensitive data each tool can reach, score risk by exposure and access scope, and enforce controls that can block, redact, or revoke access when use is unapproved or no longer needed.
Why This Matters for Security Teams
AI third-party risk management breaks down when security teams assume procurement lists are the same as actual usage. Employees can adopt copilots, browser extensions, standalone chat tools, and embedded AI features without formal approval, which means sensitive data may leave the organisation before any vendor review occurs. The real risk is not just the vendor itself, but the combination of opaque data flows, overbroad permissions, and weak visibility into who is using what.
That makes traditional questionnaires necessary but insufficient. A better starting point is discovery across browser telemetry, endpoint signals, OAuth grants, and SaaS logs, then pairing that with data sensitivity and access scope. The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams toward governance, identification, protection, detection, and response rather than treating third-party review as a one-time procurement exercise. For AI tools, the control question is not only “Is the vendor approved?” but also “What can the tool see, store, reuse, or transmit?” In practice, many security teams encounter this only after a sensitive document or prompt history has already been shared with an unvetted AI tool.
How It Works in Practice
Effective AI third-party risk management in shadow-IT environments is continuous and control-driven. Security teams should treat AI usage like an access problem, a data exposure problem, and a supply chain problem at the same time. Discovery should identify the tool, the user, the authentication method, the data types involved, and whether the tool has standing access to inboxes, files, code repositories, or tickets.
From there, the assessment should rank risk by practical exposure, not by marketing claims. A low-friction note-taking assistant that never receives sensitive content is not the same as an AI agent with OAuth consent to read mail, create tickets, or execute actions in SaaS platforms. The OWASP Non-Human Identity Top 10 is highly relevant because many AI tools function through tokens, service accounts, or delegated access that behaves like an NHI even when the business sees only a “productivity app.”
Operationally, strong programmes usually combine these steps:
- Inventory AI tools from browser, endpoint, SaaS, and identity logs.
- Classify the data each tool can reach, especially secrets, customer data, source code, and regulated records.
- Review OAuth scopes, API keys, service accounts, and extension permissions for excessive access.
- Set allow, monitor, redact, or block actions based on business risk and data sensitivity.
- Revoke access automatically when the tool is unapproved, stale, or no longer needed.
Security teams should also align control design to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access enforcement, audit logging, configuration management, and incident response. These controls tend to break down in highly decentralised SaaS-heavy environments because permissions are granted outside central identity workflows and revoked only after business users have already embedded the tool into daily operations.
Common Variations and Edge Cases
Tighter AI third-party controls often increase friction for employees, so organisations have to balance speed and flexibility against data loss and compliance exposure. That tradeoff is especially visible in engineering, sales, and marketing teams, where users adopt tools first and ask for approval later.
Current guidance suggests that best practice is evolving toward tiered controls rather than blanket prohibition. For low-risk use cases, monitoring and redaction may be enough. For tools that touch customer data, credentials, or production systems, stronger controls such as blocked access, scoped service accounts, and mandatory security review are more appropriate. There is no universal standard for this yet, but the pattern is clear: risk should drive the approval path, not the other way around.
The hardest edge cases are AI tools embedded in approved SaaS platforms, because the vendor may be sanctioned while the AI feature itself changes data handling, retention, or model training terms. In those situations, third-party risk teams should review contract language, data residency, subprocessor disclosures, and whether the AI capability can be disabled at tenant level. The identity angle matters here too, because delegated access and stale tokens can keep unapproved tools active long after the original user has moved on. Best practice is to use strong identity governance, continuous monitoring, and clear revocation triggers rather than relying on annual reviews alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Third-party AI use needs ongoing governance and oversight, not one-time procurement review. |
| OWASP Non-Human Identity Top 10 | NHI-01 | AI tools often rely on tokens and delegated access that behave like non-human identities. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege limits what shadow AI tools can access if they appear outside procurement. |
Inventory AI tokens, service accounts, and delegated grants with the same rigor as other machine identities.
Related resources from NHI Mgmt Group
- How can IAM and security teams reduce third-party risk from AI-enabled SaaS tools?
- How should security teams use AI in third-party risk management without over-automating decisions?
- Why does AI change third-party risk management for IAM and NHI teams?
- How should security teams implement automated third-party risk mitigation without losing governance control?
