Fort Wayne AI Vendor Release-Pipeline Buyer Test for 2026

What does “release-pipeline attack” mean and why is it different from a runtime AI attack?

Three timing layers exist in AI supply-chain security, and most mid-market firms collapse them into one. Naming them correctly is the precondition for fixing any of them.

The incident-response layer is where most public conversation lives. A specific incident lands — Shai-Hulud, OpenClaw, Skill scanners — and the question is what to do this week. Cloud Radix's incident playbooks live here.

The runtime layer is where most security investment lives. Prompt-injection red teaming, agent identity and IAM, authorization audits, observability stacks, evaluation harnesses — all of it watches what the AI agent does after it is deployed inside the customer boundary. The Fort Wayne AI agent authorization audit playbook and the credential attack vector writeup are runtime-layer artifacts.

The procurement layer is the timing layer that sits upstream of both. It runs at AI-tool buying time, before the vendor's binaries cross your boundary, and asks what the vendor did on their build server before publishing. It is the layer with the highest leverage and the lowest mid-market spend.

A release-pipeline attack is one that targets the vendor's build infrastructure — the runner that compiles the artifact, the signing key that attests to it, the publishing channel that emits it. The artifact that arrives at your firm carries the legitimate publisher's name and a valid signature, because the legitimate publisher's build pipeline produced it. The defense is not at runtime; the defense is to have asked, at procurement time, what kind of pipeline the vendor runs and what evidence they will share to prove their claims.

According to the VentureBeat supply-chain release-surface analysis published 2026-05-18, four such incidents struck AI vendors in 50 days. The pattern is statistically unusual. Prior supply-chain waves — the 2018 event-stream npm hijack, the 2020 SolarWinds incident, the 2021 Log4Shell vulnerability — were single-incident framings that the industry absorbed one at a time. Four in 50 days, across model weights and Skill bundles and MCP servers and npm packages, is a structural change. AI's release surface is wider than traditional enterprise software's release surface, and attackers are exploiting that width in parallel.

What were the four AI supply-chain attacks in 50 days?

The 50-day window covers four distinct attack patterns hitting four distinct AI release surfaces. The full incident-by-incident details are in the source articles linked below; the summary here is what a NE Indiana IT director needs to know to populate the questionnaire.

The Shai-Hulud npm worm (2026-05-12). A self-replicating worm that, in its May 2026 wave, pushed malicious code into 172 npm and PyPI packages while producing valid provenance signatures. The build pipeline that produced the green provenance badge had been compromised upstream — meaning every defender check that boiled down to “the signature verifies” silently passed the poisoned build through. Channel: npm and PyPI public registries. Attack stage: maintainer-credential takeover plus build-server publishing.

The Anthropic Skill scanner test-file bypass (2026-05-07). A demonstration that malicious code packaged inside a Skill bundle's test/ directory could pass every existing scanner check while still executing at install time. Scanners treated test files as out-of-scope by convention. Channel: AI agent extension marketplace (Skills). Attack stage: test-file inclusion bypassing build-time scan.

The MCP-stdio flaw (2026-05-01). A category-level vulnerability in the Model Context Protocol's stdio transport that, per reporting on the OX Security audit, exposed roughly 200,000 AI agent MCP servers to remote command execution. Channel: MCP server publishing. Attack stage: protocol-design defect carried through to every server built on it.

The OpenClaw one-command backdoor (2026-05-05). A demonstration that a single command-line invocation could convert an open-source repository into an AI-agent supply-chain backdoor by injecting agent-callable tools that the repository's maintainers never authored. Channel: open-source repo as agent context. Attack stage: post-clone code injection masquerading as repo content.

The audit table below maps these four to the buyer-side controls that would have caught each at the procurement gate. Note the structural similarity: every one of them is invisible to runtime red teaming, because by the time the artifact reaches runtime, the supply chain is already poisoned.

What is the 7-question AI Vendor Release-Pipeline Questionnaire?

