What a GenAI Security RFP Should Accomplish

The RFP is not a list of AI buzzwords. Its job is to help a cross-functional buying team determine whether a product or service can reduce defined risks without introducing unacceptable architectural, privacy, operational, or commercial risk.

At minimum, the evaluation should establish:

• which GenAI applications, agents, models, APIs, tools, data stores, retrieval systems, and environments are in scope;
• which risks are mandatory pass/fail requirements and which are weighted differentiators;
• what evidence the vendor must provide for every material claim;
• how security works at runtime, not only in a policy console or model test;
• how sensitive prompts, outputs, traces, logs, and samples are collected, stored, masked, retained, and deleted;
• how the product integrates with identity, gateways, application stacks, SIEM, incident response, and governance workflows;
• what happens when the product, model provider, policy service, or network dependency fails;
• what a bounded proof of value must prove before a production decision.

Define Your GenAI Application Scope Before Sending the RFP

Two organizations can both say they are “securing GenAI” while needing completely different controls. A public chatbot that answers documentation questions has a different risk profile from an autonomous finance agent that can issue refunds, change records, or export customer data.

This scope should be attached to the RFP. Otherwise vendors can answer against the easiest interpretation of “AI security,” making responses impossible to compare.

GenAI Application Security RFP Requirements Checklist

1. AI asset and dependency visibility

• Discover or ingest an inventory of GenAI applications, model endpoints, agents, tools, APIs, retrieval services, and data flows.
• Identify owners, environment, model/provider, reachable tools, privileges, and sensitive-data exposure where technically available.
• Show how inventory is updated when applications, endpoints, models, or tool connections change.
• Distinguish observed runtime activity from configuration-only or manually entered inventory.

2. Prompt injection and instruction-boundary controls

• Explain what the product detects for direct and indirect prompt injection.
• Demonstrate how untrusted retrieved content, files, webpages, tool output, and user input are handled.
• Describe whether detection operates before the model, after the model, around tool use, or at several stages.
• Show false-positive handling, evidence, confidence, and policy tuning rather than only a binary “blocked prompt” result.

3. Agent and tool authorization

• Support dedicated identities or traceable context for agents and automated workflows.
• Enforce least privilege by tool, endpoint, method, object, tenant, environment, and action sensitivity where applicable.
• Provide allow/deny controls for high-risk tools and state-changing actions.
• Support human approval or step-up controls for actions such as payment, deletion, permission change, bulk export, or external sharing when required by the customer.
• Preserve end-user authorization context instead of silently elevating an agent through a broad service account.

4. API and application-layer protection

• Inspect the APIs that connect AI applications to models, tools, retrieval services, and business systems.
• Validate methods, paths, headers, parameters, bodies, schemas, tokens, and relevant response data.
• Detect authorization abuse, enumeration, replay, automation, abnormal sequence behavior, and excessive data access where in scope.
• Show how the security layer coexists with API gateways, WAFs, identity systems, service meshes, and application authorization.

5. Output and downstream-action safety

• Do not assume model output is trusted simply because the model generated it.
• Validate structured outputs before they become database queries, API calls, commands, URLs, code, or workflow parameters.
• Demonstrate controls for unsafe rendering, injection into downstream systems, and unintended tool invocation.
• Separate content-safety controls from application authorization and business-action policy.

6. Sensitive data and secrets

• Identify sensitive information in prompts, retrieval context, API requests, tool calls, and responses where supported.
• Detect secrets, tokens, credentials, and prohibited data sent to model providers or external services.
• Support masking or minimization appropriate to customer policy.
• Explain whether raw sensitive payloads are stored by the security product and under what controls.

Architecture and Deployment Evaluation Criteria

Security efficacy is not enough if the product cannot fit the production path safely. Require a reference architecture for each deployment mode you may use.

Ask vendors to state what they cannot inspect or enforce. A clear limitation is more useful than an ambiguous “supports all GenAI applications” claim.

Data Governance, Privacy, and Model-Provider Questions

GenAI security products may process some of the most sensitive content in the organization: prompts, source documents, retrieval context, API payloads, agent traces, and model responses. Treat the security product as part of the data architecture.

• Collection: exactly which payload fields, prompts, outputs, embeddings, metadata, and traces are collected?
• Storage: where is data stored and in which regions or customer-controlled environments?
• Retention: what are default and configurable retention periods?
• Training: is customer data used to train, fine-tune, evaluate, or improve vendor models or services? Require contractual clarity.
• Subprocessors: which model providers, analytics services, or subprocessors receive customer data?
• Encryption: how is data protected in transit and at rest, and how are keys managed?
• Access: which vendor and customer roles can view raw prompts, outputs, payloads, and security evidence?
• Deletion: how is tenant data deleted at end of retention, contract, or customer request?
• Masking: can investigations preserve evidence without unnecessarily exposing sensitive values?

NIST’s GenAI Profile is useful here because it treats GenAI risk across the lifecycle and includes risks that extend beyond classic application vulnerabilities. The RFP should therefore cover both cybersecurity controls and broader data/governance requirements relevant to your use case.

