TL;DR: Recent AI security incidents in April 2026, including an Anthropic leak and a Mercor supply chain attack, show how human error, insecure integrations, and compromised dependencies can expose source code, customer data, and API keys across AI environments, according to Proofpoint. The lesson is that AI security failures are now operational governance failures, not just model issues.
NHIMG editorial — based on content published by Proofpoint: AI security incidents are real and rising
By the numbers:
- 82% of breaches involve human factors such as error, misdelivery, or misuse.
- 17 minutes and as quickly as 9 minutes, cly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.
Questions worth separating out
Q: What breaks when AI systems rely on exposed code or compromised dependencies?
A: The main failure is not just immediate compromise.
Q: What problem does ownership attribution solve for service accounts and API keys?
A: It closes the gap between exposure detection and accountable remediation.
Q: How can security teams tell whether AI lifecycle controls are working?
A: They should look for evidence that access requests, policy enforcement, and usage visibility are centrally recorded and current.
Practitioner guidance
- Inventory AI dependencies and trust chains Map every library, hosted API, integration, and release step that can move data into or out of AI systems.
- Add pre-release exposure controls Require code scanning, secret detection, and packaging validation before AI-related code or artefacts are published.
- Map AI workflows to non-human identities Identify which service accounts, API keys, certificates, and delegated tokens authorise each AI workflow.
What's in the full article
Proofpoint's full article covers the operational detail this post intentionally leaves for the source:
- Specific examples of how AI-related exposure happened in the Anthropic leak and Mercor supply chain case.
- The article's breakdown of why release packaging and open source dependency risk behave differently in AI environments.
- Practical examples of how AI security failures intersect with Microsoft 365, collaboration platforms, and downstream data sharing.
- Proofpoint's recommended control priorities for reducing human-driven AI exposure and supply chain risk.
👉 Read Proofpoint's analysis of the Anthropic leak and Mercor AI supply chain attack →
AI security incidents and supply chain exposure: what teams need to know?
Explore further
AI security is becoming an identity and trust governance problem, not a model-only problem. The article is correct to frame the risk around how people, tools, and integrations interact with AI systems. That makes the control surface broader than model hardening and closer to IAM, NHI governance, and software supply chain assurance. Practitioners should treat AI systems as trust chains that need continuous identity and access oversight.
A question worth separating out:
Q: Who is accountable when AI supply chain exposure leaks customer data or source code?
A: Accountability usually spans product security, application owners, cloud teams, and identity owners because the failure crosses code, dependency, and access boundaries. In regulated environments, the organisation must be able to show that releases, secrets, and third-party dependencies were governed before exposure occurred. Shared responsibility does not remove responsibility.
👉 Read our full editorial: AI security incidents expose the human and supply chain risk gap