TL;DR: The central issue is that agents chain tool calls and act within delegated credentials faster than human review cycles can govern, which makes static policy and perimeter controls insufficient, as shown by Pillar Security’s SAIL 2.0, which extends its Secure AI Lifecycle into a seven-phase operating model for AI agents, adding 91 mapped risks, three deployment zones, and standards mappings across EU AI Act, ISO 42001, OWASP, and NIST AI RMF.
At a glance
What this is: Pillar Security’s SAIL 2.0 is a secure AI lifecycle framework that expands governance for AI agents, defining a seven-phase operating model, 91 mapped risks, and three deployment zones around how agents behave in real environments.
Why it matters: IAM, PAM, and NHI teams need this because agentic systems can inherit credentials, execute chained actions, and create governance gaps that traditional access reviews and perimeter controls do not cover.
By the numbers:
- SAIL 2.0 expands the risk catalog 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.
Context
AI agent governance is the discipline of controlling systems that can choose actions, use tools, and trigger changes without waiting for a human at each step. The core problem is not just access, but how delegated authority behaves once an agent can chain decisions faster than review cycles can keep up.
Pillar Security positions SAIL 2.0 as a lifecycle model for that problem space, extending its earlier framework into agentic attack surface mapping, runtime guardrails, and retirement controls. The article is strongest where it shows that existing application security and DevSecOps assumptions do not fully describe agents that reason, retain context, and act across multiple systems.
For IAM and NHI practitioners, the article is a signal that agent governance is becoming its own control plane rather than a side issue inside app security. That is typical of a category moving from concept to operational adoption: the language is still maturing, but the control gaps are already visible.
Key questions
Q: What breaks when AI agents are managed like ordinary machine identities?
A: What breaks is the assumption that access scope can be fully understood from provisioning data and quarterly review. Ordinary machine identities are repeatable; agents are not. If teams only review entitlements, they miss context shifts, delegated actions, and credential creation inside the session.
Q: Why do agentic systems increase governance risk even when access looks limited?
A: Limited access is not the same as limited behaviour. An agent can combine multiple permitted tools, move through delegated workflows, and create an outcome that no single permission appears to authorise. That makes runtime composition of actions the real risk, not the size of the original access grant.
Q: What signals show that an AI governance programme is not working?
A: Warning signs include disconnected models built by different teams, repeated disputes over data ownership, inconsistent approvals and outputs that cannot be explained to stakeholders. If the organisation cannot trace which data supported a decision or who approved the model, governance is already failing at the operating level.
Q: How should security teams compare action-level control with access-level control for agents?
A: Access-level control decides whether an agent may enter a system, while action-level control decides whether each specific step is permitted once the agent is already inside. For AI agents, action-level control is the stronger governance boundary because the harmful decision often emerges from the sequence, not the initial login.
How it works in practice
Why agentic governance breaks static access control
Traditional access control assumes the actor’s intent is stable enough to authorise a session, then monitor or certify it later. SAIL 2.0 argues that AI agents break that model because they can chain tool calls, change state across steps, and complete harmful action sequences before a reviewer can intervene. That makes the unit of control the action, not the account or the session. The operational problem is not simply overbroad access, but non-deterministic execution inside delegated privilege. Practical implication: move from session-centric governance to invocation-level control and traceability.
Practical implication: Treat each agent action as the control point, not the login or the session.
How the three SAIL zones map to agent governance
SAIL 2.0 divides agentic exposure into three zones: code and pipeline assets, cloud agents, and endpoint agents. That distinction matters because the same risk behaves differently depending on where the agent lives. A poisoned artifact in CI/CD can propagate into every downstream build, a cloud agent can inherit delegated authority with limited visibility, and an endpoint agent may reach local credentials on a user workstation. The framework is really describing different governance boundaries, ownership models, and blast-radius profiles. Practical implication: segment controls by deployment zone instead of applying one uniform agent policy.
Practical implication: Align control ownership and blast radius to the zone where the agent actually operates.
What the expanded risk catalog reveals about agent failure modes
The new catalog entries point to a broader shift in how teams should think about agent risk. Memory poisoning, inter-agent instruction smuggling, MCP and tool-description poisoning, sandbox escape, and agent decommissioning are not isolated weaknesses. Together they show that agent security is as much about inherited context and delegated behaviour as it is about tool access. SAIL’s value is in making those failure modes legible across the lifecycle, from discovery through retirement. Practical implication: build governance around identity, context, and teardown, not just prompts and permissions.
Practical implication: Catalogue inherited context and offboarding as first-class agent security controls.
NHI Mgmt Group analysis
Static policy is the wrong abstraction for agent governance: SAIL 2.0 makes clear that agents are not governed well by rules written for human-paced systems. The important failure is not that policy is missing, but that policy written for stable sessions cannot describe chained, non-deterministic execution. For practitioners, the implication is that governance must attach to runtime action rather than pre-approved access alone.
Identity does not stay fixed long enough to be reviewed: access review cycles were designed for identities whose privileges persist long enough to be sampled and certified. That assumption fails when an agent acquires, combines, and consumes authority inside a short-lived workflow or delegated task. The implication is not merely better reviews; it is a need to rethink what reviewable identity even means in agentic systems.
The agentic attack surface is now a lifecycle problem, not a point-control problem: SAIL’s seven phases show that discovery, posture, testing, runtime enforcement, sandboxing, governance, and retirement all matter because risk moves across them. This is especially true where agent identities inherit access from makers, workflows, or local credentials. The practitioner conclusion is straightforward: lifecycle control is now the organising principle for agent security.
Maker-identity inheritance is a named concept teams should track: when an agent inherits the access of the person or process that created it, the governance model quietly transfers human privilege into machine execution. That turns an apparently normal build or no-code workflow into an unreviewed authority path. Teams should treat inherited identity as a distinct control issue, not as a subset of ordinary privilege management.
SAIL 2.0 shows the market is converging on operational governance language: the framework adds risk catalog depth, deployment zones, and standards mappings because teams no longer need abstract warnings; they need control mappings that can be executed. That tells us the category is moving from awareness to operationalisation. Practitioners should expect more emphasis on runtime enforcement, retirement, and cross-functional ownership.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: AI Agent Authorisation Guide
What this signals
Action-level governance is now the critical control pattern for AI agents: access reviews and session approval do not answer what an agent will do after it starts chaining tools. Teams need controls that inspect invocation, not just authentication, because behaviour can diverge after entry.
Maker-identity inheritance creates hidden privilege transfer: if a no-code builder or developer can ship an agent that inherits their access with no security review, governance has already failed before runtime begins. That is the exact place where discovery and authorisation must be joined.
Agent retirement is a control surface, not an admin chore: orphaned agents with live credentials and scheduled triggers behave like unowned identities with production access. Decommissioning has to revoke authority, remove stored context, and verify that no trigger can restart the actor.
For practitioners
- Map agent deployment zones Classify every agent into code and pipeline, cloud, or endpoint zones so ownership, blast radius, and control intensity match the real operating context.
- Enforce action-level guardrails Validate every agent action against policy before execution, rather than assuming a permitted session makes all downstream steps safe.
- Inventory inherited identities Identify where agents inherit maker credentials, user context, or local workstation access, then treat those inheritance paths as explicit governance items.
- Define retirement and revocation steps Require decommissioning procedures that revoke the non-human identity, rotate credentials, clear memory, and record an end-of-life audit trail.
Key takeaways
- AI agent governance fails when teams treat non-deterministic actors as if they were static software accounts.
- Pillar Security says SAIL 2.0 expands the risk catalog to 91 mapped risks and three deployment zones, showing how fast the control surface is growing.
- The practical response is to govern agent actions, inheritance, and retirement as separate lifecycle problems rather than relying on one access policy.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack surface, NIST AI RMF and NIST CSF 2.0 set the technical controls, and ISO/IEC 42001:2023 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on delegated authority, inherited access, and chained actions by AI agents. |
| ASI02 — Tool Misuse | SAIL 2.0 focuses on agents chaining tool calls and using tools beyond the intended review boundary. | |
| ASI08 — Cascading Failures | The framework highlights multi-agent workflows and downstream failure propagation across zones. | |
| Recommendation — Map agent delegation paths to ASI03 and restrict inherited privileges before runtime execution. Review tool permissions per invocation and block unsafe tool combinations under ASI02. Test multi-agent workflows for cascading failure and isolate agents so one compromise cannot fan out. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | SAIL 2.0 is an AI governance operating model with accountability, lifecycle, and control mapping. |
| Recommendation — Use GOVERN to assign ownership, escalation, and oversight for agentic systems across their lifecycle. | ||
| ISO/IEC 42001:2023 | A.4 — Context of the organization | The framework aligns agent security controls to lifecycle phases and organisational context. |
| Recommendation — Define the organisational context for agentic systems before assigning control ownership or scope. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | The article frames agent security as a programme-level risk management problem rather than a point fix. |
| Recommendation — Set a risk management strategy that treats agentic behaviour as a distinct governance domain. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes delegated credentials, chained actions, and movement across systems as core threat paths. |
| Recommendation — Map agent abuse paths to credential access and lateral movement to prioritise detection and containment. | ||
Key terms
- Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
- Action-level control: Action-level control is policy enforcement applied to each request, tool call, or data access rather than to the session as a whole. It is especially relevant for AI agents because their behaviour changes too quickly for static session controls to describe the real risk boundary.
- 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.
- Agent Retirement: Agent retirement is the controlled decommissioning of an AI agent when it is no longer needed or approved to run. It includes revoking credentials, clearing stored context, removing triggers, and proving that the agent cannot resume production access after ownership changes.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 9, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org