Cohere earned FedRAMP High. SOC 2 Type II. ISO 27001. Those certifications prove the platform is secure. They say nothing about how your application uses it. SWT3 completes the chain.
v0.7.8 PREVIEW – Cohere adapter ships with v0.7.8. Streaming, system prompt drift detection, and RAG witnessing. Available on PyPI and npm at release.
Who this is for: Enterprise teams deploying Cohere Command R/Command A in regulated industries (finance, healthcare, government), compliance officers building evidence for SOC 2 / FedRAMP / HIPAA audits, RAG pipeline engineers who need retrieval provenance, and federal agencies using Cohere through Second Front's FedRAMP authorization.
The certification boundary problem. Cohere's SOC 2 Type II covers their platform: data handling, access controls, encryption at rest, key management. Your SOC 2 covers your application: how you call the model, what decisions it informs, how you log those decisions. When your auditor asks "show me the AI governance controls," Cohere's certificate proves the platform is trustworthy. It does not prove your use of the platform is governed.
Compliance certifications have scope boundaries. Cohere's certifications cover what Cohere operates. Your certifications cover what you operate. The AI inference happens at the boundary between the two.
| Layer | Responsible Party | Certifications | What It Covers |
|---|---|---|---|
| Model Platform | Cohere | FedRAMP High, SOC 2 II, ISO 27001, HIPAA BAA | Infrastructure, data handling, model training, API availability |
| Inference Decision | Gap | Neither party covers this | What the model decided, on what input, producing what output |
| Application | You | Your SOC 2, HIPAA, FedRAMP | Business logic, access controls, data governance, logging |
The inference decision sits in the gap. Cohere's platform processed it securely. Your application consumed the result. But neither party's certification explicitly attests to the decision itself: what went in, what came out, which model version generated it, and whether the response was complete or refused.
SWT3 fills this gap. Every inference call produces a witness anchor that captures the decision fingerprint. The anchor lives in your compliance boundary, governed by your policies, but it references the exact model and response from Cohere's platform. It is the bridge artifact that connects both certification scopes.
FedRAMP High authorization. Achieved in May 2026 through Second Front Systems. This is the highest FedRAMP impact level, enabling deployment in federal agencies handling classified and controlled unclassified information. Very few AI model providers have this.
SOC 2 Type II. Independently audited controls for security, availability, and confidentiality. Type II means the controls were tested over a period, not just documented at a point in time.
ISO 27001. Information security management system certification. Covers Cohere's organizational security practices.
HIPAA Business Associate Agreement. Available for healthcare deployments, covering the handling of protected health information (PHI) within Cohere's platform.
PwC alliance. Global alliance with PwC for security, compliance, and data sovereignty in regulated industries. This signals that the Big 4 consider Cohere audit-ready.
Cohere deliberately built for regulated markets. Their certification stack is not cosmetic -- FedRAMP High is the hardest authorization to achieve. But these certifications protect the data at rest and in transit through Cohere's infrastructure. They do not generate evidence about the AI decisions your application makes. That evidence is what SWT3 produces.
Consider what happens during a typical Cohere inference call in your application:
client.chat()Now an auditor asks: "On September 12th, what model version generated the response that informed this loan decision?"
Cohere's API logs (if you have access to them) show that a call was made. Your application logs (if you built logging) show what your app did with the result. But the decision itself -- the mapping from this specific prompt to this specific response by this specific model version -- is not captured by either party's standard logging.
SWT3 captures exactly this. A cryptographic fingerprint of the prompt, the response, the model version, and the timestamp. Independently verifiable. Stored in your infrastructure. Survives regardless of what happens to either Cohere's or your application's logs.
import cohere
from swt3_ai import Witness
from swt3_ai.adapters.cohere import wrap_cohere
witness = Witness(
endpoint="https://your-instance.example.com/api/v1/witness",
api_key="axm_your_key",
tenant_id="YOUR_TENANT",
)
client = cohere.ClientV2(api_key="your-cohere-key")
witnessed = wrap_cohere(client, witness)
# Identical usage -- your code does not change
response = witnessed.chat(
model="command-r-plus",
messages=[
{"role": "system", "content": "You are a medical coding assistant."},
{"role": "user", "content": "Assign ICD-10 codes to this clinical note."},
],
)
# response is untouched
print(response.message.content[0].text)
witness.flush()
import { CohereClientV2 } from 'cohere-ai';
import { Witness, wrapCohere } from '@tenova/swt3-ai';
const witness = new Witness({
endpoint: 'https://your-instance.example.com/api/v1/witness',
apiKey: 'axm_your_key',
tenantId: 'YOUR_TENANT',
});
const client = new CohereClientV2({ token: 'your-cohere-key' });
const witnessed = wrapCohere(client, witness);
const response = await witnessed.chat({
model: 'command-r-plus',
messages: [
{ role: 'system', content: 'You are a medical coding assistant.' },
{ role: 'user', content: 'Assign ICD-10 codes to this clinical note.' },
],
});
await witness.flush();
System prompt drift detection included. The adapter separately hashes your system prompt. If someone modifies the system prompt in production (accidentally or maliciously), the system_prompt_hash in subsequent anchors will differ from your baseline. Instruction integrity monitoring, built into the adapter, zero configuration.
Each chat() call produces an anchor with: resolved model ID, prompt hash, response hash, system prompt hash, token counts, and latency.
Query anchors for provider="cohere" and verify model_id against the organization's approved model list. Cohere rotates model versions (e.g., command-r-plus-08-2024 to command-r-plus-04-2025) -- each rotation should appear as a clean model_hash transition in the ledger. If has_refusal=true appears frequently, investigate whether Cohere's safety filters are blocking legitimate business queries (a model suitability finding, not a compliance failure).
Cohere's chat_stream() returns a sequence of typed events: message-start, content-delta, message-end. The SWT3 adapter accumulates text from content deltas and extracts token usage from the message-end event, then mints a single anchor when the stream completes.
# Python streaming
stream = witnessed.chat_stream(
model="command-r-plus",
messages=[{"role": "user", "content": "Summarize this document"}],
)
for event in stream:
if event.type == "content-delta":
text = event.delta.message.content.text
print(text, end="", flush=True)
# Anchor minted automatically on stream completion
Your streaming experience is identical. The adapter sits between the stream and your code, observing events without modifying them. The witness anchor captures the complete response hash, actual model ID, and total token counts.
Cohere is widely deployed in RAG architectures. Command R was designed for grounded generation with citations. When you combine Cohere inference with a retrieval layer, you can witness both independently:
from swt3_ai import Witness
from swt3_ai.adapters.cohere import wrap_cohere
witness = Witness(
endpoint="https://your-instance.example.com/api/v1/witness",
api_key="axm_your_key",
tenant_id="YOUR_TENANT",
)
# Witness the retrieval context (AI-RAG.1)
witness.witness_rag_context(
chunks=[
{"source": "policy_v3.pdf", "text": "Section 4.2: Coverage limits..."},
{"source": "amendment_2026.pdf", "text": "Effective date: March 1..."},
],
query="What are the coverage limits?",
retriever="qdrant-v1.12",
)
# Witness the Cohere inference (AI-INF.1)
client = cohere.ClientV2(api_key="your-key")
witnessed = wrap_cohere(client, witness)
response = witnessed.chat(
model="command-r-plus",
messages=[
{"role": "system", "content": "Answer using only the provided context."},
{"role": "user", "content": context + "\n\nQuestion: " + query},
],
)
# Two anchors: retrieval provenance + generation evidence
witness.flush()
RAG witnessing answers the hardest audit question. When a model cites a source, how do you prove it actually had access to that source at inference time? The RAG witness anchor fingerprints the exact chunks that were retrieved, when they were retrieved, and from which retriever. Combined with the inference anchor, you have a complete provenance chain: these documents were retrieved, this model consumed them, this response was generated.
For RAG deployments, each user query should produce two anchors: one for AI-RAG.1 (retrieval) and one for AI-INF.1 (generation). Query the ledger for the same agent_id within a 5-second window and verify both anchors exist. If only the inference anchor exists, the retrieval step is unwitnessed -- the organization cannot prove which documents informed the model's response. This is a critical gap for healthcare (HIPAA audit trail), finance (SR 11-7 model input documentation), and any deployment where the source of truth matters.
| Framework | Requirement | Cohere's Certificate | SWT3 Anchor |
|---|---|---|---|
| SOC 2 CC7.2 | Monitor system components | Platform monitoring | AI decision monitoring in your app |
| SOC 2 CC6.1 | Logical access controls | API key management | Per-inference identity binding |
| FedRAMP AU-2 | Auditable events | API access logs | Decision-level audit events |
| HIPAA 164.312(b) | Audit controls | BAA covers data handling | PHI inference decision trail |
| SR 11-7 / SR 26-2 | Model performance monitoring | Not applicable (not a bank) | Latency, refusal, drift tracking |
| EU AI Act Art. 12 | Automatic operation logging | Provider logging (Art. 53) | Deployer logging per inference |
| NIST AI RMF MN 2.2 | Track deployed AI behavior | Platform metrics | Per-decision behavior fingerprint |
Cohere's certifications prove the platform handles your data securely. Your application's controls prove you implement proper access, logging, and business logic. SWT3 anchors prove the AI decisions between those two layers were made by the right model, on the right input, producing the right output, at the right time.
No single artifact covers all three layers. Together, they form a compliance chain that an auditor can follow from infrastructure to decision to business outcome.
When the auditor asks about AI governance, you present three artifacts: (1) Cohere's SOC 2 Type II report covering the platform, (2) your SWT3 witness anchors covering inference decisions, and (3) your application's access controls covering business logic. Each artifact is independently verifiable. Together, they eliminate the gap that exists when you only have Cohere's certificate and your application logs.
For HIPAA-covered entities using Cohere with a BAA: verify that every inference involving PHI produces a witness anchor. Request a cross-reference between the application's PHI access log and the SWT3 ledger for the same time period. Each PHI access event should have a corresponding anchor. Anchors without PHI access events may indicate shadow usage (inference calls outside the governed application). PHI access events without anchors mean the witness pipeline has gaps -- a 164.312(b) audit control deficiency.
# Python
pip install swt3-ai cohere
# TypeScript
npm install @tenova/swt3-ai cohere-ai
import cohere
from swt3_ai import Witness
from swt3_ai.adapters.cohere import wrap_cohere
witness = Witness(
endpoint="https://your-instance.example.com/api/v1/witness",
api_key="axm_your_key",
tenant_id="YOUR_TENANT",
)
client = cohere.ClientV2(api_key="your-key")
witnessed = wrap_cohere(client, witness) # Bridge the gap
# Every inference now produces a cryptographic witness anchor
response = witnessed.chat(
model="command-a",
messages=[{"role": "user", "content": "Classify this transaction"}],
)
witness.flush()