Security | Apus Ami

Apus ships with conservative defaults. On a regular host install the Gateway binds to loopback; most chat channels answer an unknown DM sender with a pairing code instead of processing the message; and group access is allowlisted, usually behind a mention gate. The exceptions are deliberate and documented: container images default to an exposed bind (pair that with auth - see the exposure runbook), and a few workspace channels such as ClickClack trust workspace membership by default - each channel page states its exact defaults. Run on those defaults and you are in good shape, and one command tells you if you have drifted:

apus security audit

The pages below are the deep end: the trust model, what the audit checks, and how to harden further as you expose more surface.

One trust boundary per gateway. This guidance assumes one trusted boundary per gateway: a single operator, or a team whose members trust each other. Group chats and multi-user operation are supported deployments inside that boundary. Apus is not a hostile multi-tenant security boundary for mutually adversarial users sharing one agent or gateway. For mixed-trust or adversarial-user operation, split trust boundaries: separate gateway + credentials, ideally separate OS users or hosts.

Agents with message-tool access can send across conversations and channel providers by default. If your deployment needs messaging confined to the current provider or conversation, configure cross-provider messaging restrictions.

Security pages

Understand the model:

Security trust model - One trust boundary per gateway, the boundary matrix, and the findings closed as no-action.
Running the security audit - What apus security audit checks and the order to fix findings in.
Security audit checks - Reference catalog of every checkId, its severity, and its auto-fix support.
Threat model - Adversarial threats to the Apus platform and ClawHub, mapped to MITRE ATLAS.

Harden a deployment:

Hardened baselines - Copy/paste configs that keep the Gateway local, paired, and tool-restricted.
Access control and allowlists - DM policy, allowlists, DM session isolation, context visibility, command authorization.
Prompt injection - Untrusted content reaching the model, model choice, and the wrapping that bounds it.
Tool and agent permissions - Control-plane tools, node execution, plugins, sandboxing, per-agent profiles.
Browser control risks - What a real browser exposes, and the SSRF policy that bounds it.
Network exposure - Bind, firewall, discovery, Gateway auth, Tailscale, reverse proxy, dangerous flags.
Secrets, storage, and logs - What lands on disk, which files hold credentials, and what transcripts contain.
Secure file operations - Root-bounded file access, atomic writes, and archive extraction helpers.
Dependency locking - How published packages pin and resolve their dependency graph.

Expose and operate:

Gateway exposure runbook - Pre-flight and rollback checklist before exposing the Gateway beyond loopback.
Trusted proxy auth - Running the Gateway behind a reverse proxy that supplies the operator identity.
Rate limiting - Every Gateway rate limit: lockouts, throttles, caps, and cooldowns.
Operator incident response - Contain, rotate, audit, and collect evidence after a suspected compromise.

Run it from the CLI:

apus security - Run the audit, read findings, and apply the supported auto-fixes.
apus policy - Inspect and test the tool policy the guidance above configures.

Where each section moved

Every anchor this page used to publish still resolves here. Each entry below carries the original anchor and links to its new home.

Security trust model

Running the security audit

Hardened baselines

Access control and allowlists

Prompt injection

Tool and agent permissions

Browser control risks

Network exposure

Secrets, storage, and logs

Operator incident response