SAIL 2.0 frames the operational gap in secure AI agent governance

At a glance

What this is: SAIL 2.0 is a seven-phase framework for governing secure AI agents across the lifecycle, with expanded risk mapping for agentic attack surfaces, runtime controls, and retirement.

Why it matters: It matters because AI agents are already acting as non-human identities with delegated access, so IAM, PAM, and governance teams need a model that addresses reasoning, tools, memory, and decommissioning together.

By the numbers:

• The catalog grows from more than 70 risks in V1 to 91, each with a stable SAIL ID, a concrete example, the assets affected, mitigations, and standards citations.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.

👉 Read Pillar Security's guide to SAIL 2.0 for secure AI agents

Context

AI agent governance is failing where traditional IAM assumes a stable subject, predictable intent, and reviewable access. SAIL 2.0 responds to that gap by treating agents as identities that can chain tool calls, inherit access, and change the effective blast radius of existing controls.

The key question is not whether an AI system can act, but whether security teams can govern what it is allowed to do once it begins reasoning, selecting tools, and operating inside shared environments. That shifts the problem from policy statements to lifecycle controls, runtime enforcement, and retirement discipline for agent identities.

Key questions

Q: How should security teams govern AI agents that can chain tool calls across systems?

A: Treat the agent as a governed identity with lifecycle ownership, action-level policy, and runtime termination controls. Session-level approval is not enough when one agent can assemble multiple legitimate actions into an unsafe outcome. The right control objective is to constrain tool use, separate execution zones, and revoke access cleanly when the agent is retired.

Q: Why do AI agents complicate existing IAM and PAM controls?

A: Because those controls assume a stable identity and a reviewable access window. An agent can inherit privileges, select tools at runtime, and complete meaningful work before a human review cycle catches up. IAM and PAM still matter, but they must be extended into runtime enforcement, delegation governance, and retirement control.

Q: What breaks when AI agents inherit the creator’s access without review?

A: Maker-identity inheritance breaks the separation between who built the agent and who should be accountable for its access. The builder’s privileges can become embedded in the artefact, then reused at runtime across systems the builder never intended. That creates hidden privilege transfer and weakens both governance and auditability.

Q: How do organisations know if AI agent governance is actually working?

A: Look for evidence that every agent is inventoried, zoned, policy-checked at runtime, and retired with credentials revoked and triggers removed. If you cannot trace an agent from creation to decommissioning, governance is still partial. A working programme leaves an auditable identity trail, not just a policy document.

How it works in practice

Why secure AI agents need lifecycle controls, not just policy

SAIL 2.0 treats the agent lifecycle as an operating model because agent risk appears at build time, deployment time, and runtime, not only at onboarding. The framework separates policy, discovery, posture, red teaming, runtime controls, sandboxing, and govern-retire steps because each phase exposes a different failure mode. This matters for secure AI agents because the identity subject can hold credentials, invoke tools, and propagate decisions through delegation chains. In practice, lifecycle governance must follow the agent from approval to decommissioning, or the environment accumulates orphaned access and unreviewed behaviour.

Practical implication: map every agent to a lifecycle owner and retire it with the same rigor you apply to privileged non-human identities.

How agentic attack surfaces differ across code, cloud, and endpoint

SAIL 2.0’s three-zone model reflects where agents actually operate. Zone 1 covers code and pipeline artefacts such as models, prompts, datasets, and agent configurations. Zone 2 covers cloud agents running inside managed platforms, where delegated authority often exceeds visibility. Zone 3 covers endpoint agents that sit close to user credentials and local files. The architectural point is that the same agentic behaviour produces different risk depending on where the trust boundary sits. A control that works in CI/CD may fail on a workstation because the credential context is different and the blast radius is immediate.

Practical implication: segment controls by zone instead of applying one uniform security pattern across all agent deployments.

Runtime guardrails for AI agents and MCP tool use

The runtime phase in SAIL 2.0 recognises that action control is different from access control. An agent may stay within its authorised session while composing a chain of actions that becomes harmful when viewed together. That is why the framework focuses on per-action policy checks, scoped tool access, and the ability to pause or terminate mid-execution. This is especially relevant where MCP servers, tool descriptions, and delegated connectors expand the action surface without changing the underlying identity model. The failure mode is not merely excessive privilege. It is uncontrolled sequence formation across trusted tools.

Practical implication: enforce action-level policy on tool calls and review MCP-connected pathways as part of runtime governance.

NHI Mgmt Group analysis

Static policy is no longer a sufficient control boundary for AI agents. SAIL 2.0 correctly treats agentic behaviour as a lifecycle and runtime problem, not a document-management problem. When an identity can chain tool calls and make changes faster than human review can intervene, the security model has to govern actions, delegation, and retirement together. The practitioner conclusion is that policy alone cannot define trust for autonomous execution.

