Why do abandoned AI projects create so much security risk?

Why This Matters for Security Teams

Abandoned AI projects are risky because they rarely fail cleanly. A prototype can still hold API keys, service accounts, model endpoints, retrieval connectors, and data copies long after the original team has moved on. That creates an unmanaged trust boundary: the asset looks inactive from a product perspective, but it may still be reachable from a security perspective. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it reinforces the need to identify, protect, detect, respond to, and recover from assets that remain in scope even when ownership is unclear.

The biggest mistake is assuming “non-production” means “low risk.” AI projects often have privileged access to internal datasets, third-party model services, or orchestration tools, and those permissions are frequently broader than the final deployment would require. If the project used agentic workflows, the risk is higher because the system may have been granted execution authority over tools, tickets, or repositories. In practice, many security teams encounter this only after a forgotten integration is flagged by an external audit, rather than through intentional lifecycle retirement.

How It Works in Practice

Security risk persists when the full AI project stack is not decommissioned as a unit. A model notebook may be gone while its service principal remains active, or a proof-of-concept may be retired while its vector database and connector credentials continue to refresh data. The right approach is to treat the project as a collection of identities, secrets, pipelines, data flows, and dependencies that each need explicit shutdown. This aligns well with the asset visibility and governance expectations in the NIST Cybersecurity Framework 2.0.

• Inventory every AI-related asset, including model endpoints, notebooks, storage buckets, retrievers, and external SaaS integrations.
• Revoke machine identities and secrets first, then verify that token issuance, key rotation, and callback URLs are no longer valid.
• Check whether the project created copies of production data, prompts, embeddings, or fine-tuning sets and remove or quarantine them.
• Confirm that logs, monitoring alerts, and CI/CD jobs tied to the project are either deleted or reassigned to current owners.
• Document the retirement decision so the asset does not reappear later through an undocumented dependency or shadow deployment.

For AI-specific threat modelling, the OWASP Top 10 for LLM Applications and the MITRE ATLAS framework help teams think about prompt injection, data leakage, supply-chain compromise, and abuse of model-connected tooling. Those concerns matter even when the project is no longer being actively developed, because dormant access paths are still exploitable if the surrounding infrastructure stays live. These controls tend to break down when teams lack a definitive owner for the project because no one is assigned to complete revocation, evidence collection, and final deletion.

Common Variations and Edge Cases

Tighter retirement controls often increase operational overhead, requiring organisations to balance fast experimentation against traceable shutdown and evidence retention. That tradeoff is especially visible in AI environments where developers expect short-lived sandboxes but security teams need durable records of what was connected, what data was exposed, and what access was granted.

There is no universal standard for this yet, but current guidance suggests that abandoned AI projects should be handled differently depending on whether they touched regulated data, production credentials, or autonomous tooling. A harmless demo notebook is not the same as an agent that can call cloud APIs, open support tickets, or access internal knowledge bases. If the project used non-human identities, the identity lifecycle is part of retirement, not an afterthought. That is where NHI governance becomes the bridge between AI security and identity security: if the machine identity remains valid, the project is not truly abandoned.

Edge cases include shared research clusters, student or contractor environments, and temporary vendor proofs of concept. In those settings, “delete the repository” is not enough. Teams should verify whether cached data, long-lived secrets, and federated access policies survived the project’s end date. The NIST Cybersecurity Framework 2.0 provides the right operational lens, while CISA Secure by Design reinforces the idea that secure systems should fail closed when no longer maintained.

Related resources from NHI Mgmt Group

• What is the core decision loop Agentic AI follows and why does it create security risk?
• When does AI-assisted security tooling create more risk than it reduces?
• Why do agentic AI systems create more security risk than standard chatbots?
• Why do orphaned NHIs create so much security risk?