---
description: A 13-section AI security policy template for teams shipping LLM apps, with each clause mapped to OWASP LLM Top 10 risks and the gateway control enforcing it.
title: AI Security Policy Template for Teams Shipping LLM Apps
image: https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w1200/2026/10/ai-security-policy-template-for-teams-shipping-llm-apps-bifrost-1920x1080.png
---

Try Bifrost Enterprise free for 14 days. [Request access](https://www.getmaxim.ai/#enterprise-trial)

**TL;DR**

- An AI security policy for LLM applications needs 13 sections, from data classification and approved providers to tool permissions and incident response.
- Each section maps to OWASP Top 10 for LLM Applications 2026 risks and a NIST AI RMF function.
- A policy clause is enforceable only when a runtime control backs it; in Bifrost those controls are virtual keys, budgets, guardrails, tool allow-lists, and audit logs.
- Model access, MCP tool access, and agent access are separate grants in Bifrost, so a policy can limit excessive agency at every hop.
- Data and model poisoning, vector store weaknesses, and misinformation need controls outside the gateway, with named owners.

An AI security policy is a written set of rules that defines which data, models, tools, and agents an organization's AI systems may use, who approves them, and how compliance is proven. The templates ranking for this topic mostly govern employees using chat tools, not engineering teams whose LLM applications send customer data to providers, call MCP tools, and delegate to other agents. This template is for those teams, and pairs each clause with the runtime control that enforces it in [Bifrost](https://www.getmaxim.ai/), the [open-source AI gateway](https://github.com/maximhq/bifrost) built by Maxim AI for enterprise model, tool, and agent traffic.

## What Is an AI Security Policy?

An AI security policy is a governing document that sets how AI systems handle data, which models, tools, and agents they may use, and how activity is logged and reviewed. For teams shipping LLM apps, it works like an application security standard, not an employee handbook.

An [AI acceptable use policy](https://www.getmaxim.ai/articles/enforce-ai-acceptable-use-policy/) governs people; this policy governs software: customer-facing apps, internal agents, and coding agents in CI. The two share one data classification scheme but are enforced in different places.

A rule such as "no restricted data is sent to third-party providers" cannot be enforced when a dozen services each hold their own provider keys. Routing all AI traffic through [the Bifrost AI gateway](https://www.getmaxim.ai/) gives the policy one enforcement point, as Figure 1 shows. That is the idea behind [moving AI governance from written policy to runtime enforcement](https://www.getmaxim.ai/articles/the-complete-guide-to-ai-governance-from-policy-to-runtime-enforcement/), and the model the [AI security resource page](https://www.getmaxim.ai/resources/ai-security) describes.

![](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/2026/10/image-42.png)

***Figure 1: Application, agent, and tool traffic crosses one enforcement point, so each policy clause is configured once instead of in every codebase.***

## AI Security Policy Template: Clause Map to OWASP and NIST

The template has 13 sections. Each addresses risks from the [OWASP Top 10 for LLM Applications 2026](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/), fits a function of the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) (Govern, Map, Measure, Manage), and names the gateway control that turns the clause into enforcement.

| # | Policy section | OWASP LLM Top 10 (2026) | NIST AI RMF | Bifrost control |
| --- | --- | --- | --- | --- |
| 1 | Purpose and scope | All | Govern | One gateway path for model, tool, and agent traffic |
| 2 | Roles and responsibilities | All | Govern | RBAC, SSO, data access control |
| 3 | Data classification | LLM02 Sensitive Information Disclosure | Map | Per-class virtual keys, required headers, routing rules |
| 4 | Approved models and providers | LLM04 Supply Chain | Govern | Provider and model allow-lists on virtual keys |
| 5 | Access control and keys | LLM06 Unbounded Consumption | Manage | Virtual keys, expiry, budgets, rate limits, secret management |
| 6 | Prompt injection and output handling | LLM01, LLM08 Hidden Context Exposure, LLM10 Improper Output Handling | Measure, Manage | Input and output guardrail rules |
| 7 | PII and secrets | LLM02 | Manage | PII Detection template, Secrets Detection, redaction modes |
| 8 | Tool, MCP, and agent permissions | LLM03 Excessive Agency | Manage | MCP tool filtering, MCP guardrails, agent grants |
| 9 | Logging and retention | All | Measure | Request logs, content logging controls, retention |
| 10 | Incident response | All | Manage | Key deactivation, alerting, audit logs |
| 11 | Vendor review | LLM04, LLM05 Data and Model Poisoning | Govern | Process control, outside the gateway |
| 12 | Exceptions | All | Govern | Scoped virtual keys with expiry |
| 13 | Review cadence | All | Govern | Guardrail monitor mode, audit log exports |

Three OWASP risks sit mostly outside the gateway: LLM05 Data and Model Poisoning (training pipelines), LLM07 Misinformation (grounding and human review), and LLM09 Vector and Embedding Weaknesses (retrieval store access). Sections 2 and 11 assign owners for them. For per-risk detail, see how to [cover each OWASP LLM Top 10 risk at the gateway](https://www.getmaxim.ai/articles/owasp-llm-top-10-how-to-cover-each-risk-at-the-gateway/); teams using the [NIST Generative AI Profile (NIST AI 600-1)](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence) can add its controls to the same columns.

## Sections 1-3: Scope, Roles, and AI Data Classification

The first three sections define what the policy covers, who owns each decision, and how data is classified before it reaches a model. Later sections depend on data classification, because provider approval, redaction, and logging rules all key off the data class.

### 1. Purpose and scope

> This policy applies to every application, agent, and pipeline operated by \[Organization] that prompts a language model, calls an MCP tool, or delegates to another AI agent. All such traffic passes through the approved AI gateway. Direct calls to model providers are prohibited.

**Enforced by:** [the Bifrost gateway](https://www.getmaxim.ai/) as the only holder of provider credentials, so a service that bypasses it has no key to call with. Employee AI use falls under the acceptable use policy; on company machines, [Bifrost Edge](https://www.getmaxim.ai/edge) extends the same gateway policies to desktop apps, browser AI, and coding agents. Edge is generally available and requires the Enterprise Gateway.

### 2. Roles and responsibilities

> The security team owns this policy. The platform team operates the AI gateway. Each application owner is accountable for their service's data classification, models, and tool permissions, and names owners for training data integrity, retrieval store access, and output review.

**Enforced by:** [role-based access control](https://docs.getbifrost.ai/enterprise/rbac) with system roles (Admin, Developer, Viewer) and custom roles such as Auditor, assigned through OIDC and SCIM 2.0 so roles follow the identity provider. Data access control scopes each role to its own, its team's, or the workspace's logs and keys.

### 3. Data classification

> Data sent to AI systems is classified as Public, Internal, Confidential, or Restricted.Public and Internal: any approved provider.Confidential: approved providers with a signed data processing agreement and no training on inputs; PII is redacted before transmission.Restricted (credentials, regulated health or payment data, national identifiers): self-hosted models only, or blocked.

**Enforced by:** a separate [virtual key](https://docs.getbifrost.ai/features/governance/virtual-keys) per data class, because a virtual key is deny-by-default for providers and can only reach the providers listed on it. [Required headers](https://docs.getbifrost.ai/features/governance/required-headers) can force every request to declare its class. A declared header is self-reported, so pair it with the guardrails in section 7 and [PII redaction before data reaches providers](https://www.getmaxim.ai/articles/pii-redaction-at-the-gateway-before-data-reaches-providers/).

## Sections 4-5: Approved Models, Providers, and Access Control

Sections 4 and 5 decide which models an application may call and with which credential. Both map to gateway configuration: a provider and model allow-list per virtual key, and a credential lifecycle with expiry, budgets, and rate limits.

### 4. Approved models and providers

> Only models on the approved list may be used. Adding a provider requires a vendor review (section 11). Provider API keys are held only by the AI gateway and are never distributed to application teams.

**Enforced by:** `provider_configs` on each virtual key, with `allowed_models` and `blacklisted_models` lists (exact names or regex) and `key_ids` to pin specific provider keys. The [AI governance controls](https://www.getmaxim.ai/ai-governance) in Bifrost apply them on every request.

### 5. Access control and keys

> Each application and environment uses its own gateway credential, rotated at least every 90 days, with a spend budget and a rate limit. Provider secrets live in the organization's secret manager.

**Enforced by:** `enforce_auth_on_inference`, which rejects requests without a valid virtual key. Expired keys fail closed with a 403 for LLM inference and MCP tool execution. [Budgets and rate limits](https://docs.getbifrost.ai/features/governance/budget-and-limits) reset on durations from one minute to one year, which addresses LLM06 Unbounded Consumption. Bifrost Enterprise adds [secret management](https://docs.getbifrost.ai/enterprise/secret-management) for HashiCorp Vault, AWS, GCP, and Azure secret stores.

## Sections 6-7: Prompt Injection, Output Handling, and PII Redaction

Prompt injection and sensitive information disclosure are the top two risks on the 2026 OWASP list. The policy treats model input as untrusted and model output as unvalidated, and requires inspection on both sides of the provider call, as Figure 2 shows.

![](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/2026/10/image-43.png)

***Figure 2: Each check before the provider can stop the request, and the log stores the redacted form of anything a guardrail detected.***

### 6. Prompt injection and output handling

> User input and retrieved content are untrusted and screened for prompt injection. Model output is never executed, rendered as HTML, or passed to a database or shell without validation. System prompts contain no credentials or sensitive data.

**Enforced by:** [guardrail rules](https://docs.getbifrost.ai/enterprise/guardrails) written as CEL expressions that run on input, output, or both. Prompt injection screening is available from AWS Bedrock Guardrails, Google Model Armor, Check Point, Repello Argus, and Singulr AI, and the [CrowdStrike AIDR integration](https://www.getmaxim.ai/bifrost/blog/bringing-enterprise-ai-security-to-llms-with-crowdstrike-aidr-guardrails-and-bifrost) adds inline AI threat detection. Output validation in the application stays with its owner; see [prompt injection defense for production agents](https://www.getmaxim.ai/articles/prompt-injection-defense-for-production-ai-agents-a-complete-2026-guide/).

### 7. PII and secrets handling

> Credentials and Restricted identifiers must not reach external providers or be stored in logs in raw form. Confidential personal data is redacted before transmission unless an approved exception applies.

**Enforced by:** the PII Detection template for Custom Regex (email, US phone, US SSN, credit-card-like numbers, IPv4), or Microsoft Presidio and Azure AI Language PII for entity recognition. Secrets Detection runs 222 Gitleaks default rules inside the gateway. Each profile can detect, block, or redact, and [redaction modes](https://docs.getbifrost.ai/enterprise/guardrails/redaction) decide whether the live payload, the logs, or both are rewritten; only roles with the Logs Reveal permission see reversible originals. The [AI guardrails page](https://www.getmaxim.ai/ai-guardrails) lists the provider options.

## Section 8: MCP and AI Agent Security Permissions

Section 8 limits what an LLM application can do, not only what it can say. It addresses LLM03 Excessive Agency by granting tools and agents explicitly per caller and inspecting tool arguments before execution. Model, tool, and agent access are separate grants, as Figure 3 shows.

![](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/2026/10/image-44.png)

***Figure 3: Granting a caller an agent does not grant that agent's model or tool calls, so excessive agency is limited at each hop.***

> Each application receives only the MCP tools it needs. Tools that write, delete, send, or spend require human approval. Tools that access user-owned data authenticate as that user. Calls to other agents require an explicit grant, and caller credentials are not forwarded unless approved.

**Enforced by:**

- [MCP tool filtering](https://docs.getbifrost.ai/mcp/filtering) at three stacked levels (client, request, virtual key), deny-by-default unless a client is marked Allow by Default.
- No automatic tool execution by default; in Agent Mode, only tools in `tools_to_auto_execute` run without approval.
- [MCP guardrails](https://www.getmaxim.ai/bifrost/blog/mcp-guardrails-in-bifrost) that inspect tool arguments before execution and results after it.
- Six [MCP authentication types](https://docs.getbifrost.ai/mcp/auth/overview), including per-user OAuth and token exchange.
- Agent access as a separate grant in the [Agent Gateway](https://www.getmaxim.ai/bifrost/blog/introducing-agent-gateway-in-bifrost-one-gateway-for-models-tools-and-agents); Bifrost strips the caller's credential before forwarding unless forwarding is turned on.

The [MCP gateway](https://www.getmaxim.ai/mcp-gateway) applies these rules to every tool call; the [MCP gateway access control and cost governance post](https://www.getmaxim.ai/bifrost/blog/bifrost-mcp-gateway-access-control-cost-governance-and-92-lower-token-costs-at-scale) covers the details.

## Sections 9-10: Logging, Retention, and AI Incident Response

Logging produces the evidence the policy relies on, and incident response sets how fast a violation is contained. Containment at the gateway is a configuration change, and its audit entry becomes part of the incident record. Figure 4 maps each response step to a control.

![](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/2026/10/image-45.png)

***Figure 4: Containment is a configuration change at the gateway, and the signed audit log proves when it happened.***

### 9. Logging and retention

> All AI requests, tool calls, and agent calls are logged with caller identity, model, tokens, cost, and guardrail outcome. Content is not stored for Restricted workloads. Request logs are kept \[N] days; changes to AI controls are kept at least one year.

**Enforced by:** [request logs](https://docs.getbifrost.ai/features/observability/default) for LLM and MCP traffic, with content logging turned off per virtual key where required, which also strips content from connector exports. Retention is set with `log_retention_days` (default 365). Request logs and [audit logs](https://docs.getbifrost.ai/enterprise/audit-logs) are different records: audit logs capture every create, update, and delete on the management API with a before-and-after diff and HMAC signing, exportable as JSON, JSON Lines, or Syslog.

### 10. Incident response

> An AI security incident includes data leakage to a provider, a prompt injection that changes system behavior, an unauthorized tool action, or credential exposure. The gateway operator contains a Severity 1 incident within \[N] minutes by revoking the affected credential or tool grant. The incident record includes the relevant request logs and audit log entries.

**Enforced by:** deactivating a virtual key or removing a tool from its allow-list. Bifrost Enterprise [alerting](https://docs.getbifrost.ai/enterprise/alerting/overview) sends budget and rate-limit alerts to Slack, Microsoft Teams, PagerDuty, or webhooks.

## Sections 11-13: Vendor Review, Exceptions, and Review Cadence

The last three sections keep the policy current. Vendor review controls what enters the approved list, exceptions give teams a sanctioned path instead of a workaround, and the review cadence tracks changes in OWASP, NIST, and incident history.

### 11. Vendor review

> Each model provider, guardrail vendor, and MCP server is reviewed for data retention, training on inputs, processing region, certifications, and subprocessors before approval. Model artifacts and fine-tuning data are integrity-checked before deployment.

**Enforced by:** process, not the gateway. The gateway is also in scope: Bifrost is self-hosted in the customer's VPC or on-premises, no prompts or responses leave that infrastructure, and it holds SOC 2 Type II, ISO 27001, HIPAA, and GDPR compliance, as the [Bifrost Enterprise page](https://www.getmaxim.ai/enterprise) details.

### 12. Exceptions

> Exceptions are requested in writing, approved by the policy owner, limited to 90 days, and implemented as a separately scoped credential.

**Enforced by:** a dedicated virtual key with an expiry date, its own budget, and only the extra access it needs; the audit log records who created it.

### 13. Review cadence

> The policy and gateway configuration are reviewed quarterly and after every Severity 1 incident, covering guardrail detections, unused credentials, tool grants, and OWASP and NIST updates. New guardrail rules run in monitor mode before enforcement.

**Enforced by:** guardrail monitor mode, which logs what an output rule would do without changing the response, and audit log exports for the review record. The [policy-to-runtime governance guide](https://www.getmaxim.ai/articles/the-complete-guide-to-ai-governance-from-policy-to-runtime-enforcement/) covers rollout across teams.

## Frequently Asked Questions

### What should an AI security policy include?

An AI security policy for LLM applications should cover scope, roles, data classification, approved models, access control, prompt injection and output handling, PII and secrets, tool and agent permissions, logging, incident response, vendor review, exceptions, and review cadence. Each clause should name the control that enforces it, such as a budget or a guardrail rule, so compliance can be tested.

### What is the difference between an AI security policy and an AI usage policy?

An AI usage policy, or AI acceptable use policy, tells employees which AI tools they may use and what data they may share with them. An AI security policy governs the AI systems an organization builds and runs: applications, agents, and pipelines. Both share a data classification scheme; the [top tools to enforce an AI usage policy](https://www.getmaxim.ai/articles/top-5-tools-to-enforce-an-ai-usage-policy-in-2026/) cover the employee side.

### How does the OWASP LLM Top 10 relate to an AI security policy?

The OWASP Top 10 for LLM Applications lists the most common security risks in LLM systems, and an AI security policy is where an organization commits to controls for each one. The 2026 edition ranks Prompt Injection, Sensitive Information Disclosure, and Excessive Agency first through third. Mapping policy sections to OWASP risks shows reviewers which risks have an owner and a control.

### Can an AI gateway enforce an entire AI security policy?

No. An AI gateway enforces the clauses that apply to traffic: identity, model access, budgets, guardrails, tool and agent grants, and logging. Training data integrity, retrieval store access, output validation, and vendor contracts need controls elsewhere. A gateway such as [Bifrost, the open-source AI gateway,](https://www.getmaxim.ai/) covers the runtime clauses in one place, and the policy assigns owners for the rest.

### How often should an AI security policy be reviewed?

Review the policy at least quarterly and after every high-severity AI incident. AI risk frameworks change quickly: the 2026 OWASP LLM Top 10 renamed and reordered several risks. Each review covers guardrail detections, unused credentials, tool grants, and new providers, and leaves a record in the [audit log](https://docs.getbifrost.ai/enterprise/audit-logs).

## Start Enforcing Your AI Security Policy with Bifrost

A policy protects LLM applications only when each clause maps to a control that runs on every request. [Bifrost, one gateway for all AI traffic,](https://www.getmaxim.ai/) turns this template into virtual keys, budgets, guardrails, tool and agent grants, and signed audit logs inside your own infrastructure. To map this AI security framework to your applications, [book a demo](https://www.getmaxim.ai/book-a-demo) with the Bifrost team or read the [AI security resources](https://www.getmaxim.ai/resources/ai-security).

## Read next

[![What Is AI Governance? A Definition for Engineering Teams](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/what-is-ai-governance-a-definition-for-engineering-teams-bifrost-1920x1080.png) AI governance is the set of policies, controls, and evidence that keeps an organization's AI use within agreed limits. This guide answers what is AI governance for engineers, mapping NIST AI RMF, EU AI Act, and ISO/IEC 42001 to runtime controls on model, MCP tool, and agent traffic.](https://www.getmaxim.ai/articles/what-is-ai-governance/)

[![EU AI Act Compliance for LLM Applications and Agents](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/eu-ai-act-compliance-for-llm-applications-and-agents-bifrost-1920x1080.png) EU AI Act compliance for LLM applications means mapping each feature to a risk category and producing evidence for logging, oversight, and transparency duties. This guide covers the post-Omnibus timeline, the engineering obligations, and where an AI gateway helps and where it stops.](https://www.getmaxim.ai/articles/eu-ai-act-compliance-llm-applications/)

[![Claude Code Hooks for Governance and Gateway Policy](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/claude-code-hooks-for-governance-and-gateway-policy-bifrost-1920x1080.png) Claude Code hooks are handlers that run at fixed points in a session and can allow, deny, or log what the agent does. This guide shows how to use Claude Code hooks for governance, how to lock them with managed settings, and where an AI gateway enforces identity, budgets, and tool access instead.](https://www.getmaxim.ai/articles/claude-code-hooks-for-governance-and-gateway-policy/)

## More in AI Governance

[![EU AI Act Compliance for LLM Applications and Agents](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/eu-ai-act-compliance-for-llm-applications-and-agents-bifrost-1920x1080.png) EU AI Act compliance for LLM applications means mapping each feature to a risk category and producing evidence for logging, oversight, and transparency duties. This guide covers the post-Omnibus timeline, the engineering obligations, and where an AI gateway helps and where it stops.](https://www.getmaxim.ai/articles/eu-ai-act-compliance-llm-applications/)

[![What Is AI Governance? A Definition for Engineering Teams](https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w720/2026/10/what-is-ai-governance-a-definition-for-engineering-teams-bifrost-1920x1080.png) AI governance is the set of policies, controls, and evidence that keeps an organization's AI use within agreed limits. This guide answers what is AI governance for engineers, mapping NIST AI RMF, EU AI Act, and ISO/IEC 42001 to runtime controls on model, MCP tool, and agent traffic.](https://www.getmaxim.ai/articles/what-is-ai-governance/)

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "publisher": {
        "@type": "Organization",
        "name": "Maxim Articles",
        "url": "https://www.getmaxim.ai/articles/",
        "logo": {
            "@type": "ImageObject",
            "url": "https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w256h256/2025/08/thumbnail.png",
            "width": 60,
            "height": 60
        }
    },
    "author": {
        "@type": "Person",
        "name": "Kamya Shah",
        "image": {
            "@type": "ImageObject",
            "url": "https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/2025/09/WhatsApp-Image-2025-08-29-at-17.40.40-1.jpeg",
            "width": 1200,
            "height": 1600
        },
        "url": "https://www.getmaxim.ai/articles/author/kamya/",
        "sameAs": []
    },
    "headline": "AI Security Policy Template for Teams Shipping LLM Apps",
    "url": "https://www.getmaxim.ai/articles/ai-security-policy-template/",
    "datePublished": "2026-10-30T19:02:08.000Z",
    "dateModified": "2026-10-30T19:02:08.000Z",
    "image": {
        "@type": "ImageObject",
        "url": "https://storage.ghost.io/c/84/03/8403f2f6-141c-411a-8f55-a32d4291533e/content/images/size/w1200/2026/10/ai-security-policy-template-for-teams-shipping-llm-apps-bifrost-1920x1080.png",
        "width": 1200,
        "height": 675
    },
    "keywords": "AI Governance",
    "description": "An AI security policy sets the rules for which data, models, tools, and agents an organization's AI systems may use. This template gives engineering teams 13 copy-ready clauses, mapped to the OWASP Top 10 for LLM Applications 2026 and NIST AI RMF, with the Bifrost control behind each one.",
    "mainEntityOfPage": "https://www.getmaxim.ai/articles/ai-security-policy-template/"
}
```