2.0 KiB
Protected request execution
Protected SQL, RCON, and management-program work uses the job channel for its lease and a separate one-time input route for its approved text:
- capabilities:
remote.run.protected.sql,remote.run.protected.rcon, andremote.run.program.command; - input route:
POST /api/v1/run/jobs/protected-request-input; - assignment input ref:
input://protected-request/<job-id>; - adapter kinds:
protected-sql,protected-rcon, andprotected-program.
The signed input request contains the Run endpoint/session, job ID, lease, attempt, and fencing token. Platform returns only the matching job/server/Run identity, fencing token, explicit authorization, approved/unexpired state, claimed queue state, protected request kind, logical transport/target keys, and bounded request text. Neither direction may carry a DSN, database path, password, socket, host path, shell, or raw connection.
Run validates all assignment and response bindings again immediately before
dispatch. A protected request must have exactly one attempt, a non-zero fencing
token, explicit authorization, an approved state, a claimed queue state, a
future expiry, a capability-kind match, and exact transport/target identity
matches. The request text is never written to the job journal or terminal
result.
Transport implementations are registered locally by (kind, transportKey) and
resolve any private connection configuration inside Run. A management-program
handler is an application protocol handler, not a host process or OS shell.
Unknown transport operations, request formats, or fields return the terminal
safe result protected_request_unknown; other transport failures use bounded
diagnostics without forwarding handler errors or response bodies. These errors
affect only the current request.
Management-program stdout and stderr are sent verbatim to the live log relay
with source management-program and streams
management-program.stdout / management-program.stderr. They are not file
execution logs and are never embedded in job result content.