Security model

Garrison can run commands on every enrolled system and change cloud accounts and firewalls. Its design starts from that: the appliance, not the AI model, decides what runs, and every change needs a person.

The approval gate

• Read-only steps run on their own. A command counts as read-only only if the appliance verifies it: every program in it is a known read-only program without its writing flags; commands may be chained with ;, && or || and piped only into plain text filters (grep, head, sort, wc…); nothing redirects or substitutes (>, <, $(…), backticks), nothing runs in the background, nothing touches credential files, no sudo. The model’s own risk label can only make a step stricter, never looser.
• Read-only cloud calls: AWS describe/list/get (but not secrets, parameters with decryption or object downloads), Azure list/show, Kubernetes reads.
• Everything else is proposed, shown exactly, and runs only when a person approves it. Approving runs exactly the stored proposal: a changed or replayed request cannot run a different command.
• Scheduled jobs run while nobody watches, so they are limited to verified read-only commands (or the one fixed command that was approved when the job was created).

Agents

• Agents connect out to the appliance over TLS; no inbound port on your systems.
• Install commands are pinned to the appliance’s public key, so they only accept your appliance, even before its certificate is trusted.
• Install tokens last at most a day and can only enrol new systems; they cannot take over an enrolled one. Each system then has its own credential, stored root-only on the system.
• Deleting a system revokes its credential and drops its connection at once.
• Agents limit themselves: at most 8 commands at once, 4 terminals, 4 MiB of output per command, 1 hour per command.
• Only a system’s owner can open a terminal to it; output goes only to that session.

The appliance

• Its own certificate authority, limited to the appliance’s names and addresses. The CA key is readable only by root, outside every container.
• The database and cache listen on localhost only. The log and metric stores (Loki, Prometheus) and Grafana listen only on the appliance’s internal docker bridge; the console serves Grafana to signed-in users only.
• Credentials for SIEMs, clouds and devices are encrypted at rest.
• Users are created by admins; standard users see only their own systems, approvals and the integration types they are granted.

Audit

The audit log records every sign-in, every command sent to any agent (whatever path sent it), every terminal session, every approval and rejection, every change to users and integrations, and system deletions. AI Audit records every prompt and answer.

The AI

The models run on the appliance. Prompts, logs and alerts do not leave it unless you connect an external model provider, and then the gateway’s guardrails reject credentials and mask personal data. Content the AI reads (logs, web pages, alerts) can try to steer it; that is why the appliance, not the AI, enforces the approval gate.

Known limitations

We publish what is not done yet:

• Commands are not yet signed end to end (a fully compromised appliance could still send them).
• Agents authenticate with a bearer credential, not yet per-agent certificates.
• Agent binaries are not yet code-signed.
• On Windows, the installer download is not yet key-pinned and the agent’s folder permissions are not yet locked down.