GitLab Transcend · October 2026 · Path A

One command. Signed. No address.

An agent can read a repository and comment on an issue, but it cannot run a single command on the host behind the firewall — which is where the failure actually is. Dropline is a dead drop for exactly that: A leaves one request, only the host agent collects it, and the answer comes back hashed and signed. Read-only by default, no socket anywhere.

gitlab.com/athulpsudheer/dropline · MIT · 116 core tests · build passes with no dependencies

01 · The loop

A writes a request. Only the host agent answers it. A verifies what comes back: the result's own hash, the hash of the request it answers, the signature over both, and that it is newer than the request.

A · agent writes request verifies result drop file or pipe no listener C · host policy → argv redact → sign request: do, do-not, hash, sig result: exit, output, hash, request-hash, sig
idle
  1. request written — nothing runs
  2. policy — closed binary set, no shell
  3. execute — argv, timeout, capped output
  4. redact — secrets never reach the file
  5. hash + sign — result, and the request it answers
  6. verify — hash, request-hash, signature, freshness

02 · Refusals are the product

A channel is defined by what it will not do. This mirrors the rules in crates/dropline-core/src/policy.rs; the real engine runs on the host, not in this page.

ALLOWEDthe host agent would run argv: ["uname", "-sr"]

03 · Tamper and drift are caught

Every result carries its own SHA-256 and the hash of the request it answers. Edit one byte and the stored hash no longer describes the content.

stored hash: recomputed: match

04 · Bits on the wire, bits on disk

The channel can carry a bare bit stream: HDLC flags, bit stuffing, CRC-32. Storage keeps the same bits packed eight per byte — no base64, no JSON, no header. The only extra bits are the ones that let a receiver trust them.

400
payload bytes
3248
bits on the wire
406
stored bytes
48
overhead bits

05 · The pipeline runs the loop

The drop boundary is a job boundary: one job writes the request, only another job's container answers it, a third verifies and fails the pipeline on any mismatch. The signing key is derived per pipeline, so nothing is stored.

handoff_request→ handoff_host→ handoff_verify hash · request-hash · signature · freshness

pipeline 2960812205 · 13 of 13 jobs green · the incident job is skipped because nothing failed