ai-safe2-framework

AI SAFE² Framework v3.1

Documentation map · Developer Workflow · CLI 1.0 workflow · Security advisories · Topic registry

Evaluate technology: Technology Contribution Profile · Evidence Assurance Level · Collect evidence

The Universal GRC Standard for Agentic AI, Swarm Governance, and Runtime Enforcement

Use the CLI · Why AI SAFE² · Architecture · MCP Security · Challenge Lab · Dashboard

Use AI SAFE² with an agent

If your immediate goal is to inspect an agent project—not read the entire framework—start with the safe2 CLI.

If your goal is to give a software team a repeatable, provider-neutral pull request and release process, start with the AI SAFE² Developer Workflow. The contract preview supports teams using Claude and Codex together without replacing either tool's configuration. It routes game and other software changes through proportionate evidence requirements, attributes each reviewer or scanner, and preserves the human merge and release decision.

The package now starts with the developer outcome, shows the before/after pull request flow, explains its folder structure, and generates a repository-specific report of the installed routes, review options, trust boundaries, limitations, and next extensions. Teams can begin with routing and deterministic checks, then add stronger planning with Superpowers, semantic review, Codex or Claude security review, strategic Greptile review, or runtime evidence where the risk justifies it. See the Adoption Guide, Tool Setup and Capability Selection, and game quickstart.

Use it when you need to:

• inventory a machine or repository running one or several agent harnesses;
• assess a project without treating missing evidence as “safe”;
• screen a downloaded or newly created skill before activation;
• bind results to the model, harness, tools, memory, environment, and policy that were actually assessed;
• check an agent's completion claim against receipts and test evidence;
• turn AISM findings into a human-owned remediation decision; or
• create replayable Challenge Lab evidence.

The shortest safe start

python -m pip install "ai-safe2[all]==1.1.0"
safe2 self-check --strict
safe2 start .
mkdir review-project
cd review-project
safe2 init .
safe2 assess . --scan-content --inspect-config

The assessment writes canonical JSON for agents and a readable Decision Card for people. It does not authorize a fix, deployment, exception, or compliance claim.

Prefer to delegate setup?

Give your agent the copyable instruction in Give this to your agent. The same provider-neutral workflow can be invoked from Codex, Claude Code, Hermes, OpenClaw, Antigravity, MiroFish, TinyFish, bots, CI, or another harness that can run a local command and preserve evidence files. That means the harness can use the CLI; it does not imply that every named product has a native adapter.

The 10-Second Version

AI SAFE² is an engineering and governance contract for agentic AI. It defines what must be governed, what must be enforced, and what evidence must exist when autonomous systems act.

The framework contains 161 controls, organized across five operational pillars plus a Cross-Pillar Governance Layer. AI SAFE² v3.1 keeps the overall framework control total at 161 while materially updating the MCP security profile for the Model Context Protocol 2026-07-28 specification.

Version 3.1 also formalizes three enforcement planes:

AI SAFE² specifies the required outcomes and evidence. NEXUS is Cyber Strategy Institute's first-party reference implementation for agent-to-agent and agent-to-tool enforcement. Organizations may use NEXUS or another implementation that demonstrably satisfies the applicable AI SAFE² controls.

What AI SAFE² Is For

Production agents can drift without a code change. Retrieval changes, accumulated memory, delegated authority, tool calls, identity confusion, protocol behavior, or changes in external services can alter the effective operating environment while the source code remains unchanged.

AI SAFE² defines the operating envelope around those systems. It combines governance, identity, runtime enforcement, auditability, fail-safe behavior, adversarial testing, protocol security, and evidence requirements so an organization can reconstruct why an autonomous action was allowed, rejected, halted, or escalated.

What both builders and governors get

• A single control vocabulary across agent runtime, identity, memory, tools, delegation, and evidence.
• Runtime enforcement patterns rather than policy-only guidance.
• Named fail-safe authority and kill-switch governance.
• Agent replication and non-human identity controls.
• Memory and RAG governance.
• MCP security controls for both provider and consumer risk.
• Mapping to 32 governance, security, privacy, and AI frameworks.
• Challenge Lab experiments designed to falsify framework claims rather than merely demonstrate the framework.

What Changed in v3.1

AI SAFE² v3.1 is primarily a protocol-governance and enforcement-plane release.

MCP 2026-07-28 realignment

The MCP core became substantially more stateless. AI SAFE² v3.1 therefore removes governance dependencies on protocol-owned session concepts and instead binds governance to framework-owned constructs such as:

• verified principal identity;
• capability grants;
• delegation chains;
• provenance baselines;
• explicit trust-establishment events;
• principal-scoped state handles;
• policy and authorization evidence.

The governing design rule is:

A CP.5 profile MUST NOT bind a control to a construct owned by the protocol it profiles.

CP.5.MCP expands from 13 to 19 sub-controls

The six v3.1 additions are:

The overall AI SAFE² framework remains 161 controls. MCP-14 through MCP-19 are profile-level sub-controls within CP.5, not six additional top-level framework controls.

Compatibility

MCP 2025-11-25 remains a legacy compatibility binding for a twelve-month migration window. Mcp-Session-Id, when encountered in the legacy binding, is treated as a principal-scoped state handle rather than identity or the authorization boundary.

server/discover is optional under MCP 2026-07-28; AI SAFE² does not require its presence for conformance.

The Core Architecture

The framework is organized around 5 Operational Pillars plus the Cross-Pillar Governance Layer, which was introduced in v3.0 and remains the governance operating system in v3.1.

CP.5 in v3.1

CP.5 provides platform and protocol-specific security profiles without allowing the profiled protocol to define the governance boundary. The v3.1 MCP profile is the primary example of this principle.

See: CP.5.MCP, MCP Server Security Profile

Assess Organizations, Technologies, and Evidence Separately

Documentation updated: 2026-10-13. Start with the AISM assessment guide to use all three instruments with the Technology Card and a worked example. Full assessment documentation lives under AISM. To evaluate a product or solution, send the technology evidence request, collect dated artifacts, and record contribution and assurance separately in the card.

An organization earns an AISM maturity level. A technology contributes evidence for specific controls within a defined boundary. A paper, benchmark, released implementation, or vendor test cannot establish organizational maturity by itself.

AISM is the AI Sovereign Maturity (AISM) Model, which assesses the organization's