[Reborn Cutover Blocker] Preserve brokered HTTP credential injection

[serrrfirat]

Purpose

Track the Reborn cutover / feature-parity blocker for preserving and generalizing IronClaw V1's brokered HTTP credential-injection model.

This is not a post-landing nice-to-have. We should not claim Reborn is ready for user-visible cutover if it regresses V1's credential-injection behavior.

This issue does not have to block every internal substrate PR into reborn-integration, but it must block final Reborn product cutover / feature parity unless explicitly deferred by reviewers with a documented replacement or scope decision.

The core question:

How do we carry forward V1's host-boundary HTTP credential injection into Reborn,
then extend it to more runtime lanes and higher-risk credential use cases without
letting agents/runtimes hold replayable long-lived secrets?

Important clarification: V1 already has this pattern

IronClaw V1 already does meaningful brokered credential injection for HTTP paths. Reborn must preserve this capability or feature parity regresses.

Current V1 evidence:

• src/tools/wasm/credential_injector.rs

  • Documents host-boundary injection.
  • Explicitly says WASM tools never see actual credential values.
  • Maps stored secrets to Authorization headers, custom headers, query params, and URL/path placeholders.

• src/tools/builtin/http.rs

  • Uses SharedCredentialRegistry to match credentials by target host.
  • Auto-injects registered credentials after pre-injection leak scanning.
  • Blocks manual Authorization, x-api-key, api-key, and x-auth-token headers for hosts with registered credentials.
  • Records replay/interceptor request snapshots from pre-injection URL/headers so fixtures do not store injected credentials.
  • Strips sensitive response headers before returning data to the model.
  • Scans response bodies for credential-like leaks.
  • DNS-pins and blocks private/internal IP targets.
  • Revalidates redirects / blocks unsafe redirects.

• src/tools/wasm/wrapper.rs

  • Resolves host credentials before WASM execution.
  • Injects host credentials inside the WASM HTTP host function by matching URL host patterns.
  • Redacts injected values from errors and interceptor records.
  • Uses a redacted Debug implementation for decrypted host credential structs.

• src/auth/mod.rs

  • Refreshes OAuth access tokens before credential injection.
  • Supports an OAuth refresh-proxy path with SSRF validation.

• src/worker/proxy_llm.rs

  • Proxies worker LLM calls through the orchestrator so workers do not hold LLM API keys.

So the cutover bar is:

Reborn must preserve V1's host-boundary HTTP credential-injection safety properties
for equivalent HTTP/WASM/provider flows before those flows replace V1 behavior.

Why this blocks feature parity

Without this work, Reborn risks regressing from V1 in two ways:

1. Security regression

   • V1 can inject credentials at the host HTTP boundary without exposing raw values to WASM/model-visible inputs.
   • A Reborn path that only uses InjectSecretOnce -> SecretMaterial could hand replayable credentials to a runtime or adapter.

2. Product regression

   • Existing HTTP/WASM/skill credential mappings and OAuth refresh flows depend on host-side credential injection.
   • Reborn must offer an equivalent or better path for those integrations before cutover.

One-shot leases are still valuable, but they do not replace host-boundary credential injection:

one-shot lease = when may the host access secret material?
brokered injection = can the runtime use the credential without ever seeing it?

Current Reborn gap

Pieces Reborn already has or is landing:

• scoped encrypted secret storage;
• one-shot secret leases;
• credential account metadata;
• scoped network policy;
• hardened HTTP egress;
• authorization/approval/run-state substrate;
• obligations such as InjectSecretOnce, ApplyNetworkPolicy, RedactOutput, and EnforceOutputLimit;
• runtime policy/preset direction in [Reborn] Add runtime presets and effective runtime policy #3045;
• no-exposure cutover direction in Reborn cutover blocker: add no-exposure safeguards #3032.

Current gap:

• V1's SharedCredentialRegistry + host-mediated HTTP credential injection is not yet represented as a Reborn contract/composition path.
• Direct InjectSecretOnce can still materialize SecretMaterial unless policy forbids direct material injection.
• Reborn network's low-level contract intentionally does not own credential injection or OAuth/token refresh.
• Runtime profiles in [Reborn] Add runtime presets and effective runtime policy #3045 do not yet define which modes require brokered credentials vs direct injection.
• Script/MCP/non-HTTP credential behavior needs explicit policy.
• No-exposure safeguards in Reborn cutover blocker: add no-exposure safeguards #3032 need concrete credential-injection/broker integration tests.

