06-reference

harrison chase langsmith auth proxy

2026-05-23·reference·source: X (Harrison Chase / LangChain)·by Harrison Chase
credential-brokeringagent-securitylangsmithsandbox-auth-proxynetwork-egress-policyagent-substrate

"How Auth Proxy secures network access for LangSmith agent sandboxes" - @hwchase17

Why this is in the vault

Founder shared 2026-05-23 09:46 ET with explicit framing "another secure agent architecture article", signaling intent to build out the agent-security corpus. SECOND credential-brokering / agent-network-isolation piece from a major actor in 24h after [[2026-05-22-tony-dang-credential-brokering-for-ai-agents]] (Infisical Agent Vault).

⚠️ Sponsorship

Harrison Chase = CEO of LangChain. This article IS the launch announcement of LangSmith Sandbox Auth Proxy, a paid LangChain product (LangSmith Sandboxes feature). Treat as marketing for a real product. The underlying paradigm framing is non-biased and converges with Anthropic Managed Agents, Vercel Sandbox, Cloudflare Outbound Workers, Infisical Agent Vault, but the "Try LangSmith Sandboxes" CTA at the end is sales-funnel.

The core argument

Frame: agents are a fleet of "untrusted developers" that can write code, run commands, install packages, and make network requests on your behalf. The corporate-laptop security stack (endpoint protection, browser filtering, secret scanners, certificate stores) was built to make a powerful open-ended environment safer for one trusted human at a time. It does not scale to spawning "thousands, or eventually millions" of agent instances. For agents the default can flip: if the task is known, the network can be narrower, and credentials should not have to exist inside the runtime at all.

Pattern: a sandbox auth proxy sits on the outbound network path and acts as both credential injector and egress policy enforcer. Sandbox code makes a normal request; the proxy checks policy by destination, optionally blocks, allows, or attaches headers; the request continues upstream without ever exposing the credential to the runtime. Three wins: credentials stay out of the runtime (reducing damage from prompt injection, malicious dependencies, accidental logging, and model mistakes), network access becomes explicit infrastructure policy, and concerns separate cleanly (agent does the task, sandbox isolates, proxy authorizes, app/auth service handles user-scoped access and refresh).

Goes beyond HTTP_PROXY env-var convention: explicit call-out that this is "not implemented by hoping every language, package manager, SDK, or subprocess respects HTTP_PROXY. Not all runtimes behave the same way, and agents often execute arbitrary code paths you didn't write." The proxy intercepts at the network layer, not the application layer.

Three header types: workspace_secret (references a stored LangSmith workspace secret), plaintext (stored and returned as-is, for non-sensitive headers), opaque (write-only, encrypted at rest, never returned by the API). Dynamic credentials via callback support OAuth refresh, per-user-scoped tokens, internally-minted credentials, and TTL caching, with fail-closed behavior on callback error or non-2xx response. Future extensions named: DNS remapping (redirect public registries to internal mirrors), network logging (audit trail of agent network behavior), and request transformation (PII redaction, org metadata, payload policy).

Mapping against Ray Data Co

Reinforces yesterday's gap analysis: [[2026-05-22-tony-dang-credential-brokering-for-ai-agents]] concluded that RDCO's 1Password CLI wrapper pattern (cloudflare-api.sh-style) is NOT functionally equivalent to credential brokering. This is now doubly validated, Harrison's piece is the LangChain launch of the exact pattern Tony Dang named as one of the convergent implementations. Two major actors landed the same paradigm inside 24 hours; the paradigm is hardening fast.

Walks back yesterday's structural-prep recommendation: the proposed "wrap shell scripts with HTTPS_PROXY envelope so a future broker can be inserted without rewriting every script" is directionally correct but UNDER-engineered. Harrison explicitly calls out that HTTP_PROXY/HTTPS_PROXY env-var convention is unreliable because "not all runtimes behave the same way." The real move is sandbox-network-interception (intercept at the network namespace / proxy layer, not the application layer). Worth surfacing this update to the Tony Dang note and the RDCO 1pass-pattern doc so the recommendation reflects the stronger guarantee.

Buy-vs-build implication for RDCO multi-tenant work: for Ray-as-agent-deployer offering, phData consulting (Lionsgate + future clients), or any "Ray operates services on behalf of multiple humans" shape, LangSmith Sandboxes + Auth Proxy is now a real "buy" option (verify pricing on the LangSmith Sandboxes page). Combined with the Anthropic Managed Agents pattern + Cloudflare Outbound Workers (which RDCO is already deep on for HQ) + Infisical Agent Vault, the landscape now has THREE+ buy-options for credential brokering. The build case for RDCO collapses; the integration case dominates.

Concrete next step (defer post phData ramp 2026-05-26): structural revision of ~/.claude/scripts/cloudflare-api.sh and sibling 1pass wrappers, instead of an HTTPS_PROXY envelope plan a migration path to either (a) LangSmith Sandbox Auth Proxy (if RDCO clients are LangChain-stack) or (b) Cloudflare Outbound Worker proxy (RDCO native, founder is deep on CF). Don't ship this today; phData ramp + Lionsgate kickoff Tue 2026-05-26 take priority.

Related