Security trust model

Scope: one trust boundary per gateway

Supported: one trust boundary per gateway - a single operator or a mutually trusting team (prefer one OS user/host/VPS per boundary).
Not supported: one shared gateway/agent used by mutually untrusted or adversarial users.
Adversarial-user isolation needs separate gateways (and ideally separate OS users/hosts).
Everyone who can message a tool-enabled agent shares that agent's delegated tool authority. That is fine for teammates who already trust each other; it is why adversarial users cannot share an agent.
Session tools reach across the whole Gateway by default: tools.sessions.visibility defaults to all and tools.agentToAgent.enabled defaults to true, so any tool-enabled agent running unsandboxed can list, read, search, and message every agent's sessions, including other users' transcripts. Sandboxed sessions stay clamped to their own spawn tree by default, which limits them as callers but does not hide their transcripts from unsandboxed agents. That matches one trust boundary per Gateway. For personas with different trust levels on one Gateway, set tools.sessions.visibility to agent or self (tree still admits requester-owned native and ACP children across agents), restrict pairs with tools.agentToAgent.allow, or set tools.agentToAgent.enabled: false. See tools.sessions and tools.agentToAgent.
For send-only delegation, pair narrow visibility with agents.entries.<agentId>.tools.agentToAgent.send (target IDs or * patterns). The rule permits sessions_send and the authorized turn's reply, not history, search, list, status, session controls, or otherwise hidden state watches. Global agent-to-agent restrictions and sandbox spawned-session clamps still apply. This is permission to ask a privileged agent to act, not a guarantee that it will refuse to disclose data or execute an untrusted request. Strong isolation still requires separate Gateways. See the send-only example.
If someone can modify Gateway host state/config (~/.apus, including apus.json), treat them as a trusted operator.
Inside one Gateway, authenticated operator access is a trusted control-plane role, not a per-user tenant role. Named operator roles bound what each teammate's connections can do; they are collaboration guardrails, not tenant isolation.
sessionKey (session IDs, labels) is a routing selector, not an authorization token.

Before changing remote access, DM policy, reverse proxy, or public exposure, run through the Gateway exposure runbook as a pre-flight/rollback checklist.

Trust boundary matrix

Quick model for triaging risk reports:

Boundary or control	What it means	Common misread
`gateway.auth` (token/password/trusted-proxy/device auth)	Authenticates callers to gateway APIs	"Needs per-message signatures on every frame to be secure"
`sessionKey`	Routing key for context/session selection	"Session key is a user auth boundary"
Prompt/content guardrails	Reduce model abuse risk	"Prompt injection alone proves auth bypass"
Browser evaluate	Intentional operator capability when enabled	"Any JS eval primitive is automatically a vuln in this trust model"
Local TUI `!` shell	Explicit operator-triggered local execution	"Local shell convenience command is remote injection"
Node pairing and node commands	Operator-level remote execution on paired devices	"Remote device control should be treated as untrusted user access by default"
`gateway.nodes.pairing.autoApproveCidrs`	Opt-in trusted-network node enrollment policy	"A disabled-by-default allowlist is an automatic pairing vulnerability"
`gateway.nodes.pairing.sshVerify`	Key-verified node enrollment over operator SSH	"Default-on auto-approval is an automatic pairing vulnerability"
`tools.sessions.visibility` / `tools.agentToAgent`	Session-tool reach inside one Gateway; Gateway-wide and on by default	"Default cross-agent session access is a tenant-isolation bypass"

Not vulnerabilities by design

Common findings closed as no-action

Prompt-injection-only chains without a policy, auth, or sandbox bypass.
Claims that assume hostile multi-tenant operation on one shared host or config.
Normal operator read-path access (for example sessions.list / sessions.preview / chat.history) classified as IDOR in a shared-gateway setup.
Localhost-only deployment findings (for example missing HSTS on a loopback-only gateway).
Discord inbound webhook signature findings for inbound paths that do not exist in this repo.
Node pairing metadata treated as a hidden second per-command approval layer for system.run; the real execution boundary is the gateway's global node command policy plus the node's own exec approvals.
gateway.nodes.pairing.sshVerify treated as a vulnerability because it is enabled by default. It never approves on network locality or SSH reachability alone: the gateway reads the device identity back over SSH (BatchMode, strict host keys) and approves only on an exact device-key match with the pending request, which requires the connecting keypair to already live under the operator's account on a host the operator controls. Checks are bounded to private/CGNAT source addresses, share the trusted-CIDR eligibility floor (fresh scopeless role: node only), and sshVerify: false turns the feature off.
gateway.nodes.pairing.autoApproveCidrs treated as a vulnerability by itself. It is disabled by default, requires explicit CIDR/IP entries, only applies to first-time role: node pairing with no requested scopes, and never auto-approves operator/browser/Control UI, WebChat, role/scope upgrades, metadata or public-key changes, or same-host loopback trusted-proxy header paths (even when loopback trusted-proxy auth is enabled).
"Missing per-user authorization" findings that treat sessionKey as an auth token.
Default Gateway-wide session visibility or default-on agent-to-agent messaging treated as a vulnerability on its own. The audit reports plain multi-agent defaults as info, not a vulnerability finding, and escalates to warn only with trust-boundary signals. One Gateway is one trust boundary; narrow tools.sessions.visibility or tools.agentToAgent for persona separation, and run separate gateways for adversarial users.

Gateway and node trust

Treat Gateway and node as one operator trust domain with different roles:

Gateway: control plane and policy surface (gateway.auth, tool policy, routing).
Node: remote execution surface paired to that Gateway (commands, device actions, host-local capabilities).
A caller authenticated to the Gateway is trusted at Gateway scope; after pairing, node actions are trusted operator actions on that node. See Operator scopes.
Direct loopback backend clients authenticated with the shared gateway token/password can make internal control-plane RPCs without presenting a user device identity. This is not a remote or browser pairing bypass - network clients, node clients, device-token clients, and explicit device identities still go through pairing and scope-upgrade enforcement.
Exec approvals (allowlist + ask) are guardrails for operator intent, not hostile multi-tenant isolation. They bind exact request context and best-effort direct local file operands; they do not semantically model every runtime/interpreter loader path. Use sandboxing and host isolation for strong boundaries.
Trusted single-operator default: host exec on gateway/node is allowed without approval prompts (security="full", ask="off"). That is intentional UX, not a vulnerability by itself.

For hostile-user isolation, split trust boundaries by OS user/host and run separate gateways.

Threat model

Your AI assistant can execute arbitrary shell commands, read/write files, access network services, and send messages to anyone (if given channel access). People who message it can try to trick it into doing bad things, social-engineer access to your data, or check for infrastructure details.

Most failures here are not exotic exploits - they are "someone messaged the bot and the bot did what they asked." Apus's stance, in order:

Identity first - decide who can talk to the bot (DM pairing / allowlists / explicit "open").
Scope next - decide where the bot can act (group allowlists + mention gating, tools, sandboxing, device permissions).
Model last - assume the model can be manipulated; design so manipulation has limited blast radius.

Reporting security issues

Found a vulnerability in Apus? Report responsibly:

Email: security@ami-docs.dev.apuscorp.com
Do not post publicly until fixed.
We will credit you (unless you prefer anonymity).