The Vendor Update Card

Watch the two-minute walkthrough 2:25

A two-minute walkthrough: the question, the release that was the attack, the six questions, the four verdicts, and how to run the prompt in any model.

Play video

The decision it forces

How does this AI product change after we've bought it? The approval most teams run is a snapshot: a demo, a security questionnaire, a contract. All of it describes the product on the day it was signed. Then the product updates itself, sometimes daily, and every update is a new version nobody approved.

This card asks the vendor six questions about the part the snapshot misses: how the product changes, what it can reach while it does, and how you'd find out if a change was bad. It names one person on your side to keep asking them. Any product can answer them in writing in a week. The ones that can't have told you something.

To run it, copy the prompt below into any model you already use.

The release can be the attack

This month a widely used open-source AI gateway shipped malware through its own official release channels. LiteLLM's report is candid about it: version 1.107.0 on PyPI and the latest Docker image carried a credential stealer, the tagged source code was clean, and the way in was a key to the company's own agent platform that had been committed to a public repository in May and never revoked. Anyone who installed from the real name, through the real channel, in that window got the malware.

None of the usual purchase checks would have caught it. The vendor was the vendor. The code anyone could review was fine. What mattered was how the product got from the vendor to the machine, how fast, what it could reach once there, and how long a leaked key stayed live.

Tim McAllister makes the builder's version of this case and offers a daily prompt for checking what you run yourself. This card is the buyer's half: the questions to put to the vendor before the next update arrives.

The six questions

Each one asks about a part the approval snapshot misses. Put them to the vendor in writing.

1. How does a new version reach us? Pushed by you, fetched when it launches, installed by us, or changed on your hosted service underneath us.
2. Can we hold a version? For how long, and can we delay routine updates while still taking urgent fixes?
3. What can it reach while it runs? Credentials, data, repositories, systems, other tools.
4. How is a release checked before it ships? Signed, built from tagged source, with a record we can verify.
5. When one of your keys leaks, how fast is it revoked? And when did you last practice that?
6. How would you tell us about a bad release, and within how many hours? The channel and the number.

And one question for our side: who owns these answers? One named person, not a team, who asks again at renewal.

The fields

One card per product. The vendor answers; we record the answer and where it's written down.

Each question carries four parts in the answer format. public_pointer is what the vendor's own published pages already say, found before you ask, or none. answer is the vendor's reply in their words. evidence is where that reply is written down (a documentation page, a contract clause, a security statement), or none. declined is true when the vendor says it won't answer or won't commit, with its words kept in answer. A refusal and a silence look the same as a blank, and they aren't: silence can still be chased, a refusal is the answer.

A pointer is never an answer. It only sharpens the question: "your terms say we must tell you about a breach on our account; what's the matching commitment from your side?" gets a faster, more specific reply than the bare question does, and the vendor still has to give it.

There's no worked example on this page: a filled card names a vendor and what it would and wouldn't commit to, and that's between you and them.

The verdict rule

Every card lands on exactly one. In full:

Not ready when the vendor declines any question, when notice names no channel or no number of hours, when any question still has no answer at reply_by (or extended_to, if you agreed one), or when update_path is fetched on launch and can_pin is no. A refusal doesn't wait for the deadline, because it won't change by then. A product that can reach your credentials and update itself without a version you can hold is the exact shape of the release above. A notice that declines to commit is not an answer, even when it's written down.

Incomplete, pending clarification when the deadline hasn't passed and any question still has no answer, or when our_owner is a team rather than a named person. A vendor that answers reach and notice and skips release_checks lands here: go back and ask for the missing answer by name. If it's still missing at reply_by, the card is not ready. You may agree one later date with the vendor and record it as extended_to; a second extension isn't on the card, because a deadline that keeps moving is how incomplete becomes permanent.

Ready with conditions when every question has an answer but any answer has no evidence. A verbal answer goes into the contract or the renewal as a condition, by name.

Ready when every question has an answer with evidence.

An answer that covers a different plan from yours, usually the enterprise tier, isn't an answer for your card. A certification such as SOC 2 is evidence about the vendor's controls in general, not about any one question.

A hosted service that changes underneath you with no version to hold doesn't trip the rule on its own. Nearly every hosted product works that way, and a rule that failed all of them would stop telling you anything. For those, reach and notice carry the weight.

The verdict is about the product's change path, not its quality. A product can be excellent and not ready.

Run it with any model

The model looks up what the vendor already publishes, drafts the questions in a form you can send, and records the replies. It keeps what it found apart from what the vendor says. It doesn't answer for the vendor, and it doesn't treat a marketing page as evidence of a commitment.

Help me fill in a Vendor Update Card for one AI product we buy or are about to
buy or renew. The card asks how the product changes after we've bought it.

STEP 1. Ask me for product (with our plan or edition), vendor, vendor_contact
(or null), and our_owner (one person, not a team). Set asked_on to the day the
questions go out: today, unless I say they already went out on another date. Set
reply_by to one week after asked_on unless I name another date, extended_to to
null, and review_by to the next renewal date if I know it, otherwise null.

STEP 2. Before drafting, look for the vendor's own published pages on each
question: documentation, security or trust pages, terms, DPA, status page,
release notes. Record each as public_pointer: the page and what it says, or
null. A pointer is never an answer and never evidence. Use it only to make the
question sharper, for example "your terms say X; does that apply to our plan,
and is it a commitment?" If you can't browse, say so and leave every
public_pointer null.