Tentative Reborn target model

Treat these as discussion starters, not final design.

Credential access modes

NoCredential
HostMediatedHttpInjection
BrokeredCredential
DirectInjectDevOnly

or a richer split:

CredentialMode::Deny
CredentialMode::HostMediatedHttpInjection
CredentialMode::BrokeredProxy
CredentialMode::ShortLivedProviderToken
CredentialMode::DirectInjectLocalDevOnly

Credential-use session / injection context

A credential-use session, permit, or host-mediated injection context could be bound to:

ResourceScope
InvocationId
ExtensionId
CapabilityId
CredentialAccountId
SecretHandle(s), metadata only
NetworkPolicy / allowed targets
allowed host/path/method patterns
expiry
max uses
max egress bytes
correlation id / audit id

Runtime flow

CapabilityHost authorizes action
  -> approvals/leases/obligations resolve
  -> host creates brokered credential-use session or host-mediated injection context
  -> runtime receives broker/proxy/session metadata, not secret material
  -> runtime makes approved outbound request through host/broker/egress layer
  -> host/broker injects credential or mints short-lived provider token
  -> events/audit record metadata only

Risk-tiered use

This should not be framed as WASM or HTTP proxy. They are orthogonal:

WASM / sandbox / VM = code isolation
brokered egress / host-mediated HTTP = credential non-exposure and network mediation

Possible policy direction:

Risk tier	Example	Runtime isolation	Credential mode	Network mode	Approval
Public/no auth	fetch public docs	flexible	none	allowlisted/direct logged	low
Low-risk read	repo metadata	safe runtime	host-mediated or brokered token	brokered/allowlisted	maybe none
Private read	Gmail/calendar read	sandboxed/WASM preferred	brokered credential	brokered only	ask/policy
Write/action	send email/post tweet	sandboxed/first-party service	brokered credential	brokered only	preview/confirm
Financial/irreversible	transfer/trade/payroll	strong sandbox/VM or first-party service	brokered + short-lived/action-specific	brokered endpoint only	human confirm
Credential admin	rotate keys/OAuth repair	first-party/system service	broker internal only	broker/provider only	strong approval

Relevant prior art

These projects are relevant references, not predetermined dependencies:

• Infisical Agent Vault: https://github.com/Infisical/agent-vault
• OneCLI: https://github.com/onecli/onecli

Useful pattern from both:

agent/runtime makes normal HTTP request through a local gateway/proxy
  -> gateway matches host/path/method/policy
  -> gateway injects real credential
  -> agent/runtime never sees the real secret

This resembles IronClaw V1's host-boundary HTTP credential injection, but external proxy/gateway patterns may help cover arbitrary runtimes that IronClaw does not fully control.

Open design questions

Please discuss and refine. These are intentionally left open.

1. Port V1 as-is first, or redesign?

   • Should Reborn first port V1's SharedCredentialRegistry + host-mediated HTTP injection semantics as a compatibility baseline?
   • Which V1 safety properties are mandatory to preserve exactly?
   • Which V1 behaviors should be tightened while porting?

2. Native vs external broker

   • Should IronClaw implement a native broker crate/service?
   • Should it integrate with Agent Vault / OneCLI-style external brokers?
   • Do we need an abstraction that supports both?

3. Proxy vs host-mediated request API

   • Should brokered access primarily be HTTPS_PROXY/local gateway for arbitrary runtimes?
   • Should Reborn keep a host-mediated request API for WASM/first-party runtimes?
   • Which model is easier to secure and test?

4. Short-lived provider tokens vs injected long-lived API keys

   • When providers support OAuth/token exchange/downscoping, should the broker mint short-lived tokens?
   • When providers only support long-lived API keys, is target-scoped host/proxy injection enough?
   • How do we represent provider capabilities?

5. Where does this live?

   • New crate such as ironclaw_credential_broker?
   • Composition in ironclaw_host_runtime over ironclaw_secrets + ironclaw_network?
   • Extension to Reborn runtime egress planning?
   • Separate process/sidecar owned by production composition?

6. Runtime lane behavior

   • WASM can use host-mediated HTTP imports. How should brokered sessions plug in?
   • Script/CLI tools may use arbitrary HTTP libraries. Do they require a container/VM where egress is locked to the broker?
   • MCP may be stdio, HTTP, or SSE. How does brokered egress work for each transport?

