A platform for building AI agents decides how every agent your teams create will authenticate, what tools it can call, what data it can read and who can stop it, so the security questions have to be in the request for proposal, not left for after go-live. This template is for buying a platform to build and run agents (low-code builders, agent frameworks offered as a managed service, and enterprise agent studios); it is not for buying a tool to secure agents, which is covered by the AI Agent Security Platform RFP. Requirements are numbered, typed and written so answers can be tested and scored, with a proof of concept plan at the end. It is vendor-neutral and draws on the OWASP Top 10 for LLM Applications 2025, the NIST AI Risk Management Framework, the NCSC Guidelines for Secure AI System Development and the CSA AI Controls Matrix. It is written for security architects, AI platform owners, procurement and evaluation panels. For how these platforms work and where they fail, read the Low-Code Agent Platforms Guide first.
How to use this template
- Replace text in square brackets, such as [Organisation], [identity provider], [SIEM] and [number], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example APR-IDN-01) and a type: M mandatory (pass or fail), S scored (0 to 5) or I informational. Keep M items few; the identity, autonomy and audit controls in sections 4.1, 4.3 and 5 are the strongest candidates.
- Write down two or three representative agents you intend to build before issue (Appendix A), for example a customer service agent with read access to a CRM, an internal IT agent that can reset passwords, and a coding agent. Bidders must answer against these, and the proof of concept builds them.
- Weights in brackets are illustrative. Fix them before responses arrive.
- Issue sections 1 to 8 to bidders. Implementation guidance is for the panel only. Ask for responses in a spreadsheet with one row per requirement ID and a column for evidence.
1. Purpose and scope
[Organisation] invites proposals for a platform on which [business units / developers / citizen developers] will design, build, test, deploy and operate AI agents that use large language models, call tools and APIs, and act on [Organisation] systems and data. The platform will support approximately [number] builders and [number] agents in production within [period]. In scope: the agent builder or SDK, model access, tool and connector framework, memory and retrieval, runtime and hosting, guardrails, human approval, logging and administration. Out of scope: separate agent security posture or detection tools, and model training, unless offered as an option in section 7.
2. Current state and intended use
- Identity: [identity provider], [privileged access tool], [secrets manager], [workload identity method in cloud].
- Systems agents will reach: [CRM], [ITSM], [ERP], [document stores], [code repositories], [cloud accounts].
- Security tooling: [SIEM], [DLP], [API gateway or AI gateway].
- Constraints: data residency [region], regulatory obligations [list, for example EU AI Act, sector rules], approved model providers [list or none].
- Appendix A agents: [describe two or three target agents, their data and their actions].
3. Instructions to bidders
- Answer each requirement as Met, Met with configuration, Roadmap (with date) or Not met, and attach evidence: documentation link, screenshot, configuration export or third-party report.
- State which features need a higher licence tier or add-on, in one availability note per section.
- Name every model the platform uses by default, who hosts it, and whether [Organisation] can bring its own model endpoint.
- Shortlisted bidders must take part in the proof of concept in section 8 using the Appendix A agents.
4. Security requirements
4.1 Agent identity and credentials
| ID | Requirement | Type |
|---|---|---|
| APR-IDN-01 | Every agent has its own unique, non-human identity that appears in [identity provider] or can be registered there, with a named human owner and a creation record. | M |
| APR-IDN-02 | Agents can authenticate to downstream systems with short-lived credentials (OAuth 2.0 client credentials, token exchange or cloud workload identity federation); describe each method supported. | S |
| APR-IDN-03 | Where static secrets are unavoidable, they are held in [secrets manager] or an encrypted platform store, never in prompts, agent instructions or builder-visible fields; describe rotation and revocation. | M |
| APR-IDN-04 | Supports acting on behalf of a signed-in user with that user's delegated, scoped permissions, distinct from the agent's own identity, and records which applied to each action. | S |
| APR-IDN-05 | An agent's credentials can be disabled in one action, revoking all tokens and stopping in-flight runs; state the time to take effect. | M |
| APR-IDN-06 | Lists all agents, their identities, owners, connectors and last activity via API for inventory and access review. | S |
See the Agent Identity and Access Guide and Secrets in Prompts.
4.2 Authorisation, tools and connectors
| ID | Requirement | Type |
|---|---|---|
| APR-TOL-01 | Each tool or connector an agent can call is declared explicitly, with its scopes, and an agent cannot call a tool that is not in its declaration (OWASP LLM06:2025 Excessive Agency: excessive functionality). | M |
| APR-TOL-02 | Connector permissions can be restricted to read-only, to named operations and to named resources; describe the granularity per connector type. | S |
| APR-TOL-03 | Administrators can maintain an allowlist of approved connectors, Model Context Protocol (MCP) servers and external APIs, and block builders from adding others. | M |
| APR-TOL-04 | Describe how remote MCP servers and custom tools are authenticated, how their tool descriptions are reviewed and how changes to a tool after approval are detected. | S |
| APR-TOL-05 | Policy decisions for sensitive tools can be delegated to an external policy engine or [Organisation] API gateway. | I |
| APR-TOL-06 | Agent to agent calls are authenticated and each agent's permissions are enforced independently; a calling agent cannot inherit a callee's rights. | S |
See the AI Agent Authorisation Guide, the MCP Security Guide and the Multi-Agent and A2A Security Guide.
4.3 Human oversight and autonomy controls
| ID | Requirement | Type |
|---|---|---|
| APR-AUT-01 | Approval steps can be required per tool or per action type (for example payments, deletions, external email, permission changes), and the model cannot skip or approve its own request (OWASP LLM06:2025: excessive autonomy). | M |
| APR-AUT-02 | Approvers see the proposed action, its parameters and the context that led to it before approving. | S |
| APR-AUT-03 | Limits can be set on steps per run, tool calls per run, spend and run time, with the agent stopped when a limit is reached (OWASP LLM10:2025 Unbounded Consumption). | M |
| APR-AUT-04 | A platform-wide and per-agent stop control halts all runs and blocks new ones; demonstrate it. | M |
| APR-AUT-05 | Agents can be promoted from test to production only through an approval workflow with a named reviewer. | S |
See the Human-in-the-Loop for AI Agents Guide and the AI Agent Kill Switch and Containment Guide.
4.4 Prompt injection, output handling and guardrails
| ID | Requirement | Type |
|---|---|---|
| APR-GRD-01 | Describe the controls against direct and indirect prompt injection from user input, retrieved documents, web pages, emails and tool results (OWASP LLM01:2025 Prompt Injection), and the testing performed, with results. | M |
| APR-GRD-02 | Model output passed to tools, code, queries or web pages is validated or encoded by the platform before use (OWASP LLM05:2025 Improper Output Handling). | S |
| APR-GRD-03 | Input and output filters for sensitive data (for example personal data, secrets, payment card numbers) are configurable per agent, with [Organisation] patterns. | S |
| APR-GRD-04 | Agent system instructions are treated as non-secret by design, and the platform documents that credentials and access decisions must not rely on them (OWASP LLM07:2025 System Prompt Leakage). | I |
| APR-GRD-05 | Guardrail policies are versioned, testable before release and cannot be disabled by builders without administrator approval. | S |
See the Prompt Injection Guide.
4.5 Memory, knowledge and data handling
| ID | Requirement | Type |
|---|---|---|
| APR-DAT-01 | Retrieval respects the source system's permissions for the requesting user, so an agent cannot surface documents the user could not open (OWASP LLM08:2025 Vector and Embedding Weaknesses). | M |
| APR-DAT-02 | Long-term agent memory is scoped per user, per agent or per tenant as configured, can be inspected and deleted, and has a retention setting. | S |
| APR-DAT-03 | Describe controls that stop untrusted content being written to memory or knowledge stores and later treated as instructions. | S |
| APR-DAT-04 | State whether [Organisation] prompts, outputs, files or memory are used to train or improve any model, and provide a contractual opt-out (OWASP LLM02:2025 Sensitive Information Disclosure). | M |
| APR-DAT-05 | State where prompts, outputs, memory, embeddings and logs are processed and stored, including model hosting regions and sub-processors. | M |
See the AI Agent Memory Security Guide.
4.6 Code execution and sandboxing
| ID | Requirement | Type |
|---|---|---|
| APR-EXE-01 | Code generated or run by agents executes in an isolated sandbox with no access to platform credentials, the host or other tenants; describe the isolation technology. | M |
| APR-EXE-02 | Sandbox network egress is denied by default and can be allowlisted per agent. | S |
| APR-EXE-03 | Sandbox CPU, memory, run time and file system are limited and reset after each run. | S |
See the AI Agent Sandboxing and Code Execution Guide.
4.7 Builder governance and supply chain
| ID | Requirement | Type |
|---|---|---|
| APR-GOV-01 | Builder roles separate who can create agents, who can connect them to production data, who can publish them and who administers the platform. | M |
| APR-GOV-02 | Agents, prompts, tool definitions and guardrails are version-controlled with change history, and can be exported to [Organisation] source control. | S |
| APR-GOV-03 | Provide a list of third-party models, libraries, plugins and templates in the platform, with provenance and update process (OWASP LLM03:2025 Supply Chain). | S |
| APR-GOV-04 | Agents shared outside the builder's team, or to external users, require security review; describe how sharing is controlled. | S |
| APR-GOV-05 | Describe how the platform supports evaluation and red teaming of agents before release, including regression tests after model changes. | S |
5. Logging, audit and monitoring
| ID | Requirement | Type |
|---|---|---|
| APR-AUD-01 | Logs every run with agent identity, user on whose behalf it acted, model and version, prompts and retrieved context references, tool calls with parameters and results, approvals and errors. | M |
| APR-AUD-02 | Logs stream to [SIEM] in a documented format and are protected from change by builders and agents. | M |
| APR-AUD-03 | Administrative events (new agent, new connector, permission change, guardrail change, publication) are logged separately and retained for [period]. | M |
| APR-AUD-04 | Alerts on anomalies such as a spike in tool calls, calls to new destinations, repeated guardrail blocks or approval bypass attempts. | S |
| APR-AUD-05 | A full run can be replayed or reconstructed for incident investigation. | S |
See the AI Agent Audit Log Schema Template and the AI Agent Observability and Incident Response Guide.
6. Platform security, assurance and hosting
| ID | Requirement | Type |
|---|---|---|
| APR-PLT-01 | Administrator and builder access uses [Organisation] SSO with phishing-resistant MFA, and SCIM or equivalent for joiners, movers and leavers. | M |
| APR-PLT-02 | Provide current independent assurance (for example SOC 2 Type II report or ISO/IEC 27001 certificate with scope) and state any ISO/IEC 42001 certification. | S |
| APR-PLT-03 | Describe the secure development practice for the platform against the four areas of the NCSC Guidelines for Secure AI System Development: secure design, development, deployment, and operation and maintenance. | I |
| APR-PLT-04 | Map the platform's controls to the CSA AI Controls Matrix or NIST AI RMF functions (Govern, Map, Measure, Manage), and state where responsibility sits with [Organisation]. | I |
| APR-PLT-05 | State tenant isolation, encryption at rest and in transit, customer-managed key options and private network connectivity options. | S |
| APR-PLT-06 | Notify [Organisation] of security incidents affecting its data within [hours], and of default model changes [days] in advance. | M |
Platform requirements can be checked again after go-live with the Agent platform health check; supplier questions beyond this RFP are in the AI Vendor Security Questionnaire Template.
7. Services, support, pricing and exit
- Onboarding: implementation plan, builder training, and the security configuration steps [Organisation] must complete.
- Support: severity definitions and response times, including for an agent taking unintended actions.
- Pricing: price at [current], [2x] and [5x] usage, stating the unit (builders, agents, runs, model tokens or compute) and how spend limits work.
- Exit: export of agent definitions, prompts, tool definitions, memory, knowledge stores and logs in documented formats, and confirmed deletion of [Organisation] data within [days].
8. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
|---|---|---|
| Agent identity and credentials (4.1) | [15%] | Agents built in the proof of concept, identity provider records |
| Authorisation, tools and oversight (4.2, 4.3) | [20%] | Live demonstration of scopes, approvals, limits and stop control |
| Guardrails, data and sandboxing (4.4 to 4.6) | [15%] | Injection test results, retrieval permission test |
| Governance and audit (4.7, 5) | [15%] | Exported logs and version history |
| Builder fit and functionality | [15%] | Time to build Appendix A agents |
| Assurance and cost over the term (6, 7) | [20%] | Reports, pricing at three volumes |
Scores use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration; 5 met fully and demonstrated. Shortlisted bidders run a [four]-week proof of concept:
- Build the Appendix A agents with their own identities and short-lived credentials, then show them in [identity provider].
- Attempt a tool call outside an agent's declaration and an action that needs approval; record whether each is blocked.
- Feed [five] documents and tool results containing embedded instructions and record whether behaviour changes.
- Ask a retrieval agent for a document the test user cannot open in the source system.
- Trigger step and spend limits, then use the stop control mid-run and confirm tokens are revoked.
- Export the full log and check that every action traces to an agent identity, user, model version and approval.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Agree scope with the right buyer: this RFP buys the build platform. If the goal is visibility and control across agents built on many platforms, use the AI Agent Security Platform RFP instead, or run both.
- Write Appendix A first: real agents with real data make answers comparable. Include one agent with write actions on a sensitive system.
- Use dedicated trial credentials: issue least-privilege, time-limited credentials and test data for the proof of concept, and revoke them at the end.
- Weight identity and oversight above features: builder experience improves quickly; the identity model and audit design are hard to change after hundreds of agents exist.
- Small vs large organisations: a small organisation may accept platform-native identity and logging if export is reliable; a large one should require integration with [identity provider], [secrets manager] and [SIEM] as mandatory.
- Govern after purchase: adopt the Agentic AI Security Policy Template, threat model each agent before production, and review agents, owners and connectors quarterly.
Standards and references
- OWASP: Top 10 for LLM Applications 2025
- OWASP: Top 10 for Agentic Applications for 2026
- NIST: AI Risk Management Framework
- NCSC: Guidelines for Secure AI System Development
- Cloud Security Alliance: AI Controls Matrix
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Securing the agent platform itself · Securing Agent Frameworks Guide · Security Vendor Evaluation and RFP Guide · AI Agent Threat Modelling Guide