Qwen OpsPilot

Inspiration

A recurring operations failure can look deceptively simple: a PowerShell window flashes every minute on one Windows host, while an apparently equivalent watchdog stays invisible on another. Hiding the task or adding WindowStyle Hidden sounds plausible, but it does not explain why the process is created in the interactive desktop session.

Qwen OpsPilot turns that ambiguity into a safe, reviewable agent workflow. It shows how an Autopilot Agent can investigate a real operational pattern, invoke tools without receiving arbitrary execution authority, and stop for a human decision before any remediation step.

What it does

Qwen OpsPilot loads one anonymized Host A / Host B incident with stable evidence IDs and a SHA-256 fixture hash. A live qwen3.7-plus request first creates an investigation plan. Qwen can then request only four fixed, schema-validated read-only evidence calls. Application code executes those calls, displays the trace, and validates that the final diagnosis separates observed facts from inference and cites only evidence from the current run.

The diagnosis identifies the decisive difference: Host A uses InteractiveToken in the signed-in desktop session, while Host B uses non-interactive S4U in Session 0. A visible policy demonstration proves that unknown or command-shaped tools are blocked.

The agent then presents one exact simulated S4U proposal with its expected outcome, prerequisites, limitations, rollback, hashes, and expiry. Approve and Reject are separate server actions. Approval succeeds only when a short-lived HMAC capability still matches the canonical run, proposal, and fixture. A valid approval changes exactly three fields on a fresh request-scoped clone; no real host or source fixture changes. Five deterministic checks must all pass before the result is marked verified. Finally, the user downloads a token-free Markdown audit report containing the complete investigation and decision record.

How we built it

The deployed application is a dependency-free Python web function on Alibaba Cloud Function Compute with a native HTML/CSS/JavaScript frontend hosted by GitHub Pages. The Qwen API key and approval HMAC secret exist only as encrypted server-side environment variables. The Function Compute backend allows browser reads only from the public GitHub Pages origin and never returns either secret.

The Qwen loop is deliberately bounded to three model responses and four processed tool calls. Tool names, argument shapes, host values, citations, and diagnosis claims are validated by trusted Python code. The human approval token uses HMAC-SHA256 over canonical JSON and binds the run ID, fixture version and hash, canonical run hash, canonical proposal hash, and expiry. Report generation validates a second signed decision envelope.

The browser renders dynamic model content with textContent only. Reports encode variable structures as indented JSON. The application includes deterministic tampering, expiry, idempotence, immutability, verification-failure, injection-safety, and browser-race tests, plus an authenticated live Qwen smoke.

Challenges we ran into

The hardest part was making the agent useful without silently turning model output into authority. A plausible diagnosis is not enough: Qwen had to produce a plan before evidence access, use only named read-only tools, cite current evidence, and remain unable to invent commands, paths, URLs, or mutation steps.

The second challenge was preserving a meaningful human-in-the-loop checkpoint in a stateless web function. The solution was a short-lived canonical HMAC capability for the proposal and a separate signed decision capability for the report. Stable server-side configuration keeps those capabilities valid across Function Compute requests, while every action still starts from the immutable fixture.

Alibaba Cloud's default Function Compute domain adds an attachment header, so the judge-facing UI is hosted by GitHub Pages while every investigation, Qwen, approval, verification, and report API remains on Function Compute.

Accomplishments that we're proud of

• A real Qwen plan-to-tools-to-cited-diagnosis loop with strict response and tool budgets.
• A visible BLOCKED_BY_POLICY path that cannot be bypassed through extra fields or command-shaped input.
• Distinct signed approval and rejection actions with expiry and tamper detection.
• Clone-only, idempotent simulation with no OS mutation API.
• Five exact deterministic verification checks and a complete audit handoff.
• A dependency-free implementation, public MIT repository, architecture diagram, and repeatable test suite.

What we learned

Production-ready agents need more than good prompts. Authority belongs in deterministic code: tool registries, schemas, evidence IDs, canonical hashes, expiry, and explicit state transitions. Model reasoning is most valuable when it is paired with constrained evidence gathering and a human decision that is cryptographically bound to the exact proposal being reviewed.

We also learned that a small vertical slice can demonstrate substantial engineering depth. One incident, implemented end-to-end and tested adversarially, communicates more about operational safety than a broad demo with hidden shortcuts.

What's next

The next step is a separately secured Windows collector that can gather authorized live evidence while retaining the same closed tool contract. Additional playbooks could cover certificate-chain failures, stalled services, and deployment drift. A production version would add authenticated operators, persistent run history, distributed replay protection, policy-managed remediation adapters, and approval audit retention.

Built With

• alibaba-cloud-function-compute
• github
• hmac-sha256
• javascript
• python
• qwen-cloud
• qwen3.7-plus