Threat Model

The canonical threat model is THREAT_MODEL.md. This page summarizes the boundaries operators need when configuring a Comis deployment. Comis treats the model as potentially steered by untrusted content. Inbound messages, fetched pages, email, transcripts, MCP output, and tool results can contain prompt injection. Controls therefore constrain what an agent can do after authentication rather than trusting model intent.

Trust boundaries

Principal	Treatment
Operator and host OS	Trusted; host compromise is out of scope
Gateway clients	Authenticated by scoped token and optionally mTLS
Model and agent output	Semi-trusted; subject to policy and completed-response scanning
External content	Untrusted; wrapped as data on guarded ingestion paths
Exec child process	OS-confined only when a supported sandbox provider is active
MCP stdio server	Third-party process outside the exec sandbox
Other agents	Logically scoped inside the shared trusted daemon/host
Providers and chat platforms	External recipients selected by the operator

Default posture

encrypted credential storage, with the master key in ~/.comis/.env;
loopback gateway bind;
log redaction and security audit events enabled;
approval workflow disabled;
full tool-policy profile;
unrestricted per-agent secret resolution when agents.<id>.secrets.allow is omitted or empty;
prompt-skill permissions and allowedTools declarations treated as metadata, not an enforced per-skill authorization boundary;
exec sandbox requested, with an unsandboxed fallback for ordinary exec when no provider is available;
Node permission model disabled.

Primary controls and limits

Threat	Controls	Limit
Prompt injection to tool abuse	content wrapping, capability gates, tool policy, action classification, optional approvals	default tools are broad and approvals are opt-in
Credential leakage	encrypted store, scoped secret access, redaction, memory/output guards, optional broker	host access to both database and master key defeats at-rest encryption; an empty agent secret allowlist is unrestricted
Unauthorized gateway access	loopback bind, scoped bearer tokens, optional mTLS	publicly exposed bearer traffic requires TLS
SSRF and path escape	guarded URL validation and safe-path checks	unsandboxed shell and separately implemented integrations have different boundaries
Memory poisoning	write validation and trust-ranked recall	validation is heuristic, not truth verification
MCP compromise	filtering, result sanitization, circuit breakers, advisory checks	stdio servers run with the daemon account outside the exec sandbox
Secret leakage in output	completed-response output guard	live streaming deltas can be emitted before the final scan

Process isolation

Linux with working Bubblewrap is the supported production boundary. macOS sandbox-exec is best effort and deprecated. Docker Desktop on macOS or Windows is not equivalent to a Linux host. The exec sandbox covers the exec tool, not every tool, browser process, or MCP server. Its default network mode is open; broker-only isolation is used only by specific driven workflows.

Approvals

Unknown actions default to the destructive classification, but classification does not itself pause execution. Human confirmation runs only when approvals.enabled: true and the specific execution path explicitly calls the approval gate. The schema accepts rule and default-mode fields, but they are not a universal action-policy evaluator.

Streaming

The output guard can sanitize a completed response. Streaming HTTP/SSE deltas may already have reached the client before that scan, so the final guard cannot retract them. Disable streaming or add buffering when this disclosure window is unacceptable.

Skill manifest boundary

Comis sanitizes and pattern-scans Markdown prompt-skill bodies at load time by default. That is a heuristic content control, not code isolation. SKILL.md permissions and allowedTools fields are currently descriptive metadata; they do not replace agent tool policy, capability gates, tool-specific validation, or an active exec sandbox. MCP stdio servers and browser processes remain outside the ordinary exec sandbox.

Out of scope

malicious operators, root access, or a compromised host;
data intentionally sent to configured external providers and platforms;
perfect prompt-injection detection or model correctness;
Linux-equivalent process isolation on unsupported hosts;
compromise of Node.js, the OS, container runtime, or hardware.

Deployment checklist

Use Linux and verify Bubblewrap at startup.
Narrow the default full tool profile.
Configure a non-empty agents.<id>.secrets.allow list for every agent that does not need unrestricted credential access.
Enable and test approvals if your policy requires human confirmation.
Protect network exposure with scoped authentication and TLS.
Back up the master key separately and restrict the daemon account.
Review each prompt skill and MCP server as untrusted third-party content or process code.
Disable streaming on confidentiality-sensitive surfaces.

See Security, Hardening, Approvals, and Exec Sandbox.

​Trust boundaries

​Default posture

​Primary controls and limits

​Process isolation

​Approvals

​Streaming

​Skill manifest boundary

​Out of scope

​Deployment checklist