What Happened
Three investigations show how attackers can reach the infrastructure around an AI application without attacking the model itself. Unit 42 investigated an intrusion involving exploitation of CVE-2024-47575, targeting more than 500 FortiGate firewalls and deploying PEERSTITCH, a memory-resident ARM64 implant [1].
Microsoft and Resecurity identified a phishing ecosystem whose kits have been used to send more than one billion emails and texts targeting over 75,000 organizations since January 2026. The associated marketplace also resells compromised or fraudulently obtained cloud resources, including accounts, licenses and storage [2].
Separate testing of 25 package managers found that fewer than half used tamper-checking lockfiles by default. Only Go and vcpkg verified the integrity of every downloaded package in the tested configurations. The tests were limited to one package, manager version and platform per case [3].
Why It Matters to Businesses
An AI application inherits the security of its network edge, cloud identities and software dependencies. A compromised administrator account can expose data or change deployments; a compromised firewall can provide a covert foothold; and a substituted package can enter a build despite an HTTPS connection to its repository [1][2][3]. These are distinct from model-specific attacks, but they can compromise the same production system.
Kimbodo Engineering Perspective
Model guardrails cannot compensate for weak infrastructure controls. We would prioritize the paths that can alter production code, retrieve sensitive data or grant privileged access. The practical trade-off is to add verification where it blocks a meaningful attack path without making every build or release dependent on manual approval. Lockfiles, for example, help only when they cover the installed content and a mismatch fails the build [3].
How We Would Implement It
- Protect access: Use phishing-resistant MFA or passkeys, Conditional Access and least privilege for cloud and deployment administrators; monitor suspicious sign-ins and verify urgent requests through trusted channels [2].
- Harden the edge: Inventory internet-facing firewalls, apply relevant fixes, and investigate indicators of compromise rather than assuming patching removes an existing implant. Include network devices in incident-response plans [1].
- Make builds reproducible and verifiable: Pin dependencies, enforce lockfile mismatches as failures, restrict package sources and assess what each language’s package manager actually verifies during installation [3].
- Correlate signals: Connect identity, endpoint, network and build logs so investigators can trace a suspicious sign-in through cloud-resource changes and subsequent deployments.
Risks, Costs and Security
Stricter dependency checks can interrupt builds when upstream packages change; phishing-resistant authentication requires enrollment and recovery processes; and edge-device investigations may require specialized evidence collection. Those costs should be planned into operations. The greater risk is treating a control’s presence as proof of coverage: HTTPS does not establish that a repository is trustworthy, a recorded package identifier may not cover the installed code, and a patched firewall may still warrant investigation after suspected compromise [1][3].
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our AI Security & Guardrails practice, or Request a Security Review.
