SAIL 2.0 signals a shift toward runtime AI agent security

At a glance

What this is: Pillar Security’s SAIL 2.0 framework positions secure AI agents as a continuous discovery, testing, and runtime control problem, with attack-surface mapping and guardrails linked into one loop.

Why it matters: It matters because AI agents increasingly behave like governed identities with tool access, so IAM, PAM, and security teams need controls that cover both pre-runtime approval and live execution.

By the numbers:

• Gartner forecasts worldwide AI cybersecurity spending to nearly double in 2026, from $25.9 billion to $51.3 billion.
• Just 14% of software engineering teams surveyed have advanced skills in AI security or platform engineering.
• Pillar says Gartner expects AI cybersecurity spending to reach $86 billion by 2027.

👉 Read Pillar Security's analysis of SAIL 2.0 and secure AI agents

Context

AI agent security is becoming a governance issue, not just a model security issue. Once an agent can hold credentials, call tools, and touch production systems, it starts to resemble a non-human identity with delegated authority that can be misused, over-scoped, or poorly observed.

Pillar Security’s framing is that the control problem spans discovery, validation, and runtime enforcement. That is the right lens for teams trying to govern agent behaviour without assuming static policy, because agentic systems can change what they touch far faster than traditional review cycles can keep up.

Key questions

Q: How should security teams govern AI agents that can use tools autonomously?

A: Start by treating each agent as a governed identity with specific permissions, owners, and approved tools. Then enforce least privilege at the point of execution, not only at onboarding, and require evidence that risky actions can be blocked before they complete. If an agent can change systems, its access must be auditable and revocable like any other high-risk identity.

Q: Why do AI agents complicate access reviews and IAM controls?

A: AI agents complicate IAM because their permissions are often distributed across tools, prompts, data sources, and execution environments. Access reviews assume stable entitlements that can be reviewed later, but agent behaviour may change by task, context, or orchestration path. Teams need live inventory and runtime enforcement to keep governance current.

Q: What breaks when AI agent guardrails exist only in policy documents?

A: Policy-only guardrails fail when an agent can act at machine speed and the control cannot interrupt the action. Logging after the fact may help investigation, but it does not stop data movement or system change. Effective guardrails must operate where the agent calls tools, accesses data, or attempts escalation.

Q: Should organisations re-evaluate IAM and PAM for agentic AI deployments?

A: Yes, because agentic systems can inherit credentials and exercise privileged tools in ways that traditional IAM and PAM reviews do not fully capture. Organisations should reassess whether their current models account for ephemeral tasks, delegated authority, and machine-speed execution. The key test is whether access can be constrained to the exact task and revoked immediately afterward.

Technical breakdown

AI agent attack surface mapping and AI-BOM

An AI-BOM is an inventory of AI assets, including agents, models, prompts, tools, datasets, and configuration links. In this model, the problem is not only whether a model exists, but what it can reach and which supply-chain components influence its behaviour. Mapping from source code, endpoints, and CI/CD into a live inventory gives defenders a way to connect an agent to its tools, data paths, and risk exposure. That is especially important when an agent can inherit permissions from multiple systems and appear harmless in isolation.

Practical implication: Practitioners should build an asset inventory that ties each AI agent to credentials, tools, and data dependencies before allowing production access.

Red teaming AI agents with chained tool calls

Agent red teaming is different from prompt testing because it evaluates behaviour across a sequence of actions, not a single response. A realistic adversarial agent may chain tool calls, probe for reachable systems, and move from reconnaissance to misuse within one workflow. That means security testing has to examine how the agent reasons about tools, how it selects actions, and where guardrails fail when context changes mid-task. The useful output is not just a finding, but replayable evidence of the path the agent took and the control gap it exposed.

Practical implication: Use multi-step attack simulations to validate whether agent privileges, tool permissions, and escalation paths hold up under adversarial chaining.

Runtime guardrails for irreversible agent actions

Runtime guardrails are enforcement controls that sit where the agent actually acts, rather than only where it is designed. They matter because agents can make decisions and execute them at machine speed, which compresses the time available for human review. A guardrail system has to check context, limit tool use, and stop unsafe actions before they become state changes in production systems. If runtime enforcement only logs activity after the fact, it is a detection tool, not a containment control.

Practical implication: Deploy runtime policy checks that can block tool use, credential use, or data access before the agent completes the action.

Threat narrative

Attacker objective: The attacker wants to hijack the agent’s delegated authority so it can be used as a trusted path into systems and data the user should not be able to reach directly.

1. Entry begins when an AI agent is granted credentials, tool access, or a route into production systems, creating a usable foothold for abuse.
2. Escalation occurs when the agent chains tool calls or follows malicious steering into systems it was not intended to reach, turning delegated access into broader reach.
3. Impact follows when the agent performs irreversible actions at machine speed, including misuse of data, unauthorized system access, or operational disruption.