7. Direct secret material escape hatch

   • Should direct InjectSecretOnce -> SecretMaterial remain only for local-dev/legacy/first-party cases?
   • Which runtime profiles from [Reborn] Add runtime presets and effective runtime policy #3045 must forbid direct material injection?
   • What visible warnings/approvals are required when direct injection is enabled?

8. Target matching and redirects

   • How strict should host/path/method matching be?
   • How are redirects handled?
   • How do we prevent DNS rebinding/private-IP/metadata endpoint attacks?
   • Which V1 redirect/DNS protections should become Reborn contract requirements?

9. Request/response privacy

   • What metadata can broker logs/events/audit store?
   • Should request/response bodies ever be logged?
   • How does this tie into Reborn cutover blocker: add no-exposure safeguards #3032 no-exposure safeguards?

10. Credential account UX

    • How does a user select "Gmail personal" vs "Gmail work"?
    • Is account selection product workflow, policy, or explicit prompt-time input?
    • How do defaults work without becoming silent authority?

11. Approvals and previews

    • For write/financial actions, should brokered credentials always pair with action preview and human approval?
    • What must be previewed: target, method, body summary, account identity, irreversible effect?

12. Non-HTTP credentials

    • How do we handle SDKs, CLIs, gRPC, websockets, browser automation, SSH, database connections, and local credential files?
    • Which should be explicitly out of scope for V1 of this cutover blocker?

13. Testing and proof

    • What integration tests prove "runtime never saw the credential"?
    • How do we test evil.com exfiltration attempts, redirects, logs, events, stdout/stderr, replay fixtures, and model-visible output?

Acceptance criteria for design / cutover readiness

• Document V1's current HTTP/WASM credential-injection behavior and safety properties.
• Decide which V1 properties must be preserved in Reborn before cutover.
• Decide whether the first Reborn implementation is native host-mediated injection, external-broker integration, or abstraction-first.
• Define credential access modes and how they map to runtime profiles ([Reborn] Add runtime presets and effective runtime policy #3045).
• Define broker/session/permit shape and scoping semantics if needed.
• Define which Reborn entrypoint creates broker sessions or host-mediated injection contexts and when they expire.
• Define WASM, Script, MCP, and first-party behavior for brokered credentials.
• Define direct-secret-material escape hatch policy.
• Define no-exposure/audit logging rules and link to Reborn cutover blocker: add no-exposure safeguards #3032.
• Define integration test scenarios for twitter-vs-evil.com style exfiltration.

Acceptance criteria for implementation / feature parity

• Reborn preserves V1's host-boundary HTTP credential injection semantics for equivalent WASM/HTTP/provider calls.
• A high-risk capability can call an allowed provider endpoint without the runtime receiving the reusable credential.
• A request to evil.com receives no credential and/or is blocked before network effect.
• Redirects to disallowed targets are blocked or stripped of credential authority.
• Broker sessions / host-mediated injection contexts are scoped to invocation/capability/account/policy and expire where applicable.
• Broker logs/audit contain metadata only, no raw secret material.
• Direct SecretMaterial injection is disabled for hosted/high-risk profiles unless an explicit policy exception exists.
• Integration tests assert sentinel credentials are absent from runtime input, runtime output, events, audit, logs, process records, replay fixtures, and model-visible results.

Non-goals for the internal substrate PRs

• Do not block unrelated internal substrate PRs on this issue if they do not expose/replace credentialed HTTP/provider behavior.
• Do not replace the one-shot lease model; brokered access builds on top of it.
• Do not pretend Reborn is starting from zero; V1's existing HTTP credential-injection behavior is the baseline to preserve or improve.
• Do not choose Agent Vault or OneCLI as a dependency without a separate design decision.
• Do not solve every provider-specific OAuth/downscoping flow in V1 of this work.
• Do not make direct host network or direct secret injection the default for high-risk hosted workflows.

Related issues

• [EPIC] Track Reborn architecture landing strategy and grouped PR plan #2987 — Reborn grouped landing tracker
• Reborn final integration PR reviewer checklist #3039 — final integration PR reviewer checklist
• [Reborn] Add runtime presets and effective runtime policy #3045 — runtime presets and effective runtime policy
• Reborn cutover blocker: add no-exposure safeguards #3032 — no-exposure safeguards
• [TEST] Reborn: Add vertical-slice integration test suite #3067 — vertical-slice integration test suite
• Reborn cutover blocker: add config-driven production composition root #3026 — production composition root
• Reborn PR1b: add host-controlled trust-class policy engine #3012 — trust-class policy engine