This is the buyer test. Each of these is its own H3 below with the acceptable answer range. The recommended use is to embed all seven in the AI section of your standard vendor security questionnaire (the SIG or CAIQ document you already use for other SaaS procurements), score each vendor response, and treat refusal-to-answer as a procurement-stage red flag of the same magnitude as a failed SOC 2 audit.

Question 1 — Does the vendor publish signed provenance attestations for every shipped artifact?

The acceptable answer is “yes, at SLSA Level 3 or higher, with Sigstore-or-equivalent transparency logging, for every artifact we ship — including model weights, Skill bundles, MCP servers, browser extensions, and any npm or PyPI packages we author.” The SLSA framework's published levels define what Level 3 means in practice: hardened build platform, source and build provenance, two-party review of build configuration changes. The transparency-log requirement is the layer that lets a third party verify the attestation independently — without it, a “yes we sign” answer is structurally weaker.

Watch for the dodge “we sign our official binaries” without specifying the channels for Skills, MCP servers, extensions, or auxiliary npm packages. Shai-Hulud was an npm-package incident; the test-file bypass was a Skill incident. Vendor signing that only covers the main binary leaves both of those channels uncovered.

Question 2 — Does the vendor scan test files with the same rigor as production code?

The acceptable answer is “yes, our build-time scanners do not exclude test/, tests/, __tests__/, spec/, or fixtures/ directories, and our static analysis treats any executable code in those paths as in-scope.” The Anthropic Skill scanner bypass was the perfect demonstration of why this question matters: an entire industry convention treated test directories as non-shipping code, and that convention was load-bearing for an attack class.

Watch for “we don't ship test files in our production artifacts.” That is the correct answer for some vendors and the wrong answer for vendors whose artifact format includes test code by convention (Skills, plugin marketplaces, GitHub Actions, npm packages whose files arrays don't exclude tests).

Question 3 — Does the vendor maintain an AI-BOM (or SBOM) for shipped artifacts?

The acceptable answer is “yes, we publish an SBOM in CycloneDX or SPDX format for every release, and an AI-BOM that lists model weights, training data classifications, third-party Skill or MCP dependencies, and any open-source agent frameworks. We share both under NDA in response to a customer procurement request within 10 business days.” CISA's ICT supply-chain security guidance puts SBOM at the center of the buyer-side defense; an AI-BOM is the natural extension.

Watch for “we'll provide that information during the security review” without an SLA. The point of the question is to confirm the vendor already maintains the artifact; producing it on demand mid-procurement is a different posture.

Question 4 — What is the vendor's incident-response SLA for a downstream supply-chain compromise?

The target acceptable answer is “customer notification within 24 hours of confirmed incident, artifact rotation within 72 hours, written post-incident report within 30 days, with notification triggered by either internal discovery or a credible third-party disclosure.” The 24/72 numbers are not regulatory — they are Cloud Radix's recommended floor based on the cadence the four incidents above played out at, and we recommend stating them explicitly in the questionnaire so the vendor either commits or pushes back.

Watch for “we'll notify our customers as soon as practicable.” That is contract boilerplate, not a procurement answer. The whole point is to know the cadence before you depend on it.

Question 5 — Does the vendor support buyer-pinned versions or hashes?

The acceptable answer is “yes, customers can pin any artifact by version, hash, or signed-attestation ID, and our auto-update channel can be opted out per environment without forfeiting support.” Buyer-pinned versions are the structural defense against the Shai-Hulud class of attack: if your CI installs from a pinned hash rather than a moving version range, a compromised auto-update channel does not reach your runtime.

Watch for “we strongly recommend taking the latest version for security reasons.” That is a vendor convenience answer, not a customer security answer. The two goals are in tension, and the buyer should have the choice.

Question 6 — What runtime telemetry does the vendor expose for buyer-side verification?

The acceptable answer is “yes, we expose signed manifest metadata, model fingerprint, and effective configuration through an API the customer's gateway can query at every request, and our manifest format is documented publicly.” The OWASP Top 10 for LLM Applications 2025 calls out LLM06 (Excessive Agency) and LLM10 (Unbounded Consumption) as runtime-side failure modes; the structural fix is to give the buyer enough telemetry to verify what the deployed artifact is actually doing. The Cloud Radix Secure AI Gateway is built to consume exactly this kind of metadata at the boundary.

