Write the AI section of a security tool requirements document as testable statements, each with a way to verify it: "the tool lists model files found in repositories, with format and hash", not "the tool supports AI". Group them under inventory, agent tools, permissions, data handling and evidence.
Why testable wording matters
A requirement you cannot test becomes a promise you cannot enforce. Vendors answer vague requirements with yes. Specific ones force a demonstration, and a demonstration is what you need.
Use the form: the tool shall do X, verified by Y. Keep each statement short enough to score as pass, partial or fail.
Five groups of requirements
Inventory
- The tool lists AI and ML libraries with versions and transitive dependencies. Verified by a seeded repository.
- The tool detects model files and records name, format and location. Verified by adding a file.
- The tool lists MCP servers configured in repositories and shared configuration. Verified by a test server.
Agent tools and MCP
- The tool shows the tools each server exposes. Verified by a test server.
- The tool alerts when a server's tools change after approval. Verified by changing one.
- The tool supports an approval record for new servers. Verified by a walkthrough.
Permissions and identity
- Each agent can be given a distinct identity. Verified by registering two agents.
- Access can be revoked and takes effect within a stated time. Verified live.
Data handling
- The vendor states whether customer code or data is sent to any model provider, and which one. Verified in writing.
- The vendor states retention for anything sent. Verified in the contract.
Evidence
- Records are exportable in an open format for a chosen past date. Verified by export.
- Retention of records matches your audit window. Verified in the contract.
Mark priorities
| Level | Meaning |
|---|---|
| Must | Fail ends the evaluation |
| Should | Fail lowers the score |
| Could | Tie breaker only |
Keep Must items to five or six. A list where everything is a must is a list where nothing is.
Keep the document alive
Date every revision. The MCP specification itself is versioned, and standards such as the NIST AI Risk Management Framework are under revision, so re-read your references when you refresh the document. Link each requirement to the control or policy it supports, which makes later audits easier. See AppSec RFP questions on AI features for question wording.
Try it yourself
The framework mapping demo shows how requirements and controls link to evidence. Use it as a model for tracing each of your requirements to a proof.
Click through it at your own pace, or open it full screen.
Safeguard publishes its capabilities and surfaces on its site, so a requirement list like this can be checked against it directly. You can also try the free scan at gold.safeguard.sh/scan.
Quick check
How long should the AI section be?
Ten to fifteen statements is usually enough. More than that suggests you are describing a product instead of a need.
Do we send the document to vendors?
Yes, early. Their answers show who reads requirements carefully and who replies with generalities.
Sources
Last reviewed: 19 October 2026.
