Topic starter
14/07/2026 4:25 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Proofpoint: “Anthropic Leak and Mercor AI Attack: Takeaways for Enterprise AI Security”.
By the numbers:
- 82% of breaches involve human factors such as error, misdelivery, or misuse.
Key questions
Q: What fails when AI code or internal files are exposed before release?
A: The failure is durability.
Q: Why does AI make software supply chain risk harder to control?
A: AI increases the amount of code produced, which reduces the time available for review and makes malicious or unauthorized changes harder to spot.
Q: What are the signs that AI governance is failing in the enterprise?
A: Common warning signs include rapid growth in AI use without matching policy coverage, sensitive files being copied into personal accounts, and a large share of AI apps carrying high or critical risk.
Practitioner guidance
- Enforce pre-release exposure checks Block releases until source code, internal files, and embedded secrets are scanned and approved in controlled pipelines.
- Inventory AI dependencies and connectors Maintain a live register of libraries, SDKs, and services that can reach AI data flows or credentials, including open source components.
- Restrict API key reachability Scope API keys to the minimum required services and separate keys used for model access from keys used for business systems.
Bottom line: AI security incidents now show that governance failures in release processes, integrations, and dependencies can expose code, data, and credentials at enterprise scale.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/07/2026 5:06 pm
AI security governance is now an identity problem as much as a model problem. The article shows that exposed code, shared integrations, and user-driven mistakes are where AI risk becomes real. That means the control plane is not just the model runtime, but also the people, credentials, and dependencies that move information around it. Practitioners should treat AI governance as a trust-boundary problem, not a model-only discipline.
A few things that frame the scale:
- Organisations that rely heavily on static credentials reported a 20-percentage-point increase in security incidents compared with those with low reliance, according to the 2026 Infrastructure Identity Survey.
- Organisations that describe themselves as confident in their AI deployment actually experience a 72% security incident rate, compared to 33% for those who remain cautious, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: Should organisations separate AI agent monitoring from identity governance?
A: Yes. Organisations should separate AI agent monitoring from identity governance because they solve different problems. Monitoring answers what happened, while identity governance answers whether the action should have been possible. Keeping those functions distinct prevents teams from mistaking visibility for control and helps reduce over-permissioning.
👉 Read our full editorial: AI security incidents expose the human and supply chain risk gap