> ## 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
> 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
```bash theme={}
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
Assets, trust boundaries, defended threats, and out-of-scope risks.
How the individual controls compose.
Credential storage, scoping, backup, and rotation.
Enable and configure the opt-in approval workflow.
Replace the default unrestricted tool profile.
Platform support, fallback behavior, and limitations.
Review recorded security-decision events.
Prepare a Linux deployment for untrusted input.