[miguelbranco80]

Human merge required. A human maintainer must manually merge this RFC. Do not enable automatic merging.

Proposed decision

Let administrators approve external HTTPS connectivity for trusted integrations in dedicated Gateways. Use revision-owned CONNECT proxies and Kubernetes NetworkPolicies, with a separate restricted route for control-plane requests. Keep existing Gateway and Harness credential boundaries.

Read RFC-0024.

This extracts the existing RFC from #2518 for focused architectural discussion, not a second proposal. It keeps the proposed architecture and improves its rationale, alternatives, operating costs, and qualification limits. The implementation and its evidence are linked from the document.

Review focus

• Is destination-controlled connectivity for trusted Gateway code the right scope?
• Does revision-owned isolation and tunnel withdrawal justify the per-revision operating cost?
• Could a maintained forwarding engine meet the same contract with less maintenance, without changing the topology?

Scope and verification

Only the RFC and specification index change. This PR contains no implementation code.

• Documentation/link and specification checks, workspace isolation, formatting, and diff checks passed.
• The routing diagram was rendered and visually inspected. Independent prose review completed; the diagnostics requirement it identified was restored.
• At approximately 1,600 visible words, the RFC stays together because authority, routing, withdrawal, and alternatives explain one architectural decision. It is below the 2,500-word hard limit.
• No product tests run: documentation-only change. Runtime qualification remains with implementation delivery.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge.

What this changes

This PR proposes administrator-controlled outbound connectivity for dedicated Gateways through revision-owned CONNECT proxies.

Example: A trusted Gateway integration needs https://api.example.com.

• Before: The bundled Slack-specific proxy refuses api.example.com:443.
• After: Under the proposal, an administrator could approve api.example.com in restricted mode and deploy a revision with that access.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	A coherent, appropriately scoped RFC with no actionable documentation defect; architectural value remains subject to maintainer approval.
Proof confidence	🌊 off-meta tidepool	Not applicable: This documentation-only RFC makes no implementation or runtime qualification claim; the companion draft separately records its evidence and outstanding holds.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Product

Kind: Feature · Worth it: Needs a maintainer decision
User problem: Trusted integrations in dedicated Gateways lack a general administrator-approved route to external HTTPS destinations.
Reason: The capability has a concrete caller and documented boundaries, but new connectivity selections and proxy topology require an owner decision.

Merge readiness

⛔ Blocked before merge - 1 item remains

Keep this PR open for architectural review: it addresses a concrete Gateway connectivity gap, stays within documentation scope, and has no actionable patch findings.

Priority: P3
Reviewed head: de345baaf4401969cdd47f49c16deafe0013c8aa
Owner decision: Required. See Decision needed.

Decision needed

• Question: Should dedicated Gateways gain administrator-approved outbound connectivity through revision-owned proxies, replacing the Slack-specific route?
• Recommendation: Accept the scoped architecture: Approve destination-controlled transport for trusted Gateway code and revision-owned isolation, while keeping forwarding-engine selection and runtime qualification explicit.
• Why: The proposal establishes new Agent and Driver behavior and accepts per-revision operating cost; neither this PR nor its companion discussion records approval of that direction.

Before merge

• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Findings

None.

Agent review details

How this fits together

OCC admits Agent configuration and deployment authority; Kubernetes Compute would translate the admitted connectivity selection into Gateway proxy resources and NetworkPolicies, while Harness credentials and networking retain their existing owners.

flowchart TB
  A[Administrator] -. approves proposed access .-> O[OCC admission]
  O -. snapshots proposed policy .-> C[Kubernetes Compute]
  C -. prepares proposed resources .-> P[Revision proxy]
  G[Dedicated Gateway] -. proposed CONNECT route .-> P
  P -. admitted destinations .-> E[External services]
  G -->|existing transport| H[Dedicated Harness]

Loading

Technical review

Best possible solution:

Resolve the Gateway transport architecture in this RFC and retain implementation qualification in the linked draft.

Do we have a high-confidence way to reproduce the issue?

This is a proposal rather than a bug report; source and existing conformance coverage establish the current Slack-only destination boundary.

Is this the best way to solve the issue?

The proposal coherently extends existing Agent, Compute, and Channel owners, explains the replacement path and operating cost, and distinguishes destination control from credential mediation; accepting that architecture remains a maintainer decision.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against e3c2a56a17f5.

