Trust & Security

Intelligence built with trust at its foundation.

An intelligence platform is only as useful as it is trustworthy. Security, privacy, compliance and governance shape how CIP stores, retrieves, remembers and reasons, in every layer and every deployment model.

Engineering philosophy

Four rules the platform does not bend.

These are design decisions in the codebase, not policies on a page.

Authorization lives in the data layer
Organizations, workspaces and projects are enforced in the database, storage and search filters. The model only ever sees results already trimmed to what the user may open. Prompts are never the control.
No standing secrets
Services authenticate with managed identities. Shared keys and local authentication are disabled on the data services, and the database accepts identity tokens only.
Originals are the record
Source documents, transcripts and decisions are kept with their provenance. Indexes and embeddings are derived, rebuildable, and never mistaken for the source.
People stay accountable
CIP cites, suggests and remembers. People decide. Anything that would act on their behalf is designed around approvals and oversight, and is on the roadmap, not live.

Practices

What CIP does today, and what is still ahead.

Every practice carries the same maturity labels as the rest of the platform.

Available in pilot: Working in the Cirrusage-operated CIP environment today, shown in guided walkthroughs and available to design-partner pilots. Not generally available.
In development: Partly built, or built and not yet validated end to end. Being actively engineered.
Architectural roadmap: Part of the platform architecture we are designing toward. Not built yet.

Enterprise Security

Identity, access, encryption and secrets designed so that a breach of one control does not expose everything behind it.

Sign-in with Microsoft Entra ID; tokens validated for signature, issuer, audience and scopePilot (Available in pilot)
Only users assigned to the application can obtain accessPilot (Available in pilot)
Services authenticate with managed identities: no API keys or shared keysPilot (Available in pilot)
Encryption in transit everywhere and at rest in every data storePilot (Available in pilot)
Short-lived, single-object access links for file uploads and previewsPilot (Available in pilot)
Private network endpoints for every serviceRoadmap (Architectural roadmap)
Customer-managed encryption keysRoadmap (Architectural roadmap)

Privacy & Data Control

Your data stays your data: processed inside defined boundaries, kept no longer than it should be, and deletable when it must be.

Customer data is never used to train shared modelsPilot (Available in pilot)
Model requests are sent with response storage disabledPilot (Available in pilot)
Logs record identifiers, counts and timings, never document text, prompts or answersPilot (Available in pilot)
Deleting a document removes its records, files and search entriesPilot (Available in pilot)
Optional web search is off by default and labelled as leaving the platform boundaryPilot (Available in pilot)
Memory erasure and retention holdsIn development (In development)
Configurable retention policies per organizationRoadmap (Architectural roadmap)

AI Governance

Models operate inside the platform's rules, not the other way round. People stay accountable for decisions.

The model only ever receives content the user is already authorized to seePilot (Available in pilot)
Answers cite their sources, and retrieval is shown only when it actually happenedPilot (Available in pilot)
Live meeting assistance requires a recorded consent confirmation and never speaks into the meetingPilot (Available in pilot)
Retrieval quality measured with a repeatable evaluation benchmarkIn development (In development)
Model approval policies per organizationRoadmap (Architectural roadmap)
Agent actions with policy limits, approvals and human oversightRoadmap (Architectural roadmap)

Knowledge Governance

Institutional memory is only useful if you can trust it: where it came from, who can see it, and whether it is still true.

Originals are kept apart from AI-derived knowledge, each versioned independentlyPilot (Available in pilot)
Every memory item has a scope, an access policy, a lifecycle state and provenancePilot (Available in pilot)
Superseded knowledge is retained as history, never silently overwrittenPilot (Available in pilot)
Disputed items are flagged for review rather than usedPilot (Available in pilot)
Personal context and organizational knowledge are kept separate by designPilot (Available in pilot)
Lineage from every derived insight back to its sourcesIn development (In development)

Compliance readiness

Architecture that can support your controls. Not a certificate.

CIP is designed so that regulatory and contractual controls can be implemented and evidenced: isolation, provenance, audit history, retention and erasure, data minimization in logs, and customer-controlled deployment boundaries. Whether a deployment meets a specific obligation depends on implementation, configuration, independent assessment and your own requirements.

During an evaluation we walk your security and compliance teams through the architecture, data flows and controls as they exist, and name the gaps plainly.

What we do not claim

Cirrusage and CIP do not currently hold, and we do not claim:

SOC 2, ISO 27001 or any other certification or attestation
HIPAA, GDPR, GxP or other regulatory compliance status
FedRAMP or other government authorization
Penetration test or third-party security audit results
Uptime guarantees or service-level agreements

When that changes, this page will say so, with the scope and date.

Deployment responsibility

Who operates which controls.

In a Cirrusage-hosted deployment we would operate most of the stack. In your cloud or data center, many of the controls that matter most are yours. The split is explicit.

Who is responsible for each area in each CIP deployment model
Responsibility	Cirrusage-hosted	Customer-managed cloud	Private / on-premises
Physical infrastructure and hosting	Cirrusage	Customer	Customer
Network boundaries and connectivity	Cirrusage	Customer	Customer
Identity provider and user lifecycle	Customer	Customer	Customer
Access policy inside CIP (workspaces, roles)	Customer	Customer	Customer
Data storage, encryption keys and backups	Cirrusage	Customer	Customer
Approved model endpoints	Cirrusage	Customer	Customer
Application releases and security fixes	Cirrusage	Shared	Shared
Platform monitoring and incident response	Cirrusage	Shared	Customer
Regulatory and contractual compliance	Shared	Shared	Shared

Cirrusage-hosted

Physical infrastructure and hosting: Cirrusage
Network boundaries and connectivity: Cirrusage
Identity provider and user lifecycle: Customer
Access policy inside CIP (workspaces, roles): Customer
Data storage, encryption keys and backups: Cirrusage
Approved model endpoints: Cirrusage
Application releases and security fixes: Cirrusage
Platform monitoring and incident response: Cirrusage
Regulatory and contractual compliance: Shared

Customer-managed cloud

Physical infrastructure and hosting: Customer
Network boundaries and connectivity: Customer
Identity provider and user lifecycle: Customer
Access policy inside CIP (workspaces, roles): Customer
Data storage, encryption keys and backups: Customer
Approved model endpoints: Customer
Application releases and security fixes: Shared
Platform monitoring and incident response: Shared
Regulatory and contractual compliance: Shared

Private / on-premises

Physical infrastructure and hosting: Customer
Network boundaries and connectivity: Customer
Identity provider and user lifecycle: Customer
Access policy inside CIP (workspaces, roles): Customer
Data storage, encryption keys and backups: Customer
Approved model endpoints: Customer
Application releases and security fixes: Shared
Platform monitoring and incident response: Customer
Regulatory and contractual compliance: Shared

“Shared” means the split is agreed per engagement. Regulatory and contractual compliance always depends on how the platform is configured and operated in your environment, and on your own assessment.

Compare deployment models →

Put CIP in front of your security team.

We would rather answer hard questions early. Bring your security questionnaire, architecture review, or data-protection requirements.

Request a security walkthroughView the architecture