Start with the identities that connect AI-supported workflows to core systems. Look for service accounts, API keys, and delegated permissions that were created for speed but never formally recertified. Those are usually the fastest route from business experimentation to unmanaged access.
Why This Matters for Security Teams
When IT starts using AI to drive business outcomes, the first risk is rarely the model itself. It is the identity sprawl created around the workflow: service accounts, API keys, delegated admin rights, and machine-to-machine trust that were issued quickly to make experimentation possible. Those identities often reach core systems faster than security reviews can keep up, which is why the earliest control point is access, not model tuning. The NIST Cybersecurity Framework 2.0 is useful here because it frames governance around asset visibility, access management, and ongoing risk treatment rather than one-time approval.
NHIMG research on the DeepSeek breach shows how quickly exposed or overly broad AI-adjacent credentials can become a data exposure problem, not just an engineering issue. Security teams should treat every AI-enabled workflow as a new trust path into production systems, especially when business units adopt tools before IAM, PAM, and secrets handling are aligned. In practice, many security teams discover unmanaged AI access only after a workflow has already reached sensitive data, rather than through intentional approval and recertification.
How It Works in Practice
The practical review starts with inventory, then moves to privilege. Security teams should identify which AI-supported workflows touch customer records, finance systems, source code, or operational tooling, then trace the identities used to make those calls. That means looking for long-lived secrets, delegated OAuth grants, and service accounts that can authenticate without a human step-up check. Where possible, map each identity to an owner, a business purpose, and a clear expiration or recertification cycle.
For prioritization, focus on credentials that can do real damage if reused or stolen: cloud API keys, automation tokens, CI/CD secrets, and accounts with write access to orchestration or data platforms. The goal is to separate experimentation access from production authority. Current guidance suggests pairing least privilege with recertification, because static access often outlives the project that justified it. The secrets-management findings in The State of Secrets in AppSec reinforce that fragmented secret storage and weak developer hygiene make this harder than teams expect.
A useful operating sequence is:
- List every AI-supported workflow that reaches a business system.
- Identify the non-human identities behind each workflow.
- Classify secrets by scope, age, and revocation path.
- Revoke unused tokens and recertify active delegated access.
- Move high-value workflows toward just-in-time provisioning and stronger approval gates.
For implementation, teams often benefit from aligning this review with NIST Cybersecurity Framework 2.0 categories for asset management and access control, then folding results into PAM and secrets rotation workflows. These controls tend to break down when AI tooling is embedded inside fast-moving DevOps pipelines because owners cannot clearly distinguish temporary experimentation access from standing production privilege.
Common Variations and Edge Cases
Tighter access review often increases operational friction, so organisations must balance control depth against delivery speed. That tradeoff is most visible when AI systems are used by multiple teams, each with different data sensitivity and change cadence. Best practice is evolving here, and there is no universal standard for which AI identities must be reviewed first beyond the general rule to start with the highest-privilege paths.
Some edge cases need special handling. A read-only analytics assistant may look low risk, but if it can query regulated data at scale, its exposure still matters. A workflow owned by a vendor integration may also be harder to recertify because the actual credential custody sits outside the enterprise boundary. In those cases, treat the external dependency as part of the identity review, not an exception to it. NHIMG’s DeepSeek breach analysis is a reminder that AI-related exposure often begins with overlooked trust relationships rather than a single obvious account.
Teams should also watch for “temporary” access that becomes permanent after launch. If a business outcome depends on AI calling core systems every day, that access is no longer temporary in practice, even if the original ticket said otherwise.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers discovery of non-human identities and overprivileged machine access. |
| NIST CSF 2.0 | PR.AC-4 | Directly maps to managing access permissions for AI-supported workflows. |
| NIST AI RMF | GOV | Supports governance for AI-enabled business use and accountability. |
Inventory AI-related service accounts and secrets, then reduce standing privilege to the minimum required.
Related resources from NHI Mgmt Group
- How should security teams govern machine identity credentials in agentic AI environments?
- How should security teams manage permissions for AI agents?
- How should security teams govern AI agents that use OAuth access?
- How should security teams limit the risk from AI agents that have access to production systems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