Watch for “we provide telemetry to our customers through our admin console.” That is a vendor-mediated answer; the buyer-side verification model requires telemetry the buyer can independently consume, ideally through an open API.

Question 7 — What contractual rights does the buyer have after a vendor-side supply-chain incident?

The acceptable answer is “yes, customers have the right to terminate without penalty within 30 days of a Severity-1 supply-chain incident, with full refund of any prepaid fees and contractual cooperation on data extraction and migration. Severity-1 is defined as an incident affecting integrity of shipped artifacts or confidentiality of customer data.” This is the procurement-meets-legal question, and the right person to negotiate it is your contracts team, not your IT team.

Watch for “termination rights are governed by the standard MSA.” That answer is non-responsive; the standard MSA does not contemplate supply-chain incidents specifically. Push for an addendum that does. The baseline signing infrastructure described in Sigstore's signing and verification project is the implementation reference behind Question 1 that Question 7 protects against when it fails.

How does this apply to four NE Indiana verticals?

The questionnaire is shape-invariant, but four mid-market verticals in Northeast Indiana have specific exposures worth naming.

The Auburn manufacturer running Claude Code and npm packages. A 200-employee injection-molding plant with a 12-developer in-house app team building an MES dashboard, a customer ordering portal, and a shop-floor IoT integration is exposed primarily to Questions 1, 2, and 5 of the questionnaire — the npm channel and the Claude Code Skill marketplace are the two surfaces that hit them hardest. The procurement-side fix is to embed Questions 1, 2, and 5 in the vendor agreement for Anthropic, GitHub, and any npm-publishing dependency that crosses the IP boundary. Trade-secret exposure on shop-floor process IP makes Question 7 (termination rights) load-bearing.

The DeKalb home-services firm running Make.com plus Zapier plus Anthropic Skills. A 60-employee HVAC or roofing company running automation across three SaaS platforms has the widest number of vendor relationships and the smallest internal IT function. The procurement-side fix is to use Questions 1, 3, and 4 — signed provenance, AI-BOM disclosure, downstream-incident SLA — as the screening filter when adding a new automation connector. The reason: consumer-protection exposure under Indiana law applies if a SaaS connector leaks customer scheduling or billing data, and the Indiana Attorney General's Consumer Protection Division is the relevant state notification authority.

The Allen County healthcare practice running Microsoft Copilot Studio and MCP servers. A 15-provider specialty practice with PHI in its environment has the strictest regulatory exposure and the second-narrowest channel surface — Microsoft and a handful of MCP servers. The procurement-side fix is Questions 1, 2, 6, and 7 — the MCP-stdio incident hit exactly this profile, and the Microsoft side of the stack needs Question 6 (runtime telemetry) because Copilot Studio's behavior is otherwise vendor-opaque. The HIPAA Business Associate Agreement is the contract vehicle; this questionnaire becomes an addendum to it.

The Allen County insurance broker running Salesforce Agentforce and custom Skills. A 40-employee independent insurance agency running Agentforce for policy quoting plus custom Skills for back-office workflows is GLBA-regulated and customer-data-rich. The procurement-side fix is the full seven questions, with Question 3 (AI-BOM) load-bearing for the custom Skills layer — those are vendor-authored artifacts that need disclosure independent of the Salesforce platform attestation. The customer-pricing data inside Agentforce raises the cost of any silent compromise to a level that justifies a procurement-time pilot.

In all four cases, the questionnaire becomes a procurement gate, not a security afterthought. The shop that runs it at buying time spends roughly two hours per vendor; the shop that doesn't run it spends weeks of incident-response time later.

How does the questionnaire fit with the runtime AI controls Cloud Radix already covers?

The procurement layer is upstream; the runtime layer is downstream; both are needed. A mid-market firm that buys well but runs poorly is exposed at runtime. A firm that runs well but buys carelessly is exposed at the publishing channel before runtime ever sees the artifact. The integrated posture looks like this:

