You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ORB's Phase B already has a dedicated secrets-at-scale category tracked (#4921-4925): per-tenant secret namespacing, centralized AI-key custody, a KV/Vault binding, extending the installation-secret pattern to AI keys and DB credentials, and a published rotation policy. AMS has zero tracked equivalent for this. That gap matters because AMS's own operational secrets (the AI-provider API keys and, once a shared datastore lands, per-tenant DB credentials) are a different concern from Rent-a-Loop's #4794, which is about what a rented job is allowed to touch at runtime - not about how AMS custodies and rotates its own keys across tenants.
Area
AMS / Secrets management
Proposal
Design how AI-provider API keys and (once the shared datastore lands) DB credentials get namespaced per tenant and centrally custodied for hosted AMS, extending ORB's existing installation-secret exchange pattern (src/orb/broker.ts) rather than inventing a parallel mechanism. The design should cover where secrets live at rest, how a tenant's process resolves only its own namespace, and how rotation is triggered and propagated without downtime.
Deliverables
Design doc covering secret namespacing (per-tenant key/credential scoping), storage (the KV/Vault binding to use), and a rotation policy (cadence, trigger, propagation)
Explicit mapping showing reuse of ORB's installation-secret pattern (src/orb/broker.ts) rather than a parallel mechanism, called out section-by-section against ORB's Add per-tenant namespacing to secret resolution #4921-4925
Resources
src/orb/broker.ts - installation-secret exchange precedent to extend
Rent-a-Loop's Scoped credential handling #4794 - contrast only: scoped credential handling for what a rented job can touch, explicitly out of scope here
This issue must produce a design doc only. It must not ship any code, migration, or binding change, and it must not make a unilateral rotation-policy decision that other maintainer-owned secrets code already depends on without an explicit sign-off step.
Secrets custody and rotation design touches every tenant's blast radius directly - maintainer-only, no partial/contributor-drafted version merged ahead of full review.
Cross-reference (added 2026-07-12)
See also #5120 ("Optional Infisical integration for self-host secrets management") — a separate, already-filed self-host-side secrets plan. Read it before finalizing centralized custody design here, so self-host and hosted don't end up with two divergent secrets stories.
Problem
ORB's Phase B already has a dedicated secrets-at-scale category tracked (#4921-4925): per-tenant secret namespacing, centralized AI-key custody, a KV/Vault binding, extending the installation-secret pattern to AI keys and DB credentials, and a published rotation policy. AMS has zero tracked equivalent for this. That gap matters because AMS's own operational secrets (the AI-provider API keys and, once a shared datastore lands, per-tenant DB credentials) are a different concern from Rent-a-Loop's #4794, which is about what a rented job is allowed to touch at runtime - not about how AMS custodies and rotates its own keys across tenants.
Area
AMS / Secrets management
Proposal
Design how AI-provider API keys and (once the shared datastore lands) DB credentials get namespaced per tenant and centrally custodied for hosted AMS, extending ORB's existing installation-secret exchange pattern (src/orb/broker.ts) rather than inventing a parallel mechanism. The design should cover where secrets live at rest, how a tenant's process resolves only its own namespace, and how rotation is triggered and propagated without downtime.
Deliverables
Resources
Boundaries
Cross-reference (added 2026-07-12)
See also #5120 ("Optional Infisical integration for self-host secrets management") — a separate, already-filed self-host-side secrets plan. Read it before finalizing centralized custody design here, so self-host and hosted don't end up with two divergent secrets stories.