The enterprise AI footprint has expanded faster than any previous technology wave. The average large enterprise now has dozens of AI models in production, hundreds of integrations connecting LLMs to internal data sources and business processes, and an unknown number of AI tools adopted informally by employees. Security teams built for protecting traditional application stacks are finding that their existing frameworks don’t map cleanly to this new surface.
AI Security Posture Management — AISPM — is the emerging practice of continuously assessing and improving the security of an organisation’s AI ecosystem. The term draws on the CSPM (Cloud Security Posture Management) model: instead of scanning cloud infrastructure for misconfigurations, AISPM frameworks scan AI deployments for vulnerabilities, excessive permissions, prompt injection exposure, data leakage risk, and compliance gaps.
This briefing covers what AISPM means in practice, the specific risks it addresses, and how to think about building this capability in your organisation.
Why Existing Frameworks Don’t Cover AI Risk
Traditional application security disciplines — SAST, DAST, penetration testing, SIEM-based monitoring — were built for deterministic systems. An application does what the code says. Input validation prevents SQL injection. Output encoding prevents XSS. The security boundary is defined by code the development team wrote.
LLM-based applications break this model in several ways:
Non-determinism. An LLM does not produce the same output for the same input. This makes static analysis incomplete and traditional testing insufficient — you can’t enumerate all possible outputs from all possible inputs.
Prompt injection as a new attack class. Attackers can inject instructions into user-supplied content that cause the AI system to take actions its developers did not intend. A customer service chatbot that can query a CRM might be prompted to extract all customer records. A code generation assistant with filesystem access might be prompted to read /etc/passwd. These attacks are not prevented by code review.
Data access through AI as a new exfiltration surface. AI systems often have broad read access to organisational data — documents, emails, databases, knowledge bases — to function effectively. A compromised or manipulated AI agent with this access is a high-value exfiltration channel.
Third-party model risk. Most enterprises use LLM APIs from hyperscalers or AI providers rather than running models locally. The security posture of those providers — and the confidentiality guarantees they provide for prompts and fine-tuning data — is a third-party risk that doesn’t fit neatly into traditional vendor risk management.
AI supply chain risk. Fine-tuned models, pre-trained adapters, embeddings, and AI application frameworks can all be attack surfaces for supply chain compromise. Malicious behaviour embedded in model weights is not visible to code review.
The AISPM Framework: What It Covers
AISPM frameworks differ in scope, but most mature approaches address these domains:
AI Asset Discovery
You can’t manage risk you can’t see. The first requirement is a complete inventory of AI systems in your environment:
- API integrations to external LLM providers (OpenAI, Anthropic, Google, Mistral, Cohere)
- Self-hosted model deployments (Ollama, vLLM, TGI, Triton)
- AI application frameworks (LangChain, LlamaIndex, LangGraph, AutoGen, CrewAI)
- AI-enabled SaaS applications (Salesforce Einstein, Microsoft Copilot, Workday AI, Zendesk AI)
- Shadow AI: unsanctioned tools discovered through network traffic analysis, browser history review, or employee disclosure
Most organisations discover they have significantly more AI surface than their initial inventory suggested. Research from 2026 consistently shows that between 60-80% of enterprise AI usage occurs through tools not approved by IT or security.
Model Access and Permission Assessment
For each AI system, assess:
- What data sources can the AI read? Are access permissions least-privilege or broad?
- What actions can the AI take on behalf of users? Can it write to systems, send emails, execute code?
- Who has access to the AI system? Is there authentication? Role-based access control?
- Are API keys and service account credentials properly rotated and scoped?
- For agentic systems — AI that can take multi-step actions — what is the blast radius if the system is manipulated?
The pattern of AI agents with broad tool access and no human-in-the-loop for consequential actions is a particularly significant risk. An LLM agent that can execute code, browse the web, read email, and write to databases presents an attack surface that is qualitatively different from a simple Q&A chatbot.
Prompt Injection Exposure
Prompt injection — causing an AI system to follow attacker-supplied instructions embedded in content it processes — is the most novel attack class in the AI security landscape and the one most likely to be underestimated.
Assess your AI applications for:
Direct prompt injection: Can an attacker directly interact with the system prompt or bypass the application’s intended instruction set through crafted user input?
Indirect prompt injection: Does the AI process external content (emails, documents, web pages, database records) that an attacker could control? An AI assistant that reads emails and can send calendar invitations is vulnerable to indirect injection through a malicious email.
Tool call injection: For agentic systems that call external APIs or functions, can injected instructions cause the AI to call APIs with attacker-controlled parameters?
Prompt injection does not have a complete technical solution. Mitigations include privilege separation (AI systems should not have access to actions beyond what the immediate task requires), input/output filtering, human-in-the-loop requirements for consequential actions, and architectural design that limits the blast radius.
Training Data and Model Risk
If your organisation fine-tunes models or trains custom models:
- Is the training data pipeline protected against poisoning? Training data from scraped external sources, customer feedback, or user interactions can be manipulated.
- Are fine-tuned model weights stored securely? Model weights are proprietary intellectual property and potentially contain learned information from sensitive training data.
- Is there a process for evaluating model behaviour for unintended capabilities or jailbreak susceptibility before deployment?
For models from external providers, your risk assessment should include the provider’s security certifications (SOC 2, ISO 27001), their data handling policies for prompts and fine-tuning data, and the breach notification terms in your contract.
AI Output and Data Leakage Risk
AI systems trained on or given access to sensitive data can reproduce that data in responses. This is a privacy and compliance risk distinct from a traditional data breach — it occurs through normal system operation.
Assess:
- Does your AI system have access to PII, PHI, or regulated data it could expose in responses?
- Are there output filtering controls to detect and block sensitive data in AI responses?
- Is there logging of AI interactions sufficient to support a breach investigation if needed?
For applications subject to GDPR, HIPAA, or CCPA, the data minimisation and purpose limitation principles apply to data you expose to AI models — both external APIs and self-hosted systems where prompt data may be retained.
Building an AISPM Capability
Phase 1: Inventory and Visibility
Start with discovery. You cannot prioritise risk without knowing your AI surface. Combine:
- Network traffic analysis to identify API calls to AI provider endpoints
- SaaS application review to identify AI-enabled tools in your stack
- Developer survey and engineering platform review (which AI coding assistants are approved or in use?)
- Browser extension audit (AI browser extensions are a significant shadow AI vector)
Build an AI asset register with ownership, data access scope, authentication status, and risk classification for each system.
Phase 2: Risk Assessment and Prioritisation
Prioritise based on:
- Data access scope: AI systems with access to sensitive, regulated, or highly confidential data are highest priority
- Action scope: AI agents that can take consequential actions (send emails, execute code, make API calls) are higher risk than read-only Q&A systems
- User-facing surfaces: Applications that process external user input (chatbots, document processing, email AI) have prompt injection exposure
- Authentication and access control gaps: Unauthenticated or poorly access-controlled AI endpoints
Phase 3: Controls and Remediation
Address findings systematically:
- Scope API key permissions to minimum required access
- Implement authentication on internal AI endpoints
- Apply least-privilege to data sources AI systems can access
- Deploy output filtering for sensitive data patterns
- Establish a human-in-the-loop requirement for consequential AI actions
- Set up logging and monitoring for AI interactions
Phase 4: Continuous Monitoring
AI posture is not static. New AI systems are deployed regularly. Existing systems gain new tool integrations. Provider models change. Establish:
- Regular re-scanning of your AI asset inventory
- Integration of AI security checks into your software development lifecycle for AI applications
- Monitoring of AI interaction logs for anomalous patterns
- Process for evaluating new AI tools before organisational adoption
Tooling Landscape
The AISPM tooling market is early. Several vendors have released products specifically targeting AI security posture:
- Protect AI — model scanning, supply chain security, LLM firewall capabilities
- Lakera — prompt injection detection and AI guardrails
- Robust Intelligence (acquired by Cisco) — AI red teaming and model risk assessment
- Wiz AI-SPM — extends cloud security posture management to AI workloads running in cloud environments
- Microsoft Defender for Cloud — has added AI workload protection for Azure OpenAI deployments
Most organisations will not need a dedicated AISPM product immediately. The fundamentals — inventory, permission scoping, access control, logging — can be addressed with existing security tooling and operational process. Dedicated tooling becomes more valuable as the AI estate grows in complexity.
The Board Conversation
CISOs raising AI security risk with boards should frame it in terms boards understand:
It’s not hypothetical. Prompt injection attacks against enterprise AI applications have been documented. AI-related data leakage incidents are occurring. The tooling is production and the risk is current.
The risk scales with adoption. Every new AI integration expands the surface. The faster your organisation adopts AI, the faster this risk category grows.
AISPM is an investment in AI programme velocity, not just security. Organisations with mature AI security practices can move faster on AI adoption because they have visibility and controls. Security bottlenecks in AI projects are often caused by undiscovered risk, not excessive caution.
The regulatory environment is hardening. The EU AI Act requires security risk assessments for high-risk AI systems. NIST’s AI Risk Management Framework provides a structure. Regulators are beginning to ask about AI governance in supervisory examinations. This is not a future compliance problem.
Summary
AISPM is a new category addressing a genuine new risk surface — one that existing CSPM, SAST, and DAST tooling does not fully cover. The foundational work is not exotic: inventory your AI assets, scope their permissions, assess their prompt injection exposure, and implement logging. The organisations that build this capability now, as their AI footprints are still manageable, will be better positioned than those that address it after a significant incident.