At procurement, the 7-question questionnaire screens vendor release pipelines and embeds the right contractual rights. This is the cheapest layer to fix and the layer most mid-market firms skip entirely.

At runtime, the confused-deputy AI agent audit matrix catches authority-delegation failures, the Fort Wayne AI tool poisoning playbook catches MCP-level tool injection at the agent runtime, and the authorization audit playbook catches scope-elevation patterns inside the agent.

At incident response, the Shai-Hulud npm worm action plan and the Anthropic Skill scanners writeup cover the specific playbooks once a known incident lands.

The buyer-side verification point — where the procurement-layer claims meet the runtime layer — is the Secure AI Gateway. The gateway sits at the boundary the vendor's artifact crosses, consumes the manifest metadata Question 6 requires, and enforces the version-pinning and integrity properties Question 5 covers. It is the only place in the stack where a vendor's procurement-time claim can be independently verified at every request. The NIST AI Risk Management Framework's Manage and Measure functions both depend on this kind of independent verification.

How does Cloud Radix run a procurement-audit pilot for NE Indiana firms?

The honest answer is that procurement work looks dull on a slide deck and pays off in incidents that don't happen. Cloud Radix offers a regional AI Vendor Release-Pipeline Audit pilot for Auburn, Fort Wayne, DeKalb, Allen, Whitley, and Noble County firms. We embed the 7-question questionnaire in your existing vendor onboarding process, score your current top-five AI vendor relationships against it, and produce a written remediation list ranking each gap by exposure. For verticals with HIPAA, GLBA, or trade-secret exposure, we add the contractual-language work in Question 7 as an addendum to your existing MSAs. The pilot is sized for 25-to-250-seat firms, takes four weeks from kickoff to remediation list, and produces an artifact your insurance carrier, your board, and your regulators all recognize. Contact our AI consulting team if you want the audit run against your current AI vendor stack before the next regulatory cycle.

A note on self-host as an adjacent decision. The 5/18 mid-market self-hosted-runtime piece argued that self-hosting the AI agent runtime eliminates entire classes of vendor questions. That is true at the runtime layer. It is also true that self-hosting does not eliminate the npm/PyPI dependency-channel exposure — every self-hosted runtime still pulls packages from upstream registries. The procurement questionnaire is the layer that catches that residual exposure regardless of whether your runtime is vendor-managed or self-hosted.

Frequently Asked Questions

Sources & Further Reading

1. VentureBeat (supply-chain release surface): venturebeat.com — Four AI supply-chain attacks in 50 days — release-surface analysis published 2026-05-18.
2. VentureBeat (Shai-Hulud): venturebeat.com — Shai-Hulud worm with valid provenance — 172 npm and PyPI packages compromised (2026-05-12).
3. VentureBeat (Anthropic Skill scanners): venturebeat.com — Anthropic Skill scanners and the test-file bypass — test-directory scan exclusion class (2026-05-07).
4. VentureBeat (MCP-stdio flaw): venturebeat.com — MCP stdio flaw and ~200,000 exposed agent servers — protocol-design vulnerability (2026-05-01).
5. VentureBeat (OpenClaw backdoor): venturebeat.com — One command turns an open-source repo into an AI-agent backdoor — supply-chain demonstration (2026-05-05).
6. Open Source Security Foundation: slsa.dev/spec/v1.0/levels — SLSA Supply-chain Levels for Software Artifacts (Level 3 referenced in Question 1).
7. Sigstore / OpenSSF: sigstore.dev — signing, verifying, and protecting software with transparency-log attestations.
8. Cybersecurity and Infrastructure Security Agency: cisa.gov — ICT Supply Chain Security Guidance — SBOM-centric defense reference for Question 3.
9. OWASP GenAI Security Project: genai.owasp.org/llm-top-10 — OWASP Top 10 for LLM Applications 2025 (LLM06 Excessive Agency, LLM10 Unbounded Consumption).
10. NIST: nist.gov/itl/ai-risk-management-framework — AI Risk Management Framework (Manage and Measure functions cited in the gateway verification point).