Alright, let's cut through the hype. Everyone's slapping "AI" on their product and expecting us to trust it with our data pipelines and customer interactions. We're evaluating a new Claw runtime for some internal processing workloads. The vendor's security deck is all rainbows and "enterprise-grade security," which means precisely nothing.
I want to pressure-test this thing against the OWASP AI Security & Privacy Guide, specifically their Top Ten for LLMs. But mapping those abstract risks to a concrete, scoreable rubric for a *runtime* is trickier than it looks. The OWASP list is great for app developers, but we're procuring an infrastructure component.
Has anyone built an actual evaluation scorecard for something like this? I'm talking about a spreadsheet or a checklist you can run a vendor through during a POC. I'm less interested in theoretical risks and more in "show me the controls."
For example, how are you operationally testing for:
* **AI01: Prompt Injection** - Can the runtime isolate and log prompt processing? Does it have any semblance of a sandbox that limits system command execution from a successful injection? Or are we just hoping the model behaves?
* **AI02: Insecure Output Handling** - If this runtime is feeding outputs to downstream systems (APIs, databases), what mechanisms exist to validate/scrub those outputs before they're passed on? Is it just a dumb pipe?
* **AI03: Training Data Poisoning** - For a runtime, this might translate to: how are base model artifacts verified and integrity-checked before deployment? What's the chain of custody from their source to our cluster?
* **AI04 & AI05: Model Denial of Service & Supply Chain Vulnerabilities** - This is where old-school sysadmin thinking applies. What's the resource isolation? Can a malicious payload in one request hog all GPU memory and starve other tenants? How are dependencies (libraries, model files) scanned for CVEs?
My starting point is a heavy modification of a standard software procurement rubric, but I'm adding weighted sections for these AI-specific concerns. I'm also demanding demonstrable evidence during the technical deep-dive, not just a "yes we have that" on a questionnaire.
I'll share my draft template below if folks are interested, but I'm really looking to see if anyone has already been down this road and has a battle-tested format. What did you ask? What did the vendors actually struggle to demonstrate? What turned out to be more important in practice than on paper?
Oh, this is exactly the kind of thing I need to learn about. When you ask about > "show me the controls," it makes me wonder, how do you even get a vendor to demonstrate that stuff during a demo? Every POC I've been in just shows the happy path.
For something like prompt injection testing in a runtime, wouldn't you have to set up a deliberate, broken prompt in your trial environment? I'd be worried about breaking something and getting billed for it.
Just my two cents.
I haven't built a full scorecard, but I've done this with a WASM runtime vendor. Your mapping is correct: you treat the runtime as the "application" that needs to expose controls.
For AI01, demand their logging format and see if you can trace a raw prompt through to the final execution context. If they can't show you that in the POC, walk away.
The practical test is to ask them to simulate a failure. Tell them to demonstrate a mitigated prompt injection attempt and show you the alert and where it landed in their audit trail. No demo theater. If they refuse, you have your answer.