AutOps Security Model — Human-in-the-Loop by Design

The governing principle

Autonomous in diagnosis. Powerless in execution.

The agent may investigate freely and may propose anything. It may not change state. The separation is structural: the analysis module has no route to the execution node, and the execution node only accepts input that the decision module has stamped with a recorded human approval.

This is deliberately more restrictive than most AIOps designs. A fully autonomous remediation agent is faster and, on a good day, indistinguishable from this one. The problem is the bad day: a misdiagnosed root cause becomes a destructive command executed against healthy infrastructure, at machine speed, with no opportunity to intervene. The approval gate costs seconds and removes that entire class of outcome.

Control inventory

Each control below is marked with its actual status in the current prototype. Controls marked designed are specified in the system requirements and partially realised; treat them as roadmap rather than as guarantees when threat-modelling your own deployment.

Security controls and implementation status
Control	What it does	Status
Approval gate	Blocks every state-changing command pending an explicit administrator reply	Enforced
Prompt-level restriction	System prompt forbids the agent from autonomously issuing destructive commands	Enforced
Module separation	Reasoning and execution are distinct workflows with no direct path between them	Enforced
Command whitelist	Cross-references every command against an allowed set before execution	Enforced
State validation	Confirms an unresolved incident exists before honouring an approval	Enforced
Key-based SSH	Cryptographic key authentication to the host; no password auth	Enforced
Container isolation	Each service in its own container on isolated internal Docker networks	Enforced
TLS termination	Nginx reverse proxy fronts the orchestration engine	Enforced
Secret externalisation	Credentials supplied via environment variables, never committed to the repository	Enforced
Role-based access control	Distinguishes full operational control from read-only analytical access	Designed
Encrypted credential store	Credentials encrypted at rest rather than held as plain environment values	Designed
Comprehensive audit log	Immutable record of every proposal, decision and execution	Designed

Command whitelisting and negative testing

The execution module does not trust its own input, including input that originated from the AI. Every command is cross-referenced against a strict whitelist before it runs; anything not on that list is blocked and logged as a priority security incident rather than silently dropped.

This path was validated by deliberate negative testing. Test scripts attempted to inject malicious payloads — directory traversal, destructive recursive deletion, piping a remote download straight into a shell — to confirm that the whitelist refuses them. The tests target the boundary, not the model: the assumption is that the agent may one day propose something dangerous, and the whitelist is what makes that harmless.

Defence in depth, concretely

For a destructive command to reach a server it would have to pass the prompt restriction, then the module boundary, then policy evaluation, then state validation, then an explicit human approval, then the execution whitelist. Six independent controls, of which any one holding is sufficient.

Behaviour under failure

Security properties that only hold on the happy path are not security properties. Two failure modes were explicitly designed for:

Unreachable host: SSH connection refusals and timeouts are caught rather than allowed to crash the pipeline. The service is recorded as down and the fallback notification path alerts the operator, so a monitoring failure is itself surfaced instead of appearing as silence.
Stale approvals: An approval for an incident that has already been resolved, or for a container with no outstanding fault, is rejected at the validation gateway. Replaying an old !approve message cannot trigger a fresh execution.

Threat model

Identified risks and their mitigations
Risk	Consequence	Mitigation
False positives	Unnecessary alerts from misconfigured thresholds or partial data, leading to alert fatigue	Configurable thresholds, ephemeral-container whitelisting, alert validation logic, and human approval before any action
Incorrect AI diagnosis	A plausible but wrong remediation proposal	Proposals are recommendations, never enforced actions; the administrator makes the final decision and sees the exact command first
Unintended automation impact	A restart or script harming a healthy service	Approval gating plus restriction to predefined, tested workflows
Credential compromise	Unauthorised server access via leaked SSH keys or API tokens	Key-based auth, secrets outside version control, container isolation; encrypted storage and RBAC are designed extensions
Messaging channel compromise	An attacker with channel access could issue an approval	Approvals are constrained to a dedicated administrative channel and validated against existing pending state; channel access control is the operator's responsibility
Third-party outage	Loss of the approval path leaves the operator blind	Acknowledged residual risk; the system fails closed, taking no action rather than acting unsupervised

Residual risk: prompt injection

A known gap, stated plainly

AutOps feeds container logs into a language model. Logs are untrusted input: they can contain whatever text an attacker managed to get an application to write. An adversary who can influence log content can therefore attempt to influence the agent's reasoning — for example by embedding text designed to be read as an instruction rather than as data.

The current architecture limits the impact of this rather than preventing the attempt, and the limits are real ones: a successfully injected instruction still cannot execute anything. It would have to produce a proposal that passes the whitelist and that a human reads and approves. The realistic worst case is a misleading diagnosis or a wasted approval prompt, not an autonomous compromise.

Operators deploying AutOps in sensitive environments should consider:

keeping the execution whitelist as narrow as the environment allows, ideally to a fixed set of service restarts;
reading the proposed command every time rather than approving on the strength of the diagnosis text;
restricting the administrative channel to the smallest possible set of people;
treating any proposal that references an unexpected host, path or binary as a signal to investigate manually.

Planned work includes intercepting AI-suggested commands that appear mid-conversation and routing them through the same formal approval gate, so a command mentioned in open dialogue cannot be acted on informally.

Your responsibilities as an operator

A self-hosted deployment puts several controls in your hands rather than the system's.

Host hardening. AutOps assumes it is running on a maintained, patched host with a configured firewall. It does not harden the server for you.
Key hygiene. Generate a dedicated SSH key for AutOps, scope it as narrowly as your setup permits, and rotate it on a schedule.
Secret management. Populate credentials from your own .env, keep that file out of version control, and restrict its file permissions.
Channel access. The approval channel is a privileged interface. Treat membership in it as equivalent to granting SSH access.
Whitelist review. Review the allowed command set when your service topology changes.

About this website

The site you are reading is static HTML with no client-side dependencies beyond a webfont. It is served with a restrictive Content-Security-Policy, frame-ancestors 'none', X-Content-Type-Options: nosniff, a strict referrer policy and a Permissions-Policy denying camera, microphone and geolocation. There is no analytics, no tracking and no third-party script. The contact form validates and rate-limits server-side and stores nothing beyond what is needed to reply to you.

Reporting a vulnerability

If you find a security issue in AutOps, we would rather hear about it than not. Please report it privately first — use the contact form and select the security subject, or open a security advisory on the repository. Please do not open a public issue with exploit details before we have had a chance to respond.

Include what you did, what you observed, and the version or commit you tested. If the issue involves a specific command or payload, describe the class of problem rather than attaching a working exploit.

Report privately Repository