Office Address
45 Ivan Allen Jr Blvd NW
Atlanta, GA 30308
Phone Number
+1 (888) 808-7330
Email Address
General: [email protected]
Sales: [email protected]
Support: [email protected]
45 Ivan Allen Jr Blvd NW
Atlanta, GA 30308
+1 (888) 808-7330
General: [email protected]
Sales: [email protected]
Support: [email protected]
by Trurion Staffs
On 2 August 2026, the EU AI Act's transparency obligations began to apply. Six days earlier, Regulation (EU) 2026/1744 — the Digital Omnibus on AI — entered into force, pushing the Act's high-risk regime from that same August date to 2 December 2027 for standalone Annex III systems and to 2 August 2028 for AI embedded in regulated products.
A lot of organizations read that as breathing room. It isn't, and the reason has nothing to do with Brussels.
The deferral moved the compliance date. It did not move the problem underneath the date, which is that most organizations cannot produce a list of the AI systems operating inside their vendor ecosystem. You cannot document conformity for systems you have not inventoried, and the inventory is the slow part. More immediately, the same missing inventory is what turns an ordinary vendor compromise into a breach you find out about eight months later.
This post makes a narrow argument. AI has not created a new category of third-party risk. It has made your existing third-party risk surface substantially harder to see — through integrations you approved once and never reviewed, sub-processors you never contracted with, and tooling your employees and your vendors' employees adopted without telling anyone. The losses show up in old, boring categories: inherited credentials, over-scoped access, and unmonitored machine identities.
IBM released the 2026 Cost of a Data Breach Report on 29 July. Ponemon Institute conducted the underlying research across 602 organizations in 16 countries and 17 industries, covering breaches between March 2025 and February 2026. The global average breach cost reached $4.99 million, a 12% rise and the highest figure in the study's 21 editions.
Three findings matter here, and they point in the same direction.
Supply chain compromise was the single largest cost-amplifying factor measured. Of the factors associated with higher breach costs, supply chain breaches led at $227,250 above the average — ahead of security system complexity, shadow IT, and regulatory noncompliance. Supply chain compromise also ranked as the second most common initial attack vector, behind phishing.
It is also the vector you find last. Supply chain compromises took an average of 258 days to identify and contain, compared with an overall average of 247 days, which rose this year after five consecutive years of improvement. Breaches running past 200 days averaged $5.65 million; those contained faster averaged $4.32 million.
The AI incidents that happened most often were not model attacks. IBM priced AI incident types, and the ranking is instructive. Model inversion was costliest at $6.07 million, and prompt injection followed at $5.89 million — both attacks on how a model reasons or what it retains. But by frequency, the two most reported AI incident types were cloud security misconfigurations and the compromise of connected applications, APIs, and plug-ins, tied at 27% each. Compromise of connected apps and APIs was also among the least expensive per incident, at $4.37 million.
Editorial note: Cost and frequency are different measures and this ranking does not establish that model-level attacks are rare — it establishes that the incidents organizations actually reported were disproportionately structural. IBM's own executive summary describes root causes as more often structural than model-specific. Read the cost figures as associations measured in isolation, not as returns on control investment.
The governance picture behind those numbers is worse than the headline. Sixty-eight percent of breached organizations had no AI governance policy in place — 35% had none at all, 33% had one still in development. The share with a finished policy actually fell, to 32% from 37%. Of the six governance controls measured in both years, five saw adoption decline: strict approval processes for AI deployments dropped to 38% from 45%, regular audits for unsanctioned AI fell to 29% from 34%, and employee training on AI risk slipped to 30% from 36%. Only adversarial testing gained ground, rising from 22% to 25%.
Meanwhile, the exposure widened. Security incidents involving an AI model or application accounted for 21% of breaches, up from 13%. Among organizations that suffered an AI-related breach, 92% lacked proper AI access controls. Across the full sample, only 40% applied access controls to AI models and data at all, and only 46% reported securing the non-human identities — service accounts, API keys, tokens — used in AI workflows.
Editorial note on methodology: The Ponemon sample is nonstatistical and judgmental, self-reported, and by the researchers' own assessment skewed toward organizations with more mature security programs. Costs are extrapolated rather than drawn from financial records. Treat every figure above as a directional benchmark for planning, not an actuarial estimate. The skew toward mature programs is worth holding in mind specifically when reading the 68% governance figure, which a mature-program bias should push down, not up.
Ncontracts surveyed 173 financial services professionals between November 2025 and January 2026 for its 2026 State of Third-Party Risk Management report. For the first time in the survey's history, AI risk tied cybersecurity as the top third-party concern.
The confidence data is the interesting part. Seventy-two percent of institutions reported being only partially aware of which of their vendors use AI. Not a single organization surveyed described itself as extremely confident in its ability to identify and manage AI-related vendor risk; 4% said very confident. Among large organizations with 5,001 or more employees, 73% fell into the lowest confidence tiers — scale conferred no advantage.
This sits atop structural capacity constraints that predate AI entirely. Sixty-three percent of these TPRM programs run with one or two dedicated full-time employees, and roughly half oversee 300 or more vendors. That is a ratio in which a single practitioner may own a hundred vendor relationships. Adding "assess the model provenance, retention policy, and sub-processor chain of every AI feature in the portfolio" to that workload is not a policy problem. It is an arithmetic problem.
There is also a fourth-party dimension that questionnaires rarely reach. When a SaaS vendor adds an AI feature, the underlying model usually belongs to someone else. Your data may traverse a model provider you never contracted with, never assessed, and cannot name — and that provider may change without a contract amendment, because in most agreements, nothing requires the vendor to tell you.
Three patterns from the past twelve months, each illustrating a different failure mode.
In August 2025, attackers obtained OAuth access and refresh tokens that Salesloft held on behalf of customers for its Drift AI chat product. Those tokens were the keys to customers' Salesforce instances — and, in a subset of cases, to Google Workspace and other connected platforms. Google Threat Intelligence Group and Mandiant disclosed a widespread data theft campaign; Salesloft disclosed on 20 August and later took Drift offline. Salesforce itself was not the point of failure. The vendor's custody of the tokens was.
The amplifier was what attackers did next: search the exfiltrated data for further credentials — cloud access keys, warehouse tokens — turning one vendor compromise into staged access across multiple downstream environments. FINRA issued a member alert. Hundreds of organizations were affected.
Editorial note on attribution: GTIG and Mandiant tracked the activity as UNC6395, an uncategorized cluster designation. Separate vendor reporting associated the campaign with the ShinyHunters brand. These are not equivalent claims: UNC6395 is a researcher-assigned operating cluster, while ShinyHunters functions as a branding umbrella used across loosely connected actors. Distinguish researcher-inferred attribution from actor-claimed attribution when citing this incident.
Editorial note on framing: Calling this an "AI breach" is misleading, and worth resisting. Drift's conversational AI played no role in the compromise mechanics. What the incident demonstrates is why AI-native SaaS deserves scrutiny anyway: products of this type are routinely granted broad, persistent, high-scope access to systems of record because that access is what makes them useful. The AI is the reason the scopes are wide. The scopes are the reason the breach was large.
In April 2026, OX Security published research on an architectural remote code execution weakness in the Model Context Protocol — the standard used to connect AI agents to external tools and data. The finding was not a coding error but a design consequence: MCP's primary transport spawns subprocesses, so command execution is the default interface, inherited by every implementation. OX estimated roughly 200,000 vulnerable instances across a dependency footprint exceeding 150 million downloads and documented exploitation of production platforms, including LangFlow, Letta, and Flowise, the last receiving CVE-2026-40933 with a CVSS score of 10.0.
Researchers disclosed more than 40 CVEs against MCP implementations across Python, TypeScript, Java, and Rust SDKs between January and April 2026. Anthropic declined to change the protocol architecture, characterizing the behavior as expected; some downstream vendors patched, others did not.
The supply chain dimension is separate and arguably more relevant to procurement. In September 2025, an unofficial Postmark MCP server with roughly 1,500 weekly downloads was modified to add a blind-copy recipient to its email-sending function, silently duplicating outbound mail to an attacker's address. Registry listing is not vetting — admission to the official MCP registry requires proof of repository or domain ownership, not code review, security audit, or malware scanning.
Editorial note: The 200,000 figure is an exposure estimate — instances running vulnerable implementations — not a count of confirmed intrusions. Keep that distinction. The Postmark case is a confirmed malicious modification; the OX research documents demonstrated exploitability against live systems. Both are real, and they are different claims.
Between April and June 2026, three npm campaigns — tracked under the Mini Shai-Hulud and Miasma names — moved supply chain malware out of package-manager execution and into the configuration files that AI coding agents and IDEs trust. A 19 May wave compromised 323 npm packages across 639 malicious versions, using AI coding assistant session hooks and editor task definitions for persistence. A 3 June Miasma wave hit 57 packages across 286-plus versions and added an install-time execution path through build configuration.
The operationally important detail is that once those hooks are written, removing the package does not remove the backdoor. It lives in the project configuration, not in dependencies. Reported credential targets spanned cloud providers, source control, container orchestration, SSH keys, and secrets-manager CLI stores.
This is a third-party risk story even for organizations that write no code. Your vendors' developers use this tooling. A compromise of their build environment is a compromise of what they ship to you.
An annual questionnaire and a SOC 2 report were designed to answer different questions. They establish that a vendor has controls; they do not establish what happens to your data once an AI feature touches it. Specifically, the standard artifacts are silent on:
The NSA's AI Security Center, together with seven allied national agencies, published joint guidance in March 2026 defining the AI/ML supply chain across six components: training data, models, software, infrastructure, hardware, and third-party services. The guidance flags third-party services as the highest-complexity vector precisely because they import risk through their own supply chains. Its central procurement recommendation is an AI Bill of Materials — a component inventory analogous to an SBOM — plus contractual cybersecurity requirements and ongoing monitoring rather than point-in-time assessment.
Vendor-neutral, and ordered by what tends to return the most for the least effort.
1. Discover before you survey. Asking vendors which AI they use yields an incomplete list, and asking employees yields a shorter one. Egress monitoring, single sign-on logs, OAuth application inventories in your major SaaS tenants, and expense-report review for unbudgeted AI subscriptions produce a real one. Only 29% of organizations in the IBM study ran regular audits for unsanctioned AI; that is the control gap where shadow AI — 43% of AI-related security incidents this year, up from 20% — becomes invisible spend and invisible data flow.
2. Treat integration scope as the primary control point. The Drift incident was survivable for organizations that had scoped the integration narrowly. Inventory every connected application in Salesforce, Google Workspace, Microsoft 365, Slack, and your identity provider. Record what scopes each holds. Remove dormant integrations. Re-review quarterly, not annually, and treat scope expansion in a vendor release note as a change requiring approval.
3. Govern non-human identities as identities. Tokens, service accounts, and API keys used by AI workflows should have owners, expiry, rotation schedules, and monitoring. Fifty-four percent of organizations in the IBM sample reported no such controls in AI workflows. Machine identities bypass the MFA and conditional access you spent years deploying.
4. Extend the questionnaire with AI-specific questions that have verifiable answers. Zero-retention API options and contractual opt-out from training use; named sub-processors with change notification; model substitution notice; independent audit rights; incident notification windows measured in hours, not "promptly." Request an AI-BOM. A vendor that cannot answer these is telling you something.
5. Vet AI tooling like the software supply chain it is. Pin dependencies. Restrict which MCP servers and agent extensions may be installed. Audit agent and editor configuration directories in repositories before opening unfamiliar projects in trusted tooling. Sandbox MCP-enabled services and block public exposure of their configuration interfaces.
6. Move from assessment to monitoring. A questionnaire captures one moment. Given a 258-day mean detection window for supply chain compromise, the operating assumption should be that a vendor in your portfolio is compromised now and you do not know it. Plan detection and response accordingly — vendor-side incident playbooks, token revocation runbooks, and tested re-integration procedures.
7. Use the regulatory runway for the inventory, not for waiting. Article 50 transparency obligations apply from 2 August 2026, with a limited transition to 2 December 2026 for machine-readable marking on generative systems already on the market. The AI literacy duty has already been applied. The deferral to December 2027 is a time to deliberately build documentation and governance scaffolding — and the inventory is the prerequisite for all of it.
The dominant narrative in AI security marketing is autonomous adversaries and novel model attacks. Those are real and worth tracking. But the incidents that produced actual losses over the past year ran on unrotated OAuth tokens, over-scoped integrations, unvetted packages, and tools nobody had inventoried. The most expensive AI incident types were model attacks; the most frequent were misconfigurations and compromised connections.
That should be encouraging, because it means the controls that work are ones your organization already understands. Access scoping. Identity lifecycle. Asset inventory. Continuous monitoring. What changed is not the control set — it is that the assets now include systems you do not operate, running models you did not select, reached through integrations you approved eighteen months ago and have not looked at since.
Why Organizations Choose Zaxtron
Organizations face increasingly sophisticated ransomware campaigns that exploit unpatched systems, stolen credentials, exposed remote access, and third-party weaknesses. To stay protected, they need actionable intelligence, not just alerts, to identify and reduce cyber risks before disruption occurs. Zaxtron provides Cybersecurity Risk Management, AI Risk Management, and Cyber Threat Intelligence services that deliver continuous visibility and risk-based insights. By combining attack surface intelligence, vulnerability data, threat and breach intelligence, and third-party risk analysis, Zaxtron offers a complete view of cyber exposure. This helps security leaders respond to threats, improve vendor security, and make informed decisions. Contact Zaxtron to strengthen cyber resilience today.
Cookie preferences