TL;DR: More than 70 AI-specific risks are mapped across seven lifecycle phases in Pillar Security’s SAIL framework, spanning planning, discovery, posture management, red teaming, runtime guardrails, safe execution, and activity tracing, according to Pillar Security. It reinforces that AI security must be treated as lifecycle governance, not a collection of point controls, especially as autonomous behaviour expands attack surface.
NHIMG editorial — based on content published by Pillar Security: Introducing the SAIL Framework, a Practical Guide to Secure AI Systems
By the numbers:
- At its core, SAIL is structured around seven lifecycle phases, addressing more than 70 mapped risks across the AI development and deployment pipeline.
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
Questions worth separating out
Q: How should security teams govern AI systems across the lifecycle?
A: They should govern AI systems by stage, not by a single pre-production review.
Q: Why do AI assets need dedicated discovery and inventory controls?
A: Because unseen AI assets cannot be governed.
Q: What breaks when runtime guardrails are missing for AI systems?
A: Without runtime guardrails, AI behaviour can drift beyond what was approved during design and testing.
Practitioner guidance
- Inventory every AI asset and dependency Create a complete register of models, datasets, prompts, MCP servers, and tools, including shadow AI built outside central IT.
- Add phase gates to AI lifecycle reviews Require documented policy, threat modelling, and approval checkpoints at plan, build, test, deploy, operate, and monitor stages.
- Constrain runtime access for high-risk AI actions Wrap tool use, code execution, and sensitive data access in runtime guardrails and sandboxed execution environments.
What's in the full article
Pillar Security's full blog covers the operational detail this post intentionally leaves for the source:
- The full seven-phase SAIL workflow with phase-by-phase control mapping for planning, build, test, deploy, operate, and monitor.
- Examples of mapped AI-specific risks across more than 70 scenarios, useful if you are building internal control libraries.
- The article’s practical guidance for secure experimentation, runtime enforcement, and activity tracing in AI environments.
- Contributor context and practitioner framing that shows how the framework was shaped by AI and cybersecurity leaders.
👉 Read Pillar Security's guide to the SAIL framework for secure AI systems →
SAIL framework and AI lifecycle security: what IAM teams need?
Explore further
AI lifecycle security is now identity governance by another name. SAIL is strongest when read as a governance model, not just an AI security framework. Its seven phases mirror the same lifecycle discipline IAM and NHI teams already apply to access, review, and oversight, but with AI-specific artefacts such as prompts, tools, and models. The practitioner takeaway is that AI security programmes should be built as lifecycle governance systems, not isolated technical controls.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: Who should own AI governance when AI touches identity and access?
A: Ownership should sit with the team that can explain the AI system’s access, purpose, and operating boundaries end to end. In practice, that means AI governance must connect security, IAM, data, and engineering accountability so the system is not treated as a floating experiment. If ownership is unclear, lifecycle control will be inconsistent.
👉 Read our full editorial: SAIL framework formalises lifecycle controls for secure AI systems