Skip to content

Safety & security

This section covers the controls that stand between an AI model and your infrastructure: the execution boundary, the three risk tiers, the rules that decide what may run without a click, the two kinds of policy profile, the security model a reviewer needs, and a pre-deployment checklist.

The safety model

  • The AI never gets a shell. A model's output is a proposal. OpsPilot's own code types it into a session only when you approve it, or when it falls in a class you pre-authorised in a Command Safety profile. This is architectural, not a setting.
  • Dangerous commands always need your click. Each profile decides what counts as dangerous and what else may run on its own, but no setting runs a High risk command by itself.
  • Secrets are removed locally, before egress. Terminal output has its escape sequences stripped and passes through the local redactor on its way to any AI provider or assistant, on exactly one path that always redacts first.
  • The rules are yours, per profile. By default your pattern list can only make classification stricter: a pattern match promotes a command to High risk, and the model's own warning still counts. A profile can be set to trust only your list.

The pages in this section

  • Execution boundary & risk tiers — what the boundary is, the three tiers, and how the model's self-assessment and your pattern list combine. Start here.
  • Approvals & auto-run — the three rules each profile sets, what each combination lets run without a click, the auto-run chip, what happens while a command waits, and the typed reason a High risk command can require.
  • Command Safety profiles — the rules and the dangerous pattern list, creating profiles, how they resolve, and why a profile can be less strict than Default.
  • Data Handling profiles — the eleven redaction categories, the six that are on by default, escape-sequence stripping, and custom regular expressions and how they are validated.
  • Security model — the principles, the data-flow diagram, the threat model, licensing traffic, credential storage and session records.
  • Hardening checklist — a thirteen-item checklist and a recommended rollout sequence, usable as a pre-deployment gate.

Who should read what

Reader Read
Engineer using OpsPilot Risk tiers and approvals
Platform owner Both profile pages, then hardening
Security or compliance reviewer Security model and hardening

An engineer needs the tiers and the approval flow, because that is the loop they work in. A platform owner needs both profile pages, because profiles are the policy surface and they are assigned per group and per connection. A reviewer needs the security model and the hardening checklist, where the boundaries and the threat model are set out.

See also