AI tools expand the attack surface because developers can introduce models, assistants, and AI dependencies outside standard procurement and security review. This creates blind spots around data exposure, policy compliance, and insecure generated code. Organisations need controls that identify where AI is used, what data it touches, and whether it aligns with approved standards and risk appetite.
Why This Matters for Security Teams
AI coding assistants and third-party models change the control problem from “who approved this tool” to “what can this tool touch, generate, and exfiltrate at runtime.” In development pipelines, the risk is not limited to insecure code suggestions. It also includes prompt leakage, hidden dependency injection, secret sprawl, and policy drift when teams adopt assistants without security review. That is why the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0 both matter here: the issue is identity, access, and governance around machine-to-machine activity, not just application security.
NHIMG research shows how quickly AI-adjacent compromise can escalate once secrets enter the ecosystem, including the patterns seen in the Guide to the Secret Sprawl Challenge and the LiteLLM PyPI package breach. In practice, many security teams encounter model-related exposure only after tokens, prompts, or generated code have already been committed into pipelines and downstream systems.
How It Works in Practice
Governance risk appears when AI tools are introduced outside normal procurement, software composition, and secrets management workflows. A coding assistant may be approved by an individual developer, but it still acts like a non-human identity with data access, network reach, and sometimes plugin or repository permissions. If that identity is not inventoried, classified, and constrained, the organisation cannot answer basic questions about what data it saw, what it stored, or what it helped publish.
Current best practice is to treat these tools as part of the software supply chain and as privileged workloads. Security teams should align approval with policy, then enforce runtime controls that cover:
- Approved model and assistant inventory, including versions and plugin dependencies
- Data-loss rules for prompts, snippets, tickets, and source code
- Secrets scanning before commits, builds, and package publication
- Access boundaries for repositories, CI/CD systems, and internal APIs
- Logging for model calls, tool use, and generated artifacts
That operational model is consistent with the 2024 ESG Report: Managing Non-Human Identities, which found that 72% of organisations have experienced or suspect they have experienced a breach of non-human identities. It also fits the control logic in NIST SP 800-53 Rev 5 Security and Privacy Controls, where access, auditability, and configuration management are part of the same governance chain. These controls tend to break down when developers can connect third-party models directly to repos, CI/CD, or secret stores without a security checkpoint because the tool’s permissions outgrow the review that approved it.
Common Variations and Edge Cases
Tighter AI governance often increases friction for developers, so organisations need to balance speed against exposure. That tradeoff becomes sharper in fast-moving product teams, where local assistants, API-based copilots, and open-source model wrappers may appear and disappear faster than standard review cycles can track.
There is no universal standard for this yet, but current guidance suggests treating different AI uses differently. A read-only code suggestion tool carries less risk than an assistant with repository write access, issue-tracker access, or the ability to call deployment APIs. Third-party models add another layer because the organisation may not control retention, training use, telemetry, or subprocessor exposure. For that reason, governance should distinguish between:
- Low-risk autocomplete inside tightly scoped editor extensions
- Higher-risk assistants that can read internal code or documentation
- High-risk integrations that can modify pipelines, create tickets, or invoke cloud services
Security teams should also review model usage against supplier assurance and internal policy, not just code quality. The Top 10 NHI Issues and the CI/CD pipeline exploitation case study show why weak non-human identity controls and pipeline trust assumptions are often the real failure point. In practice, the hardest cases are regulated environments where developers use external AI services through personal accounts or shadow integrations, because the organisation loses visibility before policy can even be applied.
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, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A03 | AI assistants can act unpredictably and expand access in pipelines. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Third-party models and assistants rely on secrets that often spread unmanaged. |
| CSA MAESTRO | P1 | MAESTRO covers governance for autonomous model and tool workflows. |
| NIST AI RMF | GOVERN | AI pipeline use needs accountable governance and documented oversight. |
| NIST CSF 2.0 | PR.AC-4 | Pipeline AI access must follow least-privilege identity and access control. |
Inventory assistant capabilities and restrict tool access to the minimum task scope.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
