Most AI startups inherit a generic security policy from their SOC 2 readiness vendor and call it done. The problem is that a generic security policy doesn't mention LLMs, prompts, RAG pipelines, AI agents, or model providers — because it wasn't written for companies that build AI products. This leaves a documentation gap that auditors, enterprise customers, and increasingly regulators are starting to identify.
An AI security policy doesn't replace your general information security policy. It supplements it with AI-specific requirements that your existing policy doesn't address. Here is what it should cover.
Section 1: Scope and Definitions
Define what the policy applies to: all AI systems built, deployed, or operated by the organisation — including LLM-based products, RAG pipelines, AI agents, fine-tuned models, and AI features embedded in non-AI products. Define key terms your team needs to understand consistently: foundation model, fine-tuning, prompt, system prompt, retrieval-augmented generation, AI agent, tool call.
Section 2: AI Risk Classification
Not all AI use is equally risky. Classify AI systems by their potential impact:
- Tier 1 (High Risk): AI systems that make or substantially influence decisions with significant consequences — financial, medical, employment, legal, or safety decisions. AI agents with write access to production systems or external communications.
- Tier 2 (Medium Risk): AI systems that process or surface sensitive personal data. AI systems used in customer-facing products. AI systems with access to proprietary business information.
- Tier 3 (Low Risk): Internal productivity tools, code assistants with read-only access, and AI features that process only non-sensitive data.
The security testing, monitoring, and approval requirements in the rest of the policy should then be tiered by this classification.
Section 3: Model and Provider Approval
Define the process for approving new AI models and foundation model providers before use in production:
- Security questionnaire for foundation model providers covering data handling, training data use, API security, and breach notification.
- Data classification review — what categories of data may be sent to the provider's API? PII, proprietary code, customer data?
- Data processing agreement (DPA) requirement for providers that process personal data.
- Named approved providers list, with a defined process for requesting additions.
Section 4: Prompt and System Instruction Security
System prompts are security-critical assets — they define the model's behaviour, constraints, and access permissions. Treat them accordingly:
- System prompts for production AI systems must be reviewed and approved before deployment.
- System prompts must not contain credentials, connection strings, or API keys.
- Changes to system prompts must go through change management (code review, staging deployment, testing).
- System prompts containing confidential business logic must be classified as confidential information assets.
Section 5: Security Testing Requirements
Define minimum security testing requirements by risk tier:
- Tier 1 systems: Full AI security penetration test before launch, covering OWASP LLM Top 10. Annual repeat. Red team assessment for agent systems. Remediation of all critical and high findings before go-live.
- Tier 2 systems: AI security assessment covering prompt injection, data leakage, and access control before launch. Remediation of all critical findings before go-live.
- Tier 3 systems: Internal security review checklist completed by the engineering team. Spot-check penetration testing annually across the Tier 3 estate.
Section 6: AI Incident Response
Define what constitutes an AI security incident and how to respond:
- Successful prompt injection that overrides system instructions or exfiltrates data.
- AI agent taking unintended actions on external systems.
- Evidence of training data extraction or membership inference attacks.
- AI model producing outputs that indicate jailbreak success or safety failure.
Response procedures should include: immediate isolation or rate limiting of the affected AI system, escalation to the security team, logging preservation, root cause analysis, and post-incident review. For Tier 1 systems, define customer notification obligations triggered by AI security incidents.
Section 7: Employee Acceptable Use
Define what employees may and may not do with AI tools:
- Prohibited: Entering customer PII, credentials, or confidential IP into unapproved AI tools or models.
- Required: Using only approved AI providers for work-related tasks involving sensitive data.
- Required: Reporting suspected AI security incidents to the security team within 24 hours.
Keeping the Policy Current
AI security is evolving faster than any other domain in software security. Review your AI security policy at least every six months, and update it whenever you: add a new AI system to the Tier 1 or Tier 2 classification, onboard a new foundation model provider, observe a significant new attack technique published against AI systems, or receive a finding in a penetration test that your current policy doesn't address.
Key Takeaways
- This post covers practical, actionable guidance for security and engineering teams.
- All findings and techniques are mapped to recognised frameworks (OWASP, NIST, ISO).
- Contact Vynox Security to test your systems against the vulnerabilities described here.