Provenance checked

• RFC implementation-status index keeps the original intent (3115679: The index distinguishes implementation progress from architectural acceptance; this patch increments the unimplemented total and adds a matching proposed entry.)

Security

None.

Evidence

What I checked:

• Pinned introduction is documentation only: The introduced diff adds the proposed RFC and updates its index; it changes no runtime, dependency, deployment, or persisted-data implementation. (specs/rfcs/0024-gateway-outbound.md:1, de345baaf440)
• Current transport does not provide the proposed capability: Current main permits CONNECT only to Slack hostnames on port 443; its existing conformance coverage explicitly expects example.com:443 to be refused. (apps/controller/src/slack-proxy.mjs:40, e3c2a56a17f5)
• Existing ownership is preserved: The authoritative design distinguishes implemented Gateway/Harness separation from remaining capabilities; the RFC leaves Harness credentials, Sandbox policy, and Credential Proxy composition with their existing owners. (docs/design.md:16, de345baaf440)
• Companion implementation and discussion: Draft implementation: managed outbound HTTPS for dedicated Gateways #2518 explicitly identifies this PR as its focused architectural proposal and remains draft. Its body preserves implementation qualification holds; freeqaz's collaborator discussion provides technical review without approving the architecture.
• Feature-history routing: Commit history and GitHub commit patches identify kevinlin-openai's introduction of the bundled Slack proxy and freeqaz's subsequent tunnel and shutdown repairs. Some historical blobs were unavailable locally, so failed blame and follow operations were supplemented with REST commit patches; unsupported line-introduction claims were excluded. (apps/controller/src/slack-proxy.mjs:71, e58c081ba963)
• Supplied media has appropriately limited scope: The downloaded screenshots show historical simulated Gateway network controls from the companion implementation. Video preparation reports ffprobe ENOENT and no browser playback tool is available; none of this media is needed to establish this documentation-only patch's behavior.

Labels

Label changes:

• add P3: This is an architectural proposal with no runtime change or demonstrated urgent regression.
• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: ⏳ waiting on maintainer: Only explicit maintainer approvals or decisions remain; merge is still blocked.

Label justifications:

• P3: This is an architectural proposal with no runtime change or demonstrated urgent regression.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: ⏳ waiting on maintainer: Only explicit maintainer approvals or decisions remain; merge is still blocked.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only. Repair and merge execution lanes are retired.

Reviewed October 24, 2026, 5:35 PM ET / 21:35 UTC.

[freeqaz-openai]

Human Free here. @miguelbranco80:

we've discussed this internally because of the overlap with the Credential Proxy that just landed. I'm wondering about, in terms of the primitives that OCE has, what the right architectural shape to build this would be. It would be nice to not have to have separate implementations of the sandboxing + network proxy primitives just to support isolating the Gateway.

Will bring this up to the team to discuss. As a stop-gap, if you need this while we do deeper refactoring, I would be open to a smaller change/PR that gives this capability. What do you think would be a reasonable minimal change that would work for that? If you want to mint a PR for this to unblock your need, I'm happy to review it.

For the context of this RFC though, I would like to ensure we have a strong design in place that doesn't duplicate sandboxing primitives.

[kevinlin-openai]

I agree with the controls introduced in this pr: limiting gateway outbound, channels contributing destinations, etc

Echo @freeqaz-openai sentiments about not introducing new infra given we already have multiple levels of network proxies on the agent side. We should just wrap the credential proxy around the gateway and implement the controls as proxy authorization rules

[miguelbranco80]

Thanks @freeqaz-openai @kevinlin-openai. We maintain our own fork with a few changes, so we’re not blocked; we can take the time to get the design right (and embedded is always a fallback).

I agree on reusing the existing sandboxing and proxy primitives. We were already experimenting similar-ish ideas, including running the Gateway inside OpenShell through Sandbox/Compute. That part tests containment only though, not Credential Proxy integration or end-to-end OCE provisioning.

Kevin, expressing the controls as Credential Proxy authorization rules makes sense. Are you also thinking of sandboxing the Gateway, or just reusing the proxy? (But it does open that option for later.)

I’ll close this RFC and in parallel, continue an experiment to test both credential requests and approved HTTPS through the shared proxy, with direct external egress blocked. I may contribute an RFC based on those results. (Traveling today to SF and will be in town for a few days, so should have the time.)