Security and deployment boundary

Know what stays local, what is stored, and what remains yours to secure.

Perseus is a set of components, not one security slogan. Each component has a different data path. Optional transports and integrations change the boundary.

System data flow

The model stays outside Perseus authority.

Workspace sourcesPerseus Context EngineReads and renders an explicit artifact
Decisions and factsPerseus VaultStores governed memory selected by the host
Events and referencesPerseus LedgerRecords supplied evidence and chain state

Component matrix

Separate defaults from opt-ins.

ComponentReadsStoresDefault transportOperator responsibility
Perseus Context EngineAuthored workspace sourcesOnly the output/cache paths the operator enablesLocal CLI or MCP stdioDirective trust, output location, optional HTTP/shell/service modes
Perseus VaultMemories submitted by the hostEncrypted entity bodies; plaintext FTS5 index and metadataLocal MCP stdioKey file, filesystem ACLs, disk encryption, backup, optional HTTP/SSE auth
Perseus LedgerEvents and references submitted by integrationsSQLite-backed event chain and configured evidence fieldsLocal CLI/SDK; other transports are configured separatelySource validity, retention, transport security, reviewer and action authority

Verified posture

What the public source supports.

  • MIT-licensed source for all three components
  • Published SBOM materials
  • Local default paths with no mandatory Perseus cloud service
  • Security policies and vulnerability-reporting path
  • Release checksums and provenance material where published

Not claimed

What this does not establish.

  • No facility clearance or classified-data authority
  • No ATO, cATO, cross-domain approval, or safety certification
  • No independent CMMC certification
  • No autonomous authority over a model or mission system
  • No Government approval created by MIT licensing, SBOMs, or JCP status