Runtime Detection and Enforcement Requirements

Pre-deployment testing matters, but GenAI applications change at runtime: models are upgraded, prompts evolve, retrieval content changes, new tools appear, permissions drift, and agents choose different sequences. Ask how the product observes and constrains live behavior.

For agentic systems, runtime evaluation should include the API action surface. An agent may receive a benign-looking prompt but still call a sensitive export API, modify a permission, or combine several individually allowed tools into an unsafe workflow. See AI agent API security risks for the API-layer control model.

Security Operations and AI Governance Criteria

A production security control must fit the team that will operate it. Include SOC, AppSec, platform engineering, AI engineering, privacy, and governance stakeholders in scoring.

• Export structured events to the organization’s SIEM or security data platform.
• Include enough context to reconstruct the AI action: user/identity, agent, model, tool, endpoint, request, response, data sensitivity, sequence, policy, and enforcement result where available.
• Support investigation without requiring security analysts to become prompt engineers.
• Define alert ownership, suppression, tuning, exception approval, and policy-change audit trails.
• Expose product health, dropped traffic, inspection gaps, and failed integrations.
• Support evidence export for risk reviews, incidents, audits, and governance reporting.
• Document model/detection changes that could materially alter security behavior.

NIST’s AI RMF organizes suggested risk-management work around Govern, Map, Measure, and Manage. That structure can help ensure the RFP covers governance and measurement as well as technical blocking.

Example GenAI Security RFP Scorecard

Adjust weights to your risk. A tool-facing autonomous agent should give more weight to authorization, action control, and runtime monitoring than a low-risk internal drafting assistant.

Use pass/fail gates separately from the weighted score. A vendor should not compensate for a failed privacy boundary or unsupported deployment requirement by scoring highly on dashboards or analytics.

Proof-of-Value Tests to Put in the RFP

Require a bounded proof of value for the highest-risk assumptions. Use representative but controlled applications and data. Define success before the test begins.

1. Inventory test: identify the known GenAI application, its model endpoint, agent/tool calls, relevant APIs, and at least one change introduced during the test.
2. Prompt injection test: exercise direct and indirect manipulation using an approved scenario and inspect evidence, false positives, and response.
3. Tool misuse test: attempt a prohibited or out-of-scope tool/API action and verify the expected control.
4. Authorization test: verify that changing an object, tenant, or user context does not become authorized simply because the agent can construct the request.
5. Sensitive data test: return controlled synthetic sensitive fields and confirm detection, masking, policy, and logging behavior.
6. Sequence test: create an unusual but syntactically valid tool/API sequence and verify behavioral evidence.
7. Failure test: remove a dependency or security component and verify documented fail-open/fail-closed or degraded-mode behavior.
8. Performance test: measure representative latency and resource impact rather than accepting a generic benchmark.
9. SOC test: send events to the real SIEM and have an analyst reconstruct the scenario from the evidence.
10. Change test: add or modify a tool, endpoint, route, or model workflow and verify how quickly visibility and policy adapt.

For a broader procurement methodology, Ammune’s API security vendor evaluation guide uses the same evidence-first principle for runtime security selection.

High-Value Questions to Ask Every Vendor

1. Which parts of our architecture can you actually inspect, and which remain blind spots?
2. Which controls are deterministic policy and which depend on probabilistic detection or model classification?
3. Can you show the exact evidence behind a high-risk finding?
4. How do you distinguish a malicious prompt from a legitimate prompt that happens to contain security-sensitive language?
5. How do you follow an agent from user/task context through tool calls and API actions?
6. What happens if the model, policy service, SaaS control plane, or network connection is unavailable?
7. Can we deploy without sending raw prompts, API payloads, or sensitive response data outside our approved boundary?
8. How do you prevent the security product itself from becoming a high-value repository of sensitive AI data?
9. How are false positives measured, tuned, and reviewed before enforcement?
10. Which OWASP GenAI 2026 risks do you address directly, indirectly, or not at all?
11. How do you map to NIST AI RMF / NIST AI 600-1 and secure-development practices without claiming compliance that the framework does not certify?
12. What can we export if we leave the platform, and how is our data deleted?

How Ammune Can Be Evaluated in a GenAI Security RFP

Ammune is most relevant to the runtime API layer around GenAI applications and agents. It can be evaluated for visibility into API traffic, agent-driven tool calls, request and response inspection, sensitive-data exposure, behavioral anomalies, high-risk API actions, runtime policy enforcement, forensics, and SIEM-ready evidence.

It should be assessed alongside—not as a replacement for—model-provider safety controls, secure model/application development, identity, application authorization, data governance, AI governance, gateways, cloud controls, and human approval for sensitive business actions.

For agent-specific architecture, see agentic AI API security for tools and workflows. For production visibility requirements, see API visibility for AI agents and the API runtime security platform guide.

Frequently Asked Questions