1. Why CoSAI Needs an Independent Evidence Layer
The CoSAI Risk Map is a shared taxonomy. It names the threats, categorizes the controls, and identifies the personas responsible for each. What it does not provide is independent proof that controls were active at runtime.
CoSAI controls like Agent Observability, Execution Integrity, and Orchestrator Route Integrity describe what organizations should do. SWT3 witness anchors prove that they did do it. The distinction matters under EU AI Act Article 12 (record-keeping), NIST AI RMF Map 1.5, and any audit where "we have a policy" is not sufficient evidence.
This crosswalk maps every CoSAI risk category to the SWT3 procedures that generate non-repudiable evidence of control enforcement. The risk taxonomy stays with CoSAI. The evidence protocol is SWT3. Both are needed.
2. CoSAI Risk Map Architecture
The CoSAI Risk Map organizes AI security into four component areas, six control domains, eight personas, and 30 named risks.
Component Areas
| Area | Scope |
|---|---|
| Data | Training data, evaluation datasets, inference-time user data, vector stores |
| Infrastructure | Compute, model hosting, TEEs, MLOps platforms, serving environments |
| Model | Architecture, weights, adapters, input/output validation, adversarial robustness |
| Application | Agent frameworks, tool registries, user-facing controls, permissions, observability |
Control Domains (6)
| Domain | Controls | SWT3 Coverage |
|---|---|---|
| Data Controls | 6 controls (privacy, sanitization, data management, vector integrity) | Full |
| Infrastructure Controls | 7 controls (access, integrity, isolation, transport, identity) | Full |
| Model Controls | 3 controls (input validation, output validation, adversarial testing) | Full |
| Application Controls | 8 controls (access, agent permissions, observability, execution bounds) | Full |
| Assurance Controls | 4 controls (red teaming, vuln management, threat detection, incident response) | Full |
| Governance Controls | 4 controls (policies, education, product governance, risk governance) | Full |
Coverage indicates SWT3 can produce independent evidence for controls in each domain. SWT3 is an evidence layer, not an enforcement layer.
Personas (8)
CoSAI defines eight roles across the AI lifecycle: Model Provider, Data Provider, AI Platform Provider, AI Model Serving, Agentic Platform and Framework Provider, Application Developer, AI System Governance, and AI System User. SWT3 witnessing applies to all eight. The protocol is role-agnostic: whoever runs inference, mints the anchor.
3. Risk-to-Evidence Crosswalk Table
Each CoSAI risk maps to one or more SWT3 procedures that produce independent evidence of mitigation. The table below covers all 30 named risks.
| CoSAI Risk | Category | SWT3 Procedure(s) | Evidence |
|---|---|---|---|
| Data Poisoning | Supply Chain | AI-DATA.1, AI-DATA.2 | Training data provenance hash, sanitization timestamp |
| Unauthorized Training Data | Supply Chain | AI-DATA.1, AI-CONSENT.1 | Data authorization record, consent chain |
| Model Source Tampering | Supply Chain | AI-MDL.5, AI-SBOM.1 | Model weights SHA-256, SBOM integrity hash |
| Excessive Data Handling | Supply Chain | AI-DATA.1, AI-DPIA.1 | Data scope record, DPIA evidence anchor |
| Excessive Data Handling (Inference) | Runtime Data | AI-LOG.1, AI-DPIA.1 | Inference data scope, clearing level enforcement |
| Model Exfiltration | Deployment | AI-MDL.5, AI-SEC.1 | Access control record, model hash verification |
| Model Deployment Tampering | Deployment | AI-MDL.5, AI-SUPPLY.1 | Deployment integrity hash, supply chain anchor |
| Denial of ML Service | Runtime Input | AI-PERF.1, AI-COST.1 | Resource consumption witness, rate limit evidence |
| Model Reverse Engineering | Deployment | AI-ACC.1, AI-SEC.1 | Access scope record, query rate evidence |
| Insecure Integrated Component | Deployment | AI-TOOL.1, AI-SBOM.1 | Tool call witness, component integrity hash |
| Prompt Injection | Runtime Input | AI-GRD.1, AI-GRD.2 | Guardrail evaluation record, input validation anchor |
| Model Evasion | Runtime Input | AI-GRD.1, AI-REDTEAM.1 | Adversarial test evidence, guardrail state |
| Sensitive Data Disclosure | Runtime Data | AI-LOG.1, AI-FAIR.1 | Clearing level enforcement, output classification |
| Inferred Sensitive Data | Runtime Data | AI-FAIR.1, AI-DPIA.1 | Inference classification, privacy impact anchor |
| Insecure Model Output | Runtime Output | AI-GRD.1, AI-GRD.3 | Output validation record, guardrail enforcement |
| Rogue Actions | Runtime Output | AI-TOOL.1, AI-ACC.1, AI-DEL.1 | Tool call witness, access scope, delegation tree |
| Accelerator Side-Channels | Deployment | AI-HW.1, AI-SEC.1 | Hardware attestation, isolation verification |
| Economic Denial of Wallet | Runtime Input | AI-COST.1, AI-PERF.1 | Cost witness, execution bounds evidence |
| Federated Training Privacy | Supply Chain | AI-DATA.1, AI-SEC.1 | Gradient isolation record, privacy control anchor |
| Adapter/PEFT Injection | Deployment | AI-MDL.6, AI-MDL.5 | Adapter stack hash, weights integrity |
| Tool Registry Tampering | Deployment | AI-TOOL.1, AI-SUPPLY.1 | Tool manifest hash, registry integrity anchor |
| Orchestrator/Route Hijack | Runtime Output | AI-INF.1, AI-CHAIN.1 | Inference provenance, chain-of-custody proof |
| Evaluation Benchmark Manipulation | Runtime Data | AI-ASSESS.1, AI-DRIFT.2 | Assessment witness, drift threshold anchor |
| Covert Channels in Outputs | Runtime Output | AI-GRD.1, AI-LOG.1 | Output validation, logging integrity |
| Malicious Loader/Deserialization | Deployment | AI-SUPPLY.1, AI-SBOM.1 | Supply chain witness, dependency integrity |
| Retrieval Vector Store Poisoning | Runtime Data | AI-RAG.1, AI-RAG.2 | RAG provenance, retrieval relevance anchor |
| Prompt/Response Cache Poisoning | Runtime Data | AI-INF.1, AI-SEC.1 | Cache integrity record, inference provenance |
| Shadow/Unknown Agents | Agentic | AI-ID.1, AI-CHAIN.1 | Agent identity binding, inventory chain |
| Zombie/Shadow MCP Servers | Agentic | AI-ID.1, AI-SUPPLY.1 | Server identity anchor, lifecycle witness |
| Delegation Chain Opacity | Agentic | AI-DEL.1, AI-CHAIN.1 | Delegation tree, chain-of-custody proof |
4. Supply Chain and Development Risks
Five CoSAI risks target the training and development pipeline: data poisoning, unauthorized training data, model source tampering, excessive data handling, and federated training privacy leakage. These risks exist before a single inference runs.
Data Governance Witnessing
CoSAI controls addressed: Training Data Management, Training Data Sanitization, Privacy Enhancing Technologies
SWT3 witnesses: Data provenance hash, sanitization completion timestamp, authorization chain linking dataset to consent record. Every training run that touches production data mints an anchor proving which dataset was used, who authorized it, and when sanitization completed.
Query the ledger for AI-DATA.1 anchors filtered by date range. Each anchor's factor_a contains the dataset identifier and factor_b contains the authorization reference. Cross-reference with the organization's data governance policy to verify authorization was current at training time.
Model and Adapter Integrity
CoSAI controls addressed: Model and Data Integrity Management, Model and Data Execution Integrity, Secure-by-Default ML Tooling
SWT3 witnesses: Model weights SHA-256 hash at deployment, adapter stack fingerprint (LoRA, QLoRA, PEFT), AI-SBOM capturing all dependencies and their versions. These three procedures together address CoSAI's Model Source Tampering, Adapter/PEFT Injection, and Malicious Loader/Deserialization risks.
Present the AI-MDL.5 anchor from deployment alongside the current model hash. If they match, the model has not been tampered with since deployment. The AI-SBOM.1 anchor provides the dependency tree for loader verification.
5. Runtime and Inference Risks
Thirteen CoSAI risks target runtime operations: prompt injection, model evasion, sensitive data disclosure, insecure outputs, denial of service, economic denial of wallet, cache poisoning, covert channels, and more. These are the risks that materialize during live inference.
Guardrail Attestation (Input, Evaluation, Output)
CoSAI controls addressed: Input Validation and Sanitization, Output Validation and Sanitization, Adversarial Training and Testing
SWT3 witnesses: Three-stage guardrail evidence: AI-GRD.1 records that input validation ran before inference, AI-GRD.2 captures the guardrail evaluation result (pass/block/modify), and AI-GRD.3 proves output sanitization completed before delivery. Each anchor includes the guardrail version and configuration hash.
This directly addresses CoSAI's Prompt Injection, Model Evasion, Insecure Model Output, and Covert Channels risks. The guardrails block the threat. SWT3 proves they were active.
Filter the ledger for AI-GRD.* procedures over the audit period. Continuous coverage (no gaps in timestamps) demonstrates that guardrails were active for every inference, not just during testing.
Inference Provenance and Chain of Custody
CoSAI controls addressed: Orchestrator and Route Integrity, Inter-Component Transport Security
SWT3 witnesses: AI-INF.1 captures which model actually served the request (critical for multi-model routers where the serving model may differ from the requested model). AI-CHAIN.1 links inference anchors into an immutable chain proving the sequence of operations from request to response.
This addresses CoSAI's Orchestrator/Route Hijack risk. If a router silently swaps models, the AI-INF.1 anchor records what actually ran.
For orchestrator integrity verification, show AI-INF.1 anchors with model_id in factor_a. Compare against the deployment manifest. Any model_id not in the approved manifest is a finding.
Resource Consumption Witnessing
CoSAI controls addressed: Application Access and Resource Management, Agent Execution Bounds
SWT3 witnesses: AI-COST.1 records token consumption, compute cost, and resource utilization per inference. AI-PERF.1 captures latency and throughput metrics. Together they provide evidence for CoSAI's Denial of ML Service and Economic Denial of Wallet risks by proving that rate limits and cost controls were enforced.
Present AI-COST.1 trend data showing per-session and per-agent cost tracking. Spikes that were caught and throttled demonstrate active enforcement of CoSAI's access management controls.
6. Agentic and Orchestration Risks
CoSAI's most recent risk additions target autonomous agent systems: shadow agents, zombie MCP servers, delegation chain opacity, rogue actions, tool registry tampering, and cross-tenant credential propagation. These risks are unique to agentic AI and did not exist in traditional ML security frameworks.
Agent Identity and Delegation Trees
CoSAI controls addressed: Agent Inventory Management, Agent Integrity Management, Agent Permissions, Agent Credential Isolation, Component Identity Provenance
SWT3 witnesses: AI-ID.1 binds a unique, non-reusable identity to each agent instance at initialization. AI-DEL.1 records parent-child delegation trees when agents spawn sub-agents, preserving the full authority chain. Together they address five CoSAI controls and three risk categories (Shadow Agents, Stale Identity Binding, Delegation Chain Opacity).
This is the highest-value mapping in the crosswalk. CoSAI's Agent Observability control states that "an agent's actions, tool use, and reasoning are transparent and auditable." SWT3 makes that statement cryptographically verifiable.
Query AI-ID.1 anchors and cross-reference against the agent inventory. Any agent_id in the ledger without a matching inventory entry is a shadow agent. AI-DEL.1 anchors reconstruct the full delegation tree for any agent action under review.
Tool Call Witnessing and Access Scope
CoSAI controls addressed: Agent User Control, Agent Permissions, Agent Observability
SWT3 witnesses: AI-TOOL.1 captures every tool invocation with the tool name, input hash, output hash, and execution duration. AI-ACC.1 records the access scope that was active when the tool was called. Together they address CoSAI's Rogue Actions and Insecure Integrated Component risks by proving that agents only called authorized tools within their permitted scope.
Filter AI-TOOL.1 anchors by agent_id and compare tool names against the agent's declared tool manifest. Any tool call outside the manifest is a rogue action finding. AI-ACC.1 proves scope was enforced at call time.
RAG Provenance and Relevance
CoSAI controls addressed: Retrieval and Vector System Integrity Management
SWT3 witnesses: AI-RAG.1 records retrieval provenance (which documents were retrieved, from which vector store, with what similarity scores). AI-RAG.2 captures relevance evaluation results. Together they address CoSAI's Retrieval Vector Store Poisoning risk by creating an immutable record of what was retrieved and whether it passed relevance checks.
Present AI-RAG.1 anchors for a sample of inferences. The retrieval source identifiers in factor_a should match the organization's approved document corpus. Unknown sources indicate potential vector store compromise.
7. Integration Pattern
Adding SWT3 evidence to a CoSAI-aligned system requires three lines of code. The witness wraps existing inference calls without modifying business logic.
Python
from swt3_ai import Witness
witness = Witness(agent_id="cosai-aligned-agent-001")
response = witness.wrap(client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": prompt}]
))TypeScript
import { Witness } from '@tenova/swt3-ai';
const witness = new Witness({ agentId: 'cosai-aligned-agent-001' });
const response = await witness.wrap(client.chat.completions.create({
model: 'gpt-4o',
messages: [{ role: 'user', content: prompt }]
}));The witness captures model_id, token counts, latency, and clearing level factors automatically. For tool calls, guardrail evaluations, and delegation events, use the dedicated methods:
# Tool witnessing (AI-TOOL.1)
witness.wrap_tool("search_database", args={"query": q}, result=result)
# Guardrail witnessing (AI-GRD.1)
witness.witness_guardrail(guardrail_id="nemo-v1", verdict="pass", config_hash=cfg_hash)
# Delegation witnessing (AI-DEL.1)
witness.witness_delegation(parent_id="agent-001", child_id="sub-agent-002", scope="read-only")Full SDK docs: sovereign.tenova.io/docs | Free tier: sovereign.tenova.io/signup
8. Quick Reference for Examiners
| Examiner Question | Where to Look |
|---|---|
| How do you address CoSAI data poisoning risk? | AI-DATA.1 anchors with dataset ID and authorization reference |
| Can you prove guardrails were active during inference? | AI-GRD.1/2/3 anchors with continuous timestamps across audit period |
| How do you track agent identity and prevent shadow agents? | AI-ID.1 anchors cross-referenced against agent inventory |
| What evidence exists for model integrity? | AI-MDL.5 weight hash at deployment, AI-SBOM.1 dependency tree |
| How do you prevent delegation chain opacity? | AI-DEL.1 delegation trees showing parent-child authority chains |
| Can you demonstrate RAG retrieval provenance? | AI-RAG.1 anchors with source IDs and similarity scores |
| How do you address orchestrator route hijacking? | AI-INF.1 anchors recording actual model_id served per request |
| What is the cost control evidence? | AI-COST.1 consumption records with per-session cost tracking |
| Where is the independent verification? | sovereign.tenova.io/verify for any SWT3 anchor fingerprint |