Security teams building on AI need practical, vendor-neutral patterns for supply chain integrity, agent identity and MCP, and the Coalition for Secure AI (CoSAI) is one of the few industry bodies producing them in the open. CoSAI is an OASIS Open Project whose four workstreams publish papers, runbooks and draft specifications on the AI software supply chain, preparing defenders, AI security risk governance and secure design for agentic systems. Its outputs are not a certification scheme, but several of them, notably MCP Security v2.0 with its assurance levels and the Artifact Integrity Maturity Model, are structured enough to audit against. This guide explains what CoSAI is, how its work is organised, what its main outputs require, the identity and NHI requirements in them, how to implement and evidence them, and how they map to other frameworks. It is for security architects, AI platform owners and GRC teams. It reflects CoSAI publications as read on 27 October 2026; papers are revised often, so check the version you use.
Key takeaways
- Four workstreams, one coalition. WS1 covers the AI software supply chain, WS2 preparing defenders, WS3 AI security risk governance and WS4 secure design patterns for agentic systems, all developed openly on GitHub under OASIS.
- MCP Security v2.0 is auditable. It defines four cumulative Security Assurance Profiles (Sandbox, Internal, Production, Regulated) with MUST and SHOULD controls across eight dimensions, chosen by data sensitivity and blast radius rather than topology.
- Authorisation stays outside the model. CoSAI's Zero Trust for AI Systems paper states that "authorization can never be delegated to the model itself" and calls for agents bound to users, short-lived scoped tokens and policy decision points that validate the full delegation chain.
- Supply chain assurance is graded. The Artifact Integrity Maturity Model sets three levels, from signed artefacts to provenance and lineage to structured attestations that policy engines can evaluate.
- Agent identity is being standardised. WS4's draft Open Delegation and Identity Standard (ODIS) links the principal, the delegated authority and the specific agent instance, extending OAuth 2.0, OpenID Connect, SPIFFE and SCIM.
What it is and who it applies to
CoSAI describes itself as an open ecosystem of AI and security experts from industry and academia, operating under OASIS Open, the standards and open source consortium. Governance follows the OASIS Open Project model, with a Project Governing Board and a Technical Steering Committee. Technical participation is free and open through the cosai-oasis GitHub organisation; sponsors fund the project. Premier sponsors listed on its site include EY, Google, Humana, IBM, Meta, Microsoft, NVIDIA, PayPal and TrendAI, with a longer list of general sponsors that includes major model providers, cloud and security vendors and universities.
Nothing in CoSAI is mandatory. Its outputs apply to anyone who builds, buys or operates AI systems and wants reference patterns that are vendor-neutral and openly reviewed. In practice the audiences are:
- AI platform and agent engineering teams: WS4 design patterns, MCP Security and runbooks.
- ML supply chain and MLOps teams: WS1 papers on supply chain risks and controls, ML artefact signing and AIMM.
- SOC, incident response and security architecture: WS2 papers on preparing defenders, AI incident response and zero trust.
- Risk, GRC and procurement: WS3 risk governance and the AI Shared Responsibility Framework.
Documentation in the workstream repositories is licensed CC-BY 4.0 and code Apache 2.0, according to the WS2 and WS3 repository READMEs, which makes the material straightforward to reuse in internal standards with attribution.
Structure and key requirements
| Workstream | Scope | Main outputs |
|---|---|---|
| WS1 Software Supply Chain Security for AI Systems | Integrity and provenance of models, data and AI components | Establish Risks and Controls for the AI Supply Chain; Signing ML Artifacts; Artifact Integrity Maturity Model (AIMM) |
| WS2 Preparing Defenders for a Changing Security Landscape | A defender's framework for investments in response to AI used by businesses, attackers and defenders | Preparing Defenders of AI Systems; AI Incident Response Framework; Zero Trust for AI Systems |
| WS3 AI Security Risk Governance | A security-focused risk and controls taxonomy, checklist and scorecard for AI products, services and components | AI Shared Responsibility Framework |
| WS4 Secure Design Patterns for Agentic Systems | Threat models, secure design patterns and infrastructure impacts for agents | MCP Security (v2.0); Agentic Identity and Access Management; ODIS draft; runbooks on tool design, input sanitisation and MCP runtime isolation; RFC-6 MCP Security Best Practices Gap Analysis; RFC-50 Trust-Aware Dataplane for Agentic Systems |
Other repositories in the organisation include Project CodeGuard and secure AI tooling. Treat RFCs and drafts as work in progress and papers as point-in-time guidance.
MCP Security v2.0 (WS4)
The second version of CoSAI's MCP paper, published in August 2026 and described as a strict superset of v1.0, keeps the threat taxonomy of 12 categories (MCP-T1 to MCP-T12) and 34 threats, including identity spoofing, confused deputy attacks, tool poisoning, resource content poisoning and shadow MCP servers. Its main addition is Security Assurance Profiles (section 3.3):
| Level | Name | Typical use | Notable requirements |
|---|---|---|---|
| 1 | Sandbox | Experiments, no sensitive data | Baseline controls |
| 2 | Internal | Internal tools and data | Adds to Level 1 |
| 3 | Production | Production systems and customer data | Sender-constrained tokens (DPoP or mTLS) mandatory; central agent gateway recommended for token validation, policy, workload identity exchange and audit |
| 4 | Regulated | Regulated data and high blast radius | Everything in Level 3 plus additional controls; gateway recommended |
Controls sit across eight dimensions: identity and authentication; authorisation and delegation; transport and network security; isolation and sandboxing; logging and observability; supply chain and lifecycle; tool, input and output integrity; and state and discovery security. Each control maps to an MCP-T category and to the OWASP MCP Top 10. The level is set by data sensitivity and blast radius, not deployment topology: CoSAI's example is that a local stdio deployment handling regulated health data should target Level 3. The paper also tracks the 2026-07-28 MCP release, in which protocol-level sessions and the Mcp-Session-Id header are removed for new implementations, and adds guidance on post-quantum migration and on gateways serving old and new clients. For MCP basics, see the MCP Security Guide.
Artifact Integrity Maturity Model (WS1)
| AIMM level | What it adds | Evidence |
|---|---|---|
| 1. Basic Artifact Integrity | Producers hash and sign artefacts at release; consumers verify hash and signature | Signatures and verification logs at a point in time |
| 2. Provenance and Lineage | Signed provenance and verifiable lineage across transformations such as fine-tuning, quantisation and distillation | Provenance records linking derived models to their sources |
| 3. Structured Attestations for Policy Automation | Attestations about model, data, process and infrastructure properties that policy engines evaluate for admission | Machine-readable attestations and admission decisions |
AIMM builds on SLSA, the in-toto attestation framework and SBOMs, adapting them to AI artefacts that change hands across organisations, and follows CoSAI's earlier Signing ML Artifacts paper. CoSAI notes that full Level 3 automation is still aspirational in many environments. See the Model Signing and OpenSSF Model Signing Guide and the SLSA and Build Provenance Guide.
Zero Trust for AI Systems (WS2)
The paper applies presume-breach and "never trust, always verify" to AI systems and recommends staged adoption: first an inventory of models, data and agents with access policies based on data classification, then initial controls (artefact verification, agent identity, input sanitisation, output filtering, observability), then per-session risk-adaptive access and AI-specific identity management, with behavioural analytics and adversarial red teaming reserved for higher-risk systems. See the Zero Trust for AI Agents Guide.
Identity and NHI requirements
Identity runs through CoSAI's agentic work more than any other theme. Collected across MCP Security v2.0, Zero Trust for AI Systems and ODIS, the requirements are:
| Requirement | Source | What it means in practice |
|---|---|---|
| Agents are a distinct identity class that does not inherit trust from users or services | Zero Trust for AI Systems | Each agent gets its own managed identity with narrowly scoped, continuously evaluated credentials |
| Bind agent sessions to the user's identity at the API gateway; remove broad service identities from agents | Zero Trust for AI Systems | No shared "god" service accounts for agents; on-behalf-of access |
| Short-lived, task-scoped tokens through token exchange | Zero Trust for AI Systems; MCP Security v2.0 (RFC 8693) | Exchange the user's token for a narrow, time-bound token per task and audience |
| Policy decision points validate the full delegation chain, using signed attestation of user and agent identity | Zero Trust for AI Systems | Authorise outside the model, with both identities as inputs |
| Agents have no visibility into access tokens and cannot influence policy decision points | Zero Trust for AI Systems | Inject credentials at the gateway or tool executor, not into model context |
| Sender-constrained tokens (DPoP, RFC 9449, or mTLS) at Level 3 | MCP Security v2.0 | Stolen bearer tokens cannot be replayed from elsewhere |
Self-reported identity in _meta is untrusted; reconcile with the authenticated principal and fail closed | MCP Security v2.0 | Never authorise on client-asserted identity fields |
| Server-held references unguessable, tenant-scoped, revocable and logged; task handles are locators, not authorisation tokens | MCP Security v2.0 | Check authorisation on every read of a named resource |
| Link principal, delegated authority and agent instance | ODIS draft | Audit trails that show who an agent acted for, under what grant, and which instance acted |
These align closely with the controls described in the Confused Deputy in AI Agents Guide and the OAuth Token Exchange and Delegation Guide. For workload identity foundations referenced by ODIS, see the SPIFFE and SPIRE Guide. WS4 also publishes an Agentic Identity and Access Management whitepaper; read it directly for its full recommendations.
Implementation steps
- Pick the outputs that match your risk. Agent and MCP builders start with MCP Security v2.0 and the WS4 runbooks; ML platform teams with AIMM and the supply chain paper; SOC and IR teams with the WS2 papers; GRC with the shared responsibility framework.
- Classify each MCP deployment. Assign a Security Assurance Profile level from data sensitivity and blast radius. Record the level and the reasoning.
- Run a gap assessment per dimension. Compare existing controls against the level's MUST and SHOULD requirements across the eight dimensions, as CoSAI suggests, rather than rereading the whole paper. Track gaps against MCP-T categories.
- Fix identity first. Remove shared agent service accounts, introduce token exchange for on-behalf-of access, validate audiences, and plan sender-constrained tokens for Level 3 and above.
- Introduce a gateway for Levels 3 and 4. Centralise token validation, policy evaluation, workload identity exchange and audit logging, piloting with one agent and one MCP server before migrating others. Keep the old path available as rollback until logs show parity.
- Set an AIMM target per model source. Level 1 for all third-party models (verify signatures and hashes), Level 2 for models you fine-tune or quantise, Level 3 where you can automate admission policies.
- Adopt WS2 zero trust in stages. Inventory and data-classification policies first, then the initial controls, then adaptive access.
- Track versions. Subscribe to the CoSAI repositories and mailing list, and re-run gap assessments when a paper version or the MCP specification changes.
Evidence and assessment
CoSAI does not certify anyone, so assessments are internal or performed by your assurance provider against CoSAI criteria. Evidence that works well:
- MCP assurance register: each MCP server and client, its assigned level, gap assessment by dimension, and remediation status.
- Identity evidence: token configuration showing audience validation, token lifetimes, DPoP or mTLS binding, and gateway policy logs that show both user and agent identity per decision.
- Supply chain evidence: signature verification logs, provenance records and admission decisions for each model, with the AIMM level achieved.
- Zero trust evidence: the AI asset inventory, data classification policies and the stage reached in the adoption plan.
| Metric | Target |
|---|---|
| MCP deployments with an assigned assurance level and current gap assessment | 100 per cent |
| Level 3 and 4 deployments using sender-constrained tokens through a gateway | 100 per cent |
| Agents running on shared broad service identities | Zero |
| Third-party models verified at AIMM Level 1 or higher before use | 100 per cent |
| Open MUST-level gaps older than 90 days | Zero, or accepted by a named risk owner |
Mapping to other frameworks
| CoSAI output | Related framework | Relationship |
|---|---|---|
| MCP Security v2.0 | OWASP MCP Top 10; MCP specification | Every control maps to the OWASP MCP Top 10; the paper tracks MCP specification releases |
| MCP Security v2.0 assurance levels | SLSA | Levels numbered in the SLSA style; cumulative |
| AIMM | SLSA, in-toto, SBOM; NIST SP 800-53 SR-3, SR-4 Provenance, SR-11 Component Authenticity | Adapts software supply chain integrity to AI artefacts |
| Zero Trust for AI Systems | NIST zero trust principles; SP 800-53 AC-6, SA-8; CSF 2.0 PR.AA-05 | Applies presume-breach and least privilege to models, data and agents |
| AI Incident Response Framework | NIST SP 800-53 IR-4, IR-8; CSF 2.0 RS.MA-01 | Extends incident handling to AI-specific incidents |
| AI Shared Responsibility Framework | CSF 2.0 GV.RR-02, GV.SC-01 | Clarifies roles between AI providers, platforms and customers |
| Risk governance (WS3) | ISO/IEC 42001; NIST AI RMF | Security-focused taxonomy, checklist and scorecard that can feed an AI management system |
| ODIS draft | OAuth 2.0, OpenID Connect, SPIFFE, SCIM | Extends existing identity standards for agent delegation |
For governance context see the ISO/IEC 42001 Guide and the NIST AI RMF Guide.
Common pitfalls
- Treating CoSAI papers as certifications: they are guidance; a claim of "CoSAI compliant" means nothing without the level, version and gap assessment behind it.
- Choosing an MCP level by topology: calling a local stdio server "Sandbox" because it runs on a laptop, even though it touches regulated data.
- Stopping at signing: AIMM Level 1 proves an artefact was not altered after release, not where it came from or how it was derived.
- Reading the blog, not the paper: summaries omit the MUST and SHOULD detail that an assessment needs.
- Ignoring version drift: MCP Security v2.0 already reflects protocol changes such as the removal of protocol sessions; controls written for older assumptions need review.
- Relying on drafts as stable: ODIS and the WS4 RFCs are evolving; design to their principles, but avoid hard dependencies on draft details.
Practitioner checklist
- Identify which CoSAI workstream outputs apply to your AI systems and assign owners for each.
- Assign an MCP Security v2.0 assurance level to every MCP deployment based on data sensitivity and blast radius.
- Complete a gap assessment across the eight control dimensions and track gaps against MCP-T categories.
- Replace shared agent service accounts with agent identities bound to users through token exchange.
- Use sender-constrained tokens and a central gateway for Level 3 and 4 deployments.
- Never authorise on self-reported identity fields; make task handles locators, not credentials.
- Set and evidence an AIMM level for each model source, starting with signature and hash verification.
- Adopt the WS2 zero trust stages, starting with an AI asset inventory and data-classification policies.
- Record the CoSAI paper version used in every assessment and re-assess on new releases.
Standards and references
- Coalition for Secure AI: Home
- CoSAI WS4: Model Context Protocol Security v2.0
- CoSAI: MCP Security Version 2.0 overview
- CoSAI: Zero Trust for AI Systems
- CoSAI: Artifact Integrity Maturity Model
- CoSAI: Open Delegation and Identity Standard working session
- CoSAI: GitHub organisation and publications
- Model Context Protocol: Security Best Practices
Related NHI Mgmt Group resources: Securing Agent Frameworks Guide · MCP Security Guide · AI Supply Chain and AI-BOM Guide · Zero Trust for AI Agents Guide · Shared Responsibility Models Guide