The problem
Every "agent + human approval" demo has the same hole. The agent says "delete resource X," a human clicks approve, and nothing binds that click to X. The agent can then execute a different action, or hit a different target, and the click still counts. Approval buttons are theater. As we hand agents real, destructive capability over production infrastructure, that gap stops being cosmetic and starts being the whole risk.
What Airlock does
Airlock runs an autopilot cleanup loop over Alibaba Cloud (ECS and RDS):
- Discover (read-only). The agent lists instances through a self-hosted, read-scoped MCP server and pulls a windowed CPU/memory/disk time series, then applies a deterministic idle policy to decide candidacy.
- Reason (Qwen Cloud). A
qwen3.7-maxplanner produces the one canonical action, and a multi-vendor jury (qwen3.7-plus+deepseek-v4-pro+glm-5.1) independently votes on whether the action is safe given only the evidence. Their disagreement is scored and bound into the proposal. - Gate (sign). On operator approval the checkpoint canonicalizes the exact proposed action (RFC 8785 JCS), hashes it, and issues an Ed25519 approval bound to that hash plus the account, audience, key id, a nonce, and an expiry. Type-to-confirm is required on high-risk actions.
- Execute (write-only). A separate executor, the only write-capable component, re-verifies the signature, re-hashes the presented action, checks account/audience/key/expiry, consumes the approval atomically (single use), re-reads live state against the precondition, rebuilds the write arguments from trusted fields, and only then calls the write MCP server.
Change any field after sign-off and the hash no longer matches, so the write is refused. Replay the same approval and it is refused. An approval authorizes exactly one action against exactly one target, once.
How we use Qwen Cloud (technical depth)
The intelligence layer is Qwen Cloud, used in two ways that go past a single chat call:
- Flagship planner.
qwen3.7-max, marketed as "the agent frontier," arbitrates the canonical cleanup action over the OpenAI-compatible endpoint with JSON-mode structured output. Its output is re-validated against a strict schema, and the executor re-checks the trusted fields regardless, so the model can influence what is proposed but never widen it. - Cross-vendor disagreement jury. The same unified Qwen Cloud endpoint routes each proposal to three heterogeneous model families (Qwen, DeepSeek, GLM). A deterministic disagreement score is computed from their votes and surfaced to the operator: unanimous-safe reads green, a split raises the review bar, and a majority-unsafe verdict flags the action high-risk and forces the stricter type-to-confirm path. This exercises the 150-model platform no other cloud offers and turns "the models agree" versus "the models split" into a legible risk signal a human can act on.
The deliberate design choice worth calling out: we could have let Qwen orchestrate the MCP tool calls directly through hosted tool-calling. We do not. The agent drives the read MCP itself and passes only the gathered evidence to Qwen. Qwen decides; it never holds a tool or a credential. That is exactly what our threat model requires, and it is why a prompt-injected or adversarial model still cannot touch the cloud.
Architecture (innovation and engineering)
Four components, each with the least capability it needs, run as separate processes or containers so the split is a deployment boundary, not just a convention:
| Component | Holds | Never holds |
|---|---|---|
| Agent + Qwen planner/jury | read RAM credential, read MCP tools | write credential, write MCP tool, signing key |
| Checkpoint | Ed25519 private key | cloud credentials of any kind |
| Executor | write RAM credential, Ed25519 public key | private signing key |
| Web app | operator token | any cloud credential |
The guarantee is enforced by capability separation, not prompt filtering. Two self-hosted MCP
servers (a fork of alibaba-cloud-ops-mcp-server) run under separate RAM identities: the read
server exposes only discovery and metrics; the write server exposes only StopInstances,
DeleteInstances, and StopDBInstance. The signer and verifier import one shared JCS
canonicalizer; conformance vectors are checked in eval/.
See docs/architecture.md (and docs/architecture.svg) for the diagram and trust boundaries.
Proof it works
- 106 automated tests cover the approval kernel, canonicalization, signing, tamper and replay rejection, the planner, the jury, the executor, and the checkpoint service.
- JCS conformance vectors in
eval/pin the byte-exact canonicalization the security model depends on; signer and verifier are proven to agree. - A local, no-cloud demo (
demo/local_demo.py) runs the whole gate against the real checkpoint, real Ed25519 keys, and the real approval store, with only the final cloud write mocked. It shows an approved action execute, a replay refused, and a target-swap refused, live. With a Qwen Cloud key set, it also binds a real cross-vendor jury vote into the proposal, so the operator console shows genuine Qwen/DeepSeek/GLM votes without any cloud deployment.
Problem value and impact
Idle and forgotten cloud resources are a universal, recurring cost. Automating their cleanup is obviously valuable and obviously dangerous, which is why it is almost never fully automated. The contribution here is the safety primitive that makes the automation trustworthy: a cryptographically bound, single-use, human approval that an autonomous agent cannot forge, re-target, or replay. The cleanup is the demo; the gate is the product, and it generalizes to any high-consequence agent action. The gate itself is provider-agnostic; the Alibaba Cloud ECS and RDS support is the first provider.
Deployment
Airlock runs on Alibaba Cloud: the two MCP servers on Function Compute (custom container, SSE),
the checkpoint and executor and approval UI on ECS, with read/write RAM separation and the write
MCP endpoint reachable only by the executor. See docs/deploy-proof-checklist.md for the exact
deploy sequence and the artifacts captured as proof.
Built with
Python, FastAPI, Next.js, Ed25519 (PyNaCl/cryptography), RFC 8785 JSON Canonicalization Scheme,
Qwen Cloud (qwen3.7-max, qwen3.7-plus, deepseek-v4-pro, glm-5.1 via the OpenAI-compatible
DashScope endpoint), Model Context Protocol (alibaba-cloud-ops-mcp-server), Alibaba Cloud
Function Compute, ECS, RAM, and Container Registry. License: MIT.
Built With
- qwen
Log in or sign up for Devpost to join the conversation.