Skip to main content
Comis treats model output and external content as potentially hostile. Its security model combines validation, least-privilege controls, audit signals, credential handling, and optional operating-system isolation. No single layer makes an autonomous agent safe in every deployment.
You don’t need to understand the technical details to use this feature. The configuration examples below are copy-paste ready.

​
Defaults to understand

Before connecting untrusted users, replace the default full tool profile, enable and test approvals if you rely on human confirmation, and verify the actual sandbox provider in daemon logs. Configuration intent is not proof that the host enforced the boundary.

​
Protections that apply broadly

  • external content is delimited and treated as data before prompt assembly;
  • URL validation blocks known private, loopback, link-local, and metadata targets on guarded fetch paths;
  • memory writes are scanned and may be blocked or stored at reduced trust;
  • completed agent responses are scanned for secret-shaped content and canary leakage;
  • logs use structured redaction and security decisions emit audit events;
  • gateway tokens are scoped, and the gateway binds to loopback by default;
  • unknown action classifications fail closed to the destructive class;
  • paths handled through Comis file tools are constrained by safe-path checks.
These controls reduce risk; they do not prove that model output is correct or that all external content is harmless.

​
Important boundaries

​
Learned state crosses sessions

Cross-session guidance is persistent model input, so it is part of the security boundary:
  • candidate guidance may surface before active promotion and influence which already-authorized tool the model requests;
  • the default single_owner corroboration mode uses repeated qualifying observations from one explicitly trusted owner, not independent sources;
  • static validation blocks selected critical patterns, but warning-level harmful or jailbreak-like language can pass;
  • recall is scoped to the tenant and agent, not to an individual sender or end user;
  • recording a correction does not guarantee immediate demotion, retirement, or a durable behavior change; and
  • learned documents are advisory Markdown with no direct script or dynamic replay path. They cannot by themselves execute a command or grant a capability, credential, lease, approval, or larger budget.
Learned guidance can still persuade the model to request an action that is within its configured reach. Use separate tenants or agents for per-user confidentiality, review the learning policy, and keep runtime authority narrow.

​
Approvals are opt-in

security.actionConfirmation classifies actions, but the human approval workflow is disabled by default. Enable approvals.enabled and add rules before claiming that destructive actions require operator confirmation. Test the approval path from the same channel and tool surface you plan to use.

​
Tool access starts broad

The default tool-policy profile is full. Use minimal, coding, messaging, or another appropriate profile, then apply explicit allow and deny rules. Tool policy is one control; it does not sandbox code by itself.

​
Shell isolation depends on the host

The exec sandbox applies to shell commands launched through the exec tool. It does not wrap every in-process tool, browser process, or MCP server.
  • Linux with working Bubblewrap provides the strongest supported isolation.
  • macOS sandbox-exec is deprecated and treated as best effort.
  • Docker Desktop on macOS or Windows does not provide the documented Linux production boundary.
  • when the configured sandbox provider is unavailable, ordinary exec currently runs with the command validator but without OS-level isolation.
Use Linux for production, install Bubblewrap, and verify the provider at boot.

​
MCP has a separate trust boundary

MCP stdio servers are separate processes and are not wrapped by the exec sandbox. Comis applies manifest/tool filtering, eligibility checks, result sanitization, and configured tool policy, but operators must still trust and review each server, its executable, permissions, and network access.

​
Streaming can precede the final scan

The output guard scans the completed response. Non-streaming delivery receives that sanitized result. Streaming HTTP/SSE token deltas may already have been emitted before the final response scan completes, so do not treat the final guard as a confidentiality boundary for live streaming. Disable streaming on sensitive surfaces or add a buffering/filtering layer before exposing them.

​
Encryption does not defeat host compromise

The encrypted store protects a copied secrets.db when the attacker does not also have the master key. A process or operator that can read both secrets.db and ~/.comis/.env can decrypt the credentials. Losing the master key makes the database unreadable because Comis has no recovery service.

​
Baseline hardening

  1. Keep the gateway on loopback, or put it behind authentication and TLS.
  2. Back up ~/.comis/.env separately from secrets.db and restrict both to the daemon account.
  3. Replace the full tool policy with the narrowest practical profile.
  4. Enable approval rules if your operating model depends on human review.
  5. Verify Bubblewrap on a Linux host; do not assume an unavailable provider fails closed for ordinary exec.
  6. Review every MCP server as third-party code with its own process privileges.
  7. Disable live streaming where pre-scan token disclosure is unacceptable.
  8. Run comis security audit, comis secrets audit --check, and comis doctor.
  9. Review learning corroboration and recall scope, and isolate users who must not share learned guidance.

​
Read the complete model

Threat Model

Trust boundaries, defended threats, and residual risks.

Hardening

Deployment controls and verification steps.

Approvals

Enable and test human-in-the-loop decisions.

Secrets

Storage modes, backup obligations, and credential scope.