TUE, SEPTEMBER 29, 2026
Independent · In‑Depth · Practitioner‑Tested
Claude Productivity

Six Prompts for Judging a Security Tool Nobody Has Run Yet

Nvidia published OpenShell under Apache 2.0 on 28 September at version 0.1.0, with more than 100 partners named. A hundred logos and a permissive licence are not evidence that it works, and a security dependency is the worst place to learn that. These six prompts pull apart what a new safety tool actually guarantees, what it only appears to guarantee, and what it costs you to find out.

⌨️ 6 prompts 🕐 Updated Sep 29, 2026
💡 How to use these prompts: Replace everything in [BRACKETS] with your specific details before sending. Click Copy to copy any prompt to your clipboard instantly.
1
Separate the Guarantee From the Marketing
Security announcements are written to be read generously. This forces a strict reading first.
Below is the documentation and announcement material for a security tool I am considering.<br/><br/>Produce two lists.<br/><br/>LIST A - what the tool actually guarantees. Only claims that are specific, testable, and stated as properties of the system.<br/><br/>LIST B - what the material implies without guaranteeing. Include anything that relies on the reader assuming a stronger claim than the words support.<br/><br/>For every item in List B, write the narrower sentence the vendor would have used if they had to defend it.<br/><br/>MATERIAL:<br/>[paste]
2
Name the Threat Model It Does Not Cover
Every control has a shape. Knowing where it stops is more useful than knowing what it covers.
Here is the documentation for a security tool.<br/><br/>Infer the threat model it is built for, then tell me what it explicitly does not protect against.<br/><br/>Structure it as: attacker capability, whether this tool stops it, and if not, what else in my stack would have to.<br/><br/>Cover at minimum: a compromised host OS, a malicious dependency inside the workload, a legitimate credential being used for an illegitimate action, and an insider with deployment access.<br/><br/>End with the single attack this tool is worst at, stated plainly.<br/><br/>DOCS:<br/>[paste]
3
Pressure-Test a Version 0.x
Question 4 is the one people skip. A security tool with no vulnerability disclosure process of its own is a warning.
This tool is at version [x]. Below is its changelog, issue tracker and commit history.<br/><br/>Assess maturity on evidence, not on the version number:<br/>1. Are there breaking changes between recent minor versions, and how were they communicated?<br/>2. How quickly are security-labelled issues closed, and are they closed with fixes or with explanations?<br/>3. How many distinct contributors, and does it survive the busiest one leaving?<br/>4. Is there a documented process for reporting a vulnerability in the tool itself?<br/><br/>Then tell me what would have to be true in six months for this to be safe to depend on.<br/><br/>REPOSITORY DATA:<br/>[paste]
4
Work Out What the Partner List Means
"More than 100 partners" is a real signal and a soft one. This tells you which.
A vendor announcement names [N] partner organisations, listed below.<br/><br/>For each named partner, classify the likely relationship: shipping it in production, integrating it as an option, reselling it, co-marketing only, or unclear from the material.<br/><br/>Then tell me which classification the announcement wants me to assume, and how many partners I can actually evidence in the strongest category.<br/><br/>PARTNERS AND ANNOUNCEMENT:<br/>[paste]
5
Cost the Hardware Dependency
Open source plus required hardware is a common shape. Point 3 is the one that bites later.
This tool has an open-source component and a component requiring specific vendor hardware. Details below.<br/><br/>Tell me:<br/>1. Exactly which guarantees I lose if I adopt only the open part.<br/>2. Whether the open part is genuinely useful alone, or is a funnel toward the hardware.<br/>3. What it would cost to move off this vendor in two years - data, config, operational knowledge, and anything that becomes load-bearing quietly.<br/>4. Whether an equivalent guarantee exists from a vendor I already buy from.<br/><br/>DETAILS:<br/>[paste]
6
Design the Trial That Would Actually Tell You
Writing the day-15 decision in advance is what stops a trial becoming an adoption.
I want to evaluate this security tool in a two-week trial.<br/><br/>Design the trial so it produces a decision rather than a good feeling. Include:<br/>- the specific attack or failure I will attempt, and what success and failure look like<br/>- what I will measure that is not the vendor's own metric<br/>- the performance cost under realistic load, measured not assumed<br/>- what I do on day 15 in each outcome, written now, before I am invested<br/><br/>Flag anything I cannot test in two weeks, so I know what I am accepting on trust.<br/><br/>CONTEXT:<br/>[paste your environment]