Repository navigation
acq(msb): bind generic custom-endpoint secrets at provision (not just usai) #226
Description
Summary
On the msb backend, acq secret set stores every service in the acq
secret store, but the msb provision path (acq_backend_provision) only binds
a fixed table of services — usai (--secret [email protected])
and, since #230, github (--secret [email protected], REST host
only). Any other custom --host/--env service is stored-but-not-wired — the
*) arm of _acq_msb_service_binding in acq.backends/msb.sh returns empty.
This is a silent no-op relative to sbx, which feeds 7 built-in services plus
custom set-custom endpoints.
This is gap C in the sbx↔msb backend parity epic (#234).
What "done" looks like
- The msb provision path binds any service that resolves a
--host/--env
pair viamsb --secret ENV@HOST(value read from the acq store into a
transient env var, never argv, never the kit spec) — mirroring sbx's
custom-endpoint breadth. acq secret set <custom>on msb re-feeds running sandboxes via
msb modify --secret(as it already does for usai).test-acqcases covering a non-usai custom-endpoint binding on msb.
Explicit exclusion
GitHub is already bound on msb (as of #230, via the REST Authorization: Bearer path msb 0.6.7 does substitute; #203 closed). The generic
git clone over HTTPS to github.com remains upstream-limited (gap F residual),
so kits needing github auth on msb use the REST API, not git clone — but that
is out of scope here. This issue is specifically about arbitrary custom
custom-endpoint services beyond the fixed usai+github table.
Related
- Part of Epic: sbx↔msb backend parity #234 (sbx↔msb backend parity epic — gap C)
- acq(msb): private GitHub repo clone (playbook kit) blocked by msb git-over-HTTPS secret substitution #203 (gap F — github git-over-HTTPS, upstream-limited; REST path resolved in fix(msb): install/launch the agent + mount workspaces at their host path #230)
- ADR-0011 / ADR-0012 (msb secret + rotation model)
AI-assisted (OpenCode); requires human review.
Activity
mogul commentedon Jul 28, 2026
Partial progress on this from #230 (msb backend parity work).
Advanced, but this issue stays open. #230:
acq secret setnow re-feeds running sandboxes viamsb modify --secretfor every bound service (driven off_acq_msb_service_binding), not just usai;acq secret rmlive-unbinds the same way (also new:msb modify --secret-rm).[email protected]) plus a tarball-fetching playbook kit, which sidesteps the git-over-HTTPS gap this issue assumed was a hard blocker. That path also resolves acq(msb): private GitHub repo clone (playbook kit) blocked by msb git-over-HTTPS secret substitution #203, so the "GitHub stays unbound / excluded" note here is now overtaken by events.Still open (gap C proper):
_acq_msb_service_bindingis still a fixedusai+githubtable. An arbitrary stored custom endpoint —acq secret set SANDBOX --host api.example.com --env API_KEY— is still stored-but-not-bound on msb. Fully closing this needs:--host/--envpair (msb'sacq_backend_secret_setdoesn't yet accept/store them), and_acq_msb_service_binding(or the provision loop) to read that back and emit--secret ENV@HOSTfor any stored custom endpoint.That's a separate chunk of work (store schema +
set-customparsing + provision loop + tests), intentionally out of scope for #230. Noted inline in_acq_msb_service_binding.See #230 for the shipped generalization and the msb secret bind/rotate/rm model it builds on.
fix(msb): install/launch the agent + mount workspaces at their host p…
mogul commentedon Jul 29, 2026
Rebase note: #230 (merged to
main) changed the picture here. On msb,_acq_msb_service_bindingis now a fixed two-entry table —usai → [email protected]andgithub → [email protected](REST host only). So the "GitHub stays unbound" exclusion in the issue body is out of date: GitHub is bound now (via the RESTAuthorization: Bearerpath that msb 0.6.7 substitutes; #203 closed).What remains for this issue is unchanged in spirit but narrower in framing: the binding table is still fixed (usai + github), not generic. An arbitrary stored custom endpoint (
acq secret set SANDBOX --host api.example.com --env API_KEY) is still stored-but-not-bound. Closing this needs (1) the acq secret store to persist the per-service--host/--envpair (msb'sacq_backend_secret_setdoes not yet accept/store it) and (2)_acq_msb_service_bindingto read it back for any resolved host/env.The git-over-HTTPS transport limitation stays upstream (gap F residual) — kits needing github auth on msb use the REST API, not
git clone.AI-assisted (OpenCode).
mogul commentedon Jul 29, 2026
Evidence from
msb --tree(msb 0.6.7): the msb secret flags are broader than a single host, which is relevant to how the generic binding should be shaped —msb run/create --secret ENV@HOST[,HOST...]andmsb modify --secret NAME@HOST[,HOST...]both accept a comma-separated multi-host list (value read from host envENVat start, stored as a source reference, never inlined; inlineENV=VALUE@HOSTis rejected).msb run/create --on-secret-violation <block|block-and-log|block-and-terminate|passthrough>controls what happens if a secret is sent to a disallowed host.So the generic custom-endpoint binding this issue asks for can bind one env var to multiple allowed hosts in a single
--secret, and we may want to surface--on-secret-violation(defaulting to a block variant) as part of the acq secret model. No change to the scope here — just capturing the real flag shape so the implementation doesn't assume single-host.AI-assisted (OpenCode).
feat(acq)!: sbx↔msb backend parity, incl. live openchamber-on-msb (om…