NHI Mgmt Group analysis

AI agents are becoming governed identities, not just software features. Once an agent can authenticate, call tools, and act across systems, the real control problem shifts to delegated authority, not model quality. That changes how security teams think about access reviews, least privilege, and privilege persistence for non-human actors. Practitioners should treat agent identity as a first-class governance object.

Discovery without runtime enforcement is incomplete for agent security. The article’s loop of inventory, red teaming, and guardrails reflects the right sequencing because an AI system that is well documented can still be unsafe in execution. Static approval models miss the point when an agent can re-plan, re-order tools, or change behaviour in response to context. Practitioners should align controls to execution time, not only onboarding time.

AI governance debt is now an operational security issue. Enterprises can accumulate undocumented tools, prompts, and agent connections faster than they can classify or review them, which creates invisible access paths. That is not just a model-risk concern. It is a governance failure that maps directly to access control gaps, audit gaps, and incident-response blind spots. Practitioners should reduce AI governance debt before agent sprawl becomes normalised.

Runtime guardrails need to be evaluated like containment controls, not policy documentation. A policy that exists only on paper does not protect a live agent when it is chaining actions at machine speed. The important question is whether the control can stop an action before data moves or systems change. Practitioners should demand evidence that guardrails can interrupt execution, not merely record it after the fact.

What this signals

AI governance debt will show up first as identity debt. As more agents reach production, the fastest-growing risk is not model accuracy but undocumented authority: which agent can authenticate, which tool it can call, and which data it can move. Teams should expect the review burden to shift from model inventory to delegated access inventory, with NIST AI Risk Management Framework and runtime control patterns becoming more relevant to operational assurance.

Machine-speed execution changes the response window for security teams. Once an agent can complete a chain of actions before a human review cycle even starts, the useful control point is pre-action enforcement. That makes detection-only strategies less effective and raises the value of runtime blocking, audit-quality evidence, and revocation workflows tied to the agent’s actual tool use.

AI agent sprawl will increasingly look like NHI sprawl. The operational question is no longer whether an AI system exists, but whether its permissions are bounded, attributable, and revocable in real time. Teams that already struggle with service accounts and secrets management should expect the same failure modes to reappear unless agent identities are governed with the same discipline.

For practitioners

• Build an AI agent inventory tied to access paths Map every production agent to credentials, tools, prompts, datasets, and environments so the security team can see what each agent can reach and who owns it.
• Test agents with multi-step adversarial scenarios Run red-team scenarios that chain tool calls, probe reachable systems, and attempt privilege expansion so you can see where the agent breaks containment.
• Enforce runtime policy before actions execute Place control checks at the moment of tool use or data access so unsafe actions can be blocked before the agent completes them in production.
• Review agent privileges like standing access Treat long-lived tool permissions and inherited credentials as standing access and remove anything that is broader than the agent’s immediate task scope.

Key takeaways

• AI agents now create a governance problem that looks much more like non-human identity management than traditional software deployment.
• Pillar Security’s framing reflects a wider market reality: discovery, red teaming, and runtime enforcement have to work together if agent risk is to be contained.
• For practitioners, the immediate priority is to map every agent to its credentials, tools, and data paths, then prove those privileges can be stopped at runtime.

Key terms

• AI-BOM: An AI bill of materials is an inventory of the parts, dependencies, and connections behind an AI system. In practice it should show the agent, model, prompts, tools, datasets, and environments it touches so security teams can understand exposure and ownership.
• Runtime Guardrails: Runtime guardrails are controls that evaluate an AI agent’s actions while it is operating, not just when it is approved. They can restrict tool use, block unsafe access, or stop execution before a risky action changes data or systems.
• Agentic AI Security: Agentic AI security is the discipline of governing AI systems that can decide and act across tools and data sources. It focuses on identity, delegation, permissions, and containment because the risk comes from what the agent is allowed to do, not only what it can generate.
• AI Governance Debt: AI governance debt is the gap that builds when organisations deploy AI faster than they can inventory, classify, and control it. It shows up as undocumented tools, unclear ownership, weak review cycles, and controls that are no longer aligned to live behaviour.

What's in the full article

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

• The specific RedGraph testing flow used to graph agent attack paths and replay adversarial scenarios.
• The AI-BOM inventory fields that tie agents, prompts, models, tools, and datasets into one live asset map.
• The runtime guardrail behaviour used to enforce policy on agent actions before they complete.
• The audit-evidence format the vendor uses to show findings, retests, and compliance output.

👉 Pillar Security's full post covers the RedGraph workflow, AI-BOM mapping, and runtime guardrail detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in a way that helps practitioners structure access and control decisions. It is useful for security teams that need a practical foundation for governing machine-speed identities alongside human access.