Skip to content
Our procurement che...
 
Notifications
Clear all

Our procurement checklist for AI agent platforms - sharing the security clauses we added.

4 Posts
4 Users
0 Reactions
0 Views
(@lisat)
Eminent Member
Joined: 1 week ago
Posts: 19
Topic starter   [#4805]

Hi everyone. I’ve been lurking here for a while, reading all the discussions on SAST and supply chain security—thank you, it’s been incredibly helpful. I’m coming from a customer support and CRM background, and my team is now evaluating AI agent platforms for automating parts of our helpdesk workflow.

This process has been eye-opening, especially from a security standpoint. Our procurement team gave us a standard vendor checklist, but after reading through AppSec threads, we realized it was completely inadequate for an AI platform that will handle customer data.

I wanted to share some of the specific security clauses we ended up adding to our checklist, in case it helps others in a similar spot. We focused heavily on data handling, model behavior, and integration points.

**Data & Privacy**
* Explicit requirement that all customer data processed by the AI agent is excluded from model training or improvement by the vendor, by default.
* Contractual guarantee of data residency and a clear map of all subprocessor APIs (e.g., which LLM provider is behind the agent, where their inference happens).
* Right to audit logs of prompts and responses for a given timeframe, to investigate potential data leakage or misuse.

**Operational Security**
* Mandatory secret scanning for any API keys or credentials that the agent platform requires us to store for integrations (like our CRM or ticketing system).
* Support for our own private, encrypted connections (private link/VPC) rather than just public API endpoints.
* Detailed incident response protocol that includes notification timelines specific to a prompt/data leak, not just a system outage.

**Supply Chain & Integrity**
* A software bill of materials (SBOM) for the platform’s own components, and notification process for vulnerabilities in any upstream dependencies (including the base LLM).
* Assurance of version control and rollback capabilities for any agent behavior updates, so a vendor update doesn’t silently change how the agent handles sensitive queries.

We’re still finalizing things, and I’m sure we’ve missed aspects. Has anyone else gone through this? I’m particularly unsure about what “supply chain” checks even mean for a hosted AI agent service beyond the SBOM ask. Any advice would be greatly appreciated.



   
Quote
(@ci_cd_plumber)
Reputable Member
Joined: 3 months ago
Posts: 156
 

Good start, but you're missing the operational mechanics. That "right to audit logs" clause is useless if they dump a million unsearchable JSON files on you in 48 hours.

Make them specify the format, delivery method (like a secure S3 bucket), and retention period in the contract. Also, define what constitutes a "log event" - is it just the final prompt/response, or does it include the reasoning trace and tool calls? You need the full chain for a real investigation.


Build once, deploy everywhere


   
ReplyQuote
(@ci_cd_mechanic_7)
Estimable Member
Joined: 3 months ago
Posts: 108
 

Right. Your "explicit requirement" about training data is a good start, but you need to make it operational. That clause is meaningless without a technical enforcement mechanism.

Demand they detail how the exclusion is enforced at the API or infrastructure level. Is it a flag sent with every request? Is the data physically segmented? Get the engineering spec, not just a policy statement.

Also, tie the audit log right to that data. You need to be able to verify exclusion happened for any given log entry. Otherwise it's just a promise.



   
ReplyQuote
(@joshuam)
Trusted Member
Joined: 1 week ago
Posts: 35
 

Exactly. You need the schema. I'd push for a `data_retention_policy` field in every API call's metadata, with enumerated values like `NO_STORAGE`, `TRANSIENT_PROCESSING`, `OPT_IN_TRAINING`. Then you can query the audit logs for `metadata.data_retention_policy != 'OPT_IN_TRAINING'`.

Without that, you're just trusting their pipeline logic, and you can't prove anything post-incident.



   
ReplyQuote