STEP 3. Draft a short, polite message I can send the vendor, asking these six
questions in plain language:
- update_path: how does a new version reach us: pushed by you, fetched on
  launch, installed by us, or changed on your hosted service?
- can_pin: can we hold a version, for how long, and can we delay routine updates
  while still taking urgent fixes?
- reach: what can the product access while it runs: credentials, data,
  repositories, systems, other tools?
- release_checks: how is a release checked before it ships: signed, built from
  tagged source, with a record we can verify?
- key_revocation: when one of your credentials leaks, how fast is it revoked,
  and when did you last practice that?
- notice: how and within how many hours would you tell us about a bad release?
Ask for each answer to point to where it's written down, to say whether it
applies to our plan, and to arrive by reply_by.

STEP 4. When I come back with replies, record each one: answer, in the vendor's
words; evidence, the document or clause it points to, or null; and declined,
true only when the vendor says it won't answer or won't commit, otherwise false.
A question with no reply stays answer null, declined false. If I tell you we
agreed a later due date with the vendor, record it once as extended_to; if
extended_to is already set, say a second extension isn't allowed and keep the
first. Do not fill in an answer the vendor didn't give. An answer that covers a
different plan from ours is no answer for this card. If I paste a marketing
page, record it as evidence only if it states the specific commitment, and say
so. A certification such as SOC 2 or ISO 27001 is evidence about the vendor's
controls in general, not about any one question.

STEP 5. Apply the rule exactly, in this order. The first that fits is the
verdict; every card gets exactly one.
Here the deadline is extended_to if set, otherwise reply_by.
not ready: the vendor declined any question; notice names no channel or no
number of hours; any question still has no answer once the deadline has passed;
or update_path is fetched on launch and can_pin is no. A hosted service that
changes underneath us with no version to hold does not trip this last trigger on
its own, because nearly every hosted product works that way and a rule that
failed all of them would tell us nothing; for those, reach and notice carry the
weight.
incomplete: the deadline hasn't passed and any question has no answer yet, or
our_owner is not a named person. List each missing question's key in missing,
and draft a short follow-up asking for those answers by name.
ready with conditions: every question answered, but any answer has null
evidence. List each as a condition: the question's key and the vendor's words.
ready: every question answered with evidence.

RULES YOU DO NOT BREAK
1. Do not answer any question on the vendor's behalf, from public information or
   from what similar products usually do. What you find yourself goes in
   public_pointer, never in answer, and in evidence only when the vendor's own
   reply points to it.
2. Do not upgrade a verbal answer to evidence, and do not record a refusal as a
   missing answer or a missing answer as a refusal.
3. Do not soften "not ready", and do not call a card ready, with or without
   conditions, while any answer is missing.
4. Do not ask me for credentials, contracts in full, or internal security
   reports. The vendor's answers are enough.

OUTPUT
Valid JSON matching the schema vendor-update-card/v0.3 as published at
https://sigsub.show/takeaways/vendor-update-card/#the-answer-format. If you
can't read that page, use these keys, in this order: schema, product, vendor,
vendor_contact, our_owner, asked_on, reply_by, extended_to, review_by;
questions, holding update_path, can_pin, reach, release_checks, key_revocation
and notice, each with public_pointer, answer, evidence, declined; conditions, a
list, each with question and answer; missing, a list of question keys; verdict.
Then one sentence naming the question to raise first at the next renewal: the
first not-ready trigger in the order above, otherwise the first missing answer,
otherwise the first condition, otherwise update_path, since it changes with
every release.

What to check in the answer

It may look up the vendor's pages, draft the message and keep the record, because that's research and writing. It may never fill a vendor's answer from what it knows about the product, or count a promise as evidence. If the card comes back ready and the vendor hasn't replied, the model answered for them. If a question has no answer and the card says anything but incomplete or not ready, it skipped the catch-all. If a public_pointer reappears as an answer, or a SOC 2 badge sits in release_checks evidence, it did the same thing more quietly.

The part that's not optional

Name our_owner before you send anything. The answers age with every release, and an answer nobody owns is never asked again.

And check your own side too. The card covers what the vendor commits to. What's actually running on your machines is a different question, and Tim McAllister's Daily Patch Loop is one way to keep asking it.

{
  "schema": "vendor-update-card/v0.3",
  "product": "product and plan or edition",
  "vendor": "who ships it",
  "vendor_contact": "who you'd write to there, or null",
  "our_owner": "one named person",
  "asked_on": "YYYY-MM-DD",
  "reply_by": "YYYY-MM-DD",
  "extended_to": "YYYY-MM-DD or null",
  "review_by": "YYYY-MM-DD or null",
  "questions": {
    "update_path": { "public_pointer": null, "answer": null, "evidence": null, "declined": false },
    "can_pin": { "public_pointer": null, "answer": null, "evidence": null, "declined": false },
    "reach": { "public_pointer": null, "answer": null, "evidence": null, "declined": false },
    "release_checks": { "public_pointer": null, "answer": null, "evidence": null, "declined": false },
    "key_revocation": { "public_pointer": null, "answer": null, "evidence": null, "declined": false },
    "notice": { "public_pointer": null, "answer": null, "evidence": null, "declined": false }
  },
  "conditions": [
    { "question": "the question's key", "answer": "the vendor's words" }
  ],
  "missing": ["the key of each question with no answer yet"],
  "verdict": "ready | ready with conditions | incomplete | not ready"
}