Access review cadences were designed for identities whose privilege persists long enough to be observed. That assumption fails when an AI agent can inherit, consume, and propagate access inside a short execution window. The implication is not simply more review. It is that review-based governance cannot be the primary control plane for fast-moving agentic identities.

Agentic blast radius is now determined by where the identity lives, not just what it can access. SAIL 2.0’s zone model is a useful reminder that code, cloud, and endpoint environments carry different trust assumptions and different failure modes. A connector in a managed cloud platform behaves differently from an endpoint agent sitting beside local credentials, and governance needs to reflect that separation. Practitioners should classify controls by execution zone, not by AI label.

MCP and tool-description exposure create a new governance surface around delegated action. When tool catalogs, connectors, and agent instructions are shared across systems, the identity boundary extends into the metadata that tells an agent what it can do. That changes the control conversation from “who can log in” to “which action paths are discoverable and executable.” The practitioner conclusion is that tool governance has to be treated as identity governance.

Maker-identity inheritance: SAIL 2.0 points to a failure mode where a business user or builder can create an agent that inherits the creator’s access without security review. That assumption was designed for a human-paced deployment model. It fails when access is embedded into the build artefact itself and then reused at runtime across multiple systems. The implication is that creation-time identity and runtime identity can no longer be treated as the same trust event.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), 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.
• Use OWASP Agentic AI Top 10 to connect those findings to runtime risk patterns and control mapping.

What this signals

Maker-identity inheritance is emerging as a core governance problem for AI agents because creation-time access can persist into runtime without a separate review event. That means IAM teams need to treat agent provisioning as an identity handoff, not just a deployment step.

With 92% of organisations agreeing that governing AI agents is critical but only 44% having implemented policies, the gap is no longer conceptual. Teams should expect pressure to prove inventory, runtime enforcement, and decommissioning controls together, not as isolated projects.

The programme signal is clear: lifecycle ownership, action control, and zone-based segmentation will become the practical differentiators in agent governance, especially where tools like MCP expand the number of paths an identity can take.

For practitioners

• Inventory agent identities by lifecycle stage Map every AI agent to build, deploy, operate, and retire ownership so no agent remains live without an accountable controller. Treat orphaned agent identities as unresolved access, not inactive software.
• Separate controls by execution zone Apply different guardrails to code and pipeline artefacts, cloud agents, and endpoint agents because each zone has a distinct credential context and blast radius. Use the zone model to decide where review, isolation, and approval gates belong.
• Enforce action-level policy on tool use Validate each agent action, not just the initial session, when tools, connectors, or MCP servers can chain into harmful sequences. Add pause and termination paths that can stop execution before a delegation chain completes.
• Retire agents as identities, not artefacts Revoke credentials, disable triggers, wipe memory, and record an end-of-life audit when an agent is decommissioned. If the agent can still authenticate after retirement, the identity was not actually removed.
• Test for delegation-chain failure paths Red-team maker-identity inheritance, privilege escalation through delegation, and cascading failure propagation across multi-agent workflows. Focus on how one agent’s authorised action becomes another system’s unreviewed input.

Key takeaways

• SAIL 2.0 reframes AI agent security as lifecycle governance, runtime control, and retirement discipline, not just policy writing.
• Agents already exceed intended scope in most organisations, which means review-based IAM alone cannot keep pace with delegated execution.
• Practitioners should classify AI agents by execution zone, constrain actions at runtime, and decommission them as identities when they are no longer needed.

Key terms

• Agentic Attack Surface: The set of places where an AI agent can be created, connected, and allowed to act. It includes code artefacts, cloud platforms, and endpoints, plus the tools, credentials, and data paths those agents can reach. Governance has to follow that surface, not just the model.
• Maker-Identity Inheritance: A failure mode where an agent inherits the creator’s permissions without a separate security review. The builder’s identity becomes embedded in the agent’s runtime access, which can transfer privileges far beyond the original intent. This creates hidden accountability and expands blast radius.
• Runtime Guardrails: Controls that evaluate and restrict what an AI agent can do while it is running. They focus on actions, tool calls, and execution paths rather than only on login or session establishment. In agentic environments, they are the difference between permitted access and permitted abuse.
• Delegation Chain: The sequence of identities and permissions through which an agent receives or extends authority. In agentic systems, one actor can pass context or access to another, making the effective privilege path longer than the visible login path. That chain has to be governed end to end.

What's in the full announcement

Pillar Security's full blog covers the operational detail this post intentionally leaves for the source:

• The full seven-phase SAIL 2.0 lifecycle with phase-by-phase risk examples and control mapping.
• The complete list of 91 mapped risks, including the new agentic entries and their standards citations.
• The zone-by-zone breakdown for code, cloud, and endpoint agents with practical ownership implications.
• The SAIL Skill outputs for roadmap building, maturity assessment, and vendor-assessment questions.

👉 The full Pillar Security post covers the SAIL 2.0 lifecycle, risk catalog, and standards mappings in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.