> ## Documentation Index
> Fetch the complete documentation index at: https://comis-fix-skill-import-vetting-gate.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Security Boundaries
> What Comis protects, what requires configuration, and what remains your responsibility
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
| Control | Default | What that means |
| ------------------------------ | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Credential storage | `encrypted` | Credentials are stored in `secrets.db`; the master key is in `~/.comis/.env` and must be backed up separately. |
| Gateway bind | Loopback | The daemon listens on `127.0.0.1` unless you explicitly expose it. |
| Log redaction and audit events | Enabled | Security-relevant decisions are recorded without intentionally storing secret values or message bodies. This is not a record of every agent action. |
| Approval workflow | **Disabled** | Destructive classification alone does not create a human approval step. Set `approvals.enabled: true` and configure rules. |
| Tool-policy profile | `full` | Agents receive the broadest available tool set unless you choose a narrower profile or deny tools. |
| Exec sandbox | Requested (`always`) | Linux uses Bubblewrap when available; macOS uses best-effort `sandbox-exec`. If no provider is available, ordinary `exec` currently falls back to unsandboxed execution. |
| Node permission model | Disabled | Enable and test it explicitly for a hardened Linux deployment. |
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
Trust boundaries, defended threats, and residual risks.
Deployment controls and verification steps.
Enable and test human-in-the-loop decisions.
Storage modes, backup obligations, and credential scope.