The whole funnel rests on one idea: a job runs under the intersection of two policies, every step lands in a tamper-evident audit log, and payment moves only after that log verifies. Here's the mechanism.
A job carries a policy profile: the employer's ceiling on what the task may touch. The worker's device has its own local policy — the authority the machine enforces. The agent runs under the intersection of the two.
job profile (employer ceiling) device policy (worker authority)
tools: [shell, files, net] tools: [shell, files, net, browser]
shellAllow: [make, git, pytest] shellAllow: [make, git, pytest, npm]
roots: [./workspace] roots: [~/work, ./workspace]
netAllow: [api.github.com] netAllow: [api.github.com, *.example.com]
↓ intersect — narrow, never union
effective grant (what the device actually allows)
tools: [shell, files, net]
shellAllow: [make, git, pytest]
roots: [./workspace]
netAllow: [api.github.com]
If the intersection is empty for something the job requires, the worker can't accept the job — they're told before applying, not failed mid-run. And the device keeps the final word: even a resolved grant is re-checked against local policy at execution. A denied tool is denied, logged, and visible in the dashboard.
Each step is appended to a hash-chained log: every entry carries the SHA-256 of the previous entry, so any edit, gap, or reorder breaks the chain. For a job run, the log records the lifecycle from claim to completion.
job 42 — run 8f2c… on device 9f3a… [09:14:02] run created job=42 policy=job#3 ∩ local plan=sha256:7a… [09:14:05] plan approved approval receipt bound to plan + policy revision [09:15:12] shell "make test" → allow argv=[make,test] [09:15:40] files write ./report.md → allow root=./workspace [09:16:01] net fetch api.github.com → allow ssrf=ok [09:16:33] shell "curl http://169.254.169.254/…" → deny ssrf=internal [09:18:44] run complete entries=4,124 status=succeeded
Note the denied internal fetch: it was refused by the SSRF guard, recorded, and does not count against the worker — but it is visible, because a tamper-evident record is only trustworthy if it records the denials too.
The worker — or the employer, independently — can verify the chain at any time. This is the command, and a realistic output for a completed job run.
$ remoteagent audit verify chain ~/.remoteagent/audit/job-42.log entries 4,124 first 2026-01-15T09:14:02Z run created (job=42) last 2026-01-15T09:18:44Z run complete ✓ hash chain 4,124 / 4,124 links match ✓ cloud anchor matches anchor 6b1d… @ api.remoteagent.online ✓ device signature valid (ed25519) ✓ no gaps · no reorder · no tamper verdict: VERIFIED
If anyone alters a single entry — even one — the chain breaks and the verdict flips to TAMPER DETECTED. That's the property escrow release depends on.
A held payment is not "released when the worker says done." It releases only when all three conditions are true — by construction, not by policy-let's-hope.
verification_status = verified — the chain is intact and no step ran outside the effective grant.
The employer confirms the deliverable. A human signs off; the system doesn't auto-release on a green log alone.
The payment actually cleared into escrow. You can't release money that never arrived.
Post a remote job with a policy profile, or install the agent and deliver work a client can verify.
Post a remote job Install RemoteAgent