Security

Security controls, deployment boundaries, and operator responsibilities

Comis assumes that external content can contain prompt injection and that a model can request unsafe actions. The runtime therefore layers content guards, capability checks, tool policy, credential handling, audit events, and platform-dependent process isolation.

Security depends on deployment choices. The default configuration is suitable for local evaluation, not an assurance that every high-impact action is human-approved or every tool process is kernel-confined.

Current default posture

Area	Default posture	Operator action
Secrets	Encrypted store; master key in ~/.comis/.env	Back up and protect the key separately
Gateway	Loopback bind	Add authentication and TLS before network exposure
Approvals	Disabled; only explicitly wired paths can request approval	Enable and test every guarded path that requires confirmation
Tool policy	full profile	Select a narrower profile and explicit denies
Exec isolation	Enabled when a provider is available	Use Linux + Bubblewrap and verify startup logs
MCP stdio	Outside the exec sandbox	Review each server as third-party process code
Node permissions	Disabled	Enable only after testing required paths and hosts
Output guard	Completed-response scan	Do not rely on it to retract previously emitted streaming deltas

Ordinary exec currently falls back to unsandboxed execution when the sandbox provider is unavailable. macOS isolation is best effort, and Docker Desktop is not the Linux production boundary. Treat the daemon host and operator account as trusted.

Control layers

• Input and external-content handling: validates inbound data and wraps untrusted text before prompt assembly.
• URL and path controls: guarded fetch paths reject known local/private targets; file tools use traversal- and symlink-aware path checks.
• Tool authorization: profiles and allow/deny lists determine which tools are available. The default profile is intentionally broad.
• Action classification: read, mutate, and destructive labels support policy and auditing. The human approval workflow is a separate opt-in layer.
• Credential handling: encrypted storage, scoped resolution, redaction, and optional broker injection reduce plaintext exposure.
• Learned-state controls: source trust, provenance, configured corroboration, usefulness, and correction history shape what can return in a later session.
• Output and memory guards: completed responses and new memory writes are scanned for secret-shaped or suspicious content.
• Audit and diagnostics: content-free security-decision events and operator checks help reconstruct and verify the active posture.
• OS isolation: Bubblewrap or sandbox-exec confines supported exec paths; scope and availability are documented rather than assumed.

Learned state is a security boundary

Cross-session guidance is persistent model input. Candidate guidance may surface before active promotion and influence which already-authorized tool the model requests.

The default single_owner corroboration mode accepts repeated qualifying observations from one explicitly trusted owner. It is not independent-source corroboration. Static validation blocks selected critical patterns, but warning-level harmful or jailbreak-like language can pass and remain persuasive.

Recall is scoped to the tenant and agent, not to an individual sender or end user. Use separate tenants, agents, or another isolation layer when users must not share learned guidance. Recording a correction feeds the correction and demotion process, but does not guarantee immediate demotion, retirement, or a durable behavior change.

Learned documents are advisory Markdown with no direct script or dynamic replay path. Learned text cannot by itself execute a command or grant a capability, credential, lease, approval, or larger budget. It can still steer the model toward actions already within its configured reach, so tool policy, capability checks, origin checks, credential scope, approvals on supported paths, budgets, leases, and host isolation remain authoritative.

Verify a deployment

comis doctor
comis security audit
comis secrets audit --check
comis daemon logs

Confirm the gateway bind, token/TLS settings, credential storage mode, approval configuration, effective tool policy, and reported sandbox provider. Repeat verification after host, container, or configuration changes.

Security documentation

Threat Model

Assets, trust boundaries, defended threats, and out-of-scope risks.

Defense in Depth

How the individual controls compose.

Secrets

Credential storage, scoping, backup, and rotation.

Approvals

Enable and configure the opt-in approval workflow.

Tool Policy

Replace the default unrestricted tool profile.

Exec Sandbox

Platform support, fallback behavior, and limitations.

Audit

Review recorded security-decision events.

Hardening

Prepare a Linux deployment for untrusted input.