SAIL 2.0 says it plainly: "static policy can't govern a non-deterministic actor" and "authorize every action, not just every session." That is precisely the problem polysec exists to solve — with a policy you can model-check instead of prose you can only hope is followed. Below, the mapping in SAIL's own vocabulary: phase by phase, risk ID by risk ID.
SAIL X.Y identifiers, and mappings to ISO/IEC 42001, NIST AI RMF, OWASP, the EU AI Act, DASF, and AIUC-1. Cognitive Fab is not affiliated with or endorsed by Pillar Security; this page maps our approach onto their framework because their risk IDs are becoming the shared language of agentic security reviews — SAIL itself recommends using them in vendor assessments.
SAIL organizes 91 risks across seven phases. polysec and polyman address a specific, provable slice of them: the risks that reduce to reachable-bad-state problems — where the right control is a policy you prove airtight at design time and enforce unchanged at runtime. Each row states what our method contributes, in method-level terms.
| SAIL ID | Risk (as cataloged) | Where polysec fits |
|---|---|---|
| Phase 1 · AI Policy (Plan) | ||
| SAIL 1.12 | No Action-Authorization Policy Defined | The policy is a machine-checkable artifact, not prose: an action-authorization state machine whose properties you prove before any agent runs under it. |
| SAIL 1.9 | Incomplete Threat Modeling for AI and Agentic Systems | Forbidden regions are declared as predicates over state, not enumerated attack paths — and the adversary is modeled as maximal nondeterminism, which covers the channels nobody thought to draw. |
| Phase 3 · Agentic Posture (Build) | ||
| SAIL 3.11 | Insufficient Understanding of Agent Reachable Graph | Exhaustive reachability over the declared domains is the core check. The reachable graph isn't estimated or diagrammed — it is walked, completely, and any path into a forbidden region comes back as the shortest counterexample. |
| SAIL 3.16 | Missing Per-Action Authorization Policy at Build | The same policy artifact is fixed at build time and model-checked before it ships — so "posture floor" is a proven property, not a configuration intention. |
| SAIL 3.18 | Posture Drift / Configuration Drift Over Time | Every policy change is version-gated: classified by compatibility and proved safe against the state already live in the fleet before it deploys. |
| Phase 4 · Agentic Red Teaming (Test) | ||
| SAIL 4.1 | Untested Agent | The design-time gates attack their own verdict before certifying: adversarial havoc over unmediated variables, a gate-deletion bypass hunt, and a named witness trace on every failure. Deterministic, repeatable on every commit. |
| SAIL 4.8 | Untested Tool Chain and Multi-Agent Workflows | Properties are checked over every reachable ordering of the declared actions — the tool-chain interleavings a sampled red-team run can't cover — and cohort-level invariants extend the same discipline past a single agent. |
| SAIL 4.10 | Untested Reasoning-Chain Manipulation | Complementary by design: we don't test the reasoning, we bound its consequences. However the chain was manipulated, the actions it can commit are the ones the proven machine accepts. |
| Phase 5 · Runtime Controls (Deploy) | ||
| SAIL 5.13 | Missing Action-Level Authorization at Runtime | The flagship fit. Every tool call is a mediated proposal against the proven policy — default-deny, per invocation, session state remembered. A denial names the rule it broke; unknown tools and unlabeled effects refuse rather than pass. |
| SAIL 5.8 | Sensitive Data Exfiltration via Agent Output or Tool Calls | The canonical policy ships with the gate: a session that has ingested untrusted content and touched a secret cannot open egress — the lethal-trifecta combination is refused before the call runs, whichever order the steps arrive in. |
| SAIL 5.9 | Goal Hijacking / Intent Manipulation | The gate never asks what the agent intends. A hijacked goal still has to step the same machine — and the forbidden region is no more reachable after the hijack than before it. |
| SAIL 5.20 | Privilege Amplification via Confused-Deputy Agent | Composition hazards are first-class: capabilities that are each fine alone and forbidden together are exactly the properties a state-machine policy expresses and a model checker proves. |
| Phase 6 · Sandbox (Operate) | ||
| SAIL 6.2 | Unrestricted API/Tool Invocation | Per-invocation mediation with memory: the decision depends on what the session has accumulated, not on the current call in isolation — which is what makes escalation-by-chaining a checkable property. |
| SAIL 6.4 | Task Decomposition for Policy Evasion | The property lives on accumulated state, so splitting a prohibited task into benign-looking subtasks changes nothing: each subtask steps the machine, and the forbidden combination stays unreachable no matter how the work is sliced. |
| SAIL 6.14 | Irreversible Agent Actions Without Rollback Path | Recovery is proven, not improvised: from every danger state, corrective transitions are checked to converge without re-entering the forbidden region — and containment vs. restoration is recorded as a first-class distinction. |
| Phase 7 · Govern (Monitor & Retire) | ||
| SAIL 7.1 | Insufficient AI and Agent Interaction Logging | One journaled transaction per dispatch — state before, action, data, state after — the ground-truth stream every other check consumes, including denials with their reasons. |
| SAIL 7.3 | Undetected Agent Drift | Audit by replay: run the journal back through the deployed policy, and any divergence between record and policy is a finding, not a log line. Drift is treated as intrusion until shown otherwise. |
| SAIL 7.6 | Missing Agent-Specific Anomaly Detection | An out-of-band diagnoser maintains the set of states consistent with what's observable and alarms on early (tolerant) or certain (sound) semantics — and fleet-level invariants catch the aggregate patterns no single instance exhibits. |
SAIL asks you to authorize every action, not just every session. We'd add one word: provably.
A mapping you can trust has to name its edges. Large parts of the SAIL catalog are out of polysec's scope by design, and need the tools built for them:
Discovery (Phase 2) — inventorying agents, shadow AI, and third-party integrations is upstream of us; we assume you know which agents you're gating. Execution isolation (SAIL 6.1, 5.15) — polysec is a reference monitor, not a sandbox; a compromised runtime that opens its own socket around the gate is confinement's job. Content inspection (SAIL 5.3–5.5) — we don't detect prompt injection or mask PII; we make the injected action refuse rather than the injected text visible. Supply chain and credential hygiene (SAIL 3.8, 3.9, 3.12, 6.3) — vetting components and rotating secrets are their own disciplines.
And in SAIL's own words about its standards mappings: alignment, not automatic compliance. The same applies here — this table tells you where the method fits, not that a checkbox is checked.
The honest disclosure. Every "proven" above means: model-checked exhaustively over the finite action and data domains the policy declares, with the residual named — gate bypass, unmodeled channel, and the frontier below the state-machine layer. A consistency check, not a certificate of invulnerability.
This page describes the method against the risks where the fit is structural. How far coverage extends across the rest of the 91-risk catalog — and what the mapping looks like against your own agent estate, your autonomy tiers, and the frameworks you answer to — is the domain of the polysec enterprise edition. If your security review speaks SAIL, come speak it with us.
No. SAIL is a lifecycle framework and risk catalog; polysec is a verification and enforcement engine. This page exists because SAIL's risk IDs are becoming the shared language of agentic security reviews, and teams adopting SAIL deserve a precise answer to "which of these rows does a proof-based gate actually address?"
No — they stack. polysec governs capability state with a model-checked, default-deny policy. Content inspection and execution isolation are different layers, and SAIL is right to require all of them. What polysec uniquely covers is the class per-call filters structurally miss: properties of what a session has accumulated.
For the design-time rows: the policy machine is checked over every reachable ordering of its declared actions before deployment — not a sampled test suite — and failures return the shortest counterexample. For the runtime rows: the exact proven machine is what executes, so the authorization decision is a state transition, not a judgment with a false-negative rate.