> ## 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.

# Threat Model

> Trust boundaries, defended threats, and residual risks

The canonical threat model is
[`THREAT_MODEL.md`](https://github.com/comisai/comis/blob/main/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

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

See [Security](/security/index), [Hardening](/security/hardening),
[Approvals](/security/approvals), and [Exec Sandbox](/security/exec-sandbox).