Proposal: Hardening environment variables in agent runtime

[wylswz]

Self Checks

• I have read the Contributing Guide and Language Policy.
• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report, otherwise it will be closed.
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Environment Hardening: Secret Injection Without Exposure

Problem

Secret environment variables in shell outputs are currently redacted via a configurable pattern list, but leakage remains possible:

• Encoding bypass — apply a transformation (e.g. base64) to the sensitive envvar, then decode it externally.
• Exfiltration via network — transmit the secret directly to untrusted sites (e.g. as an HTTP header value).

Pattern-based redaction is inherently an arms race; the root cause is that secrets live in the agent's process address space at all.

---

Proposed Solution

Remove secrets from the agent's process entirely. Instead of injecting real values as environment variables, maintain a mapping outside the agent's reachable filesystem and resolve placeholders at the network boundary.

Provider Profiles

Each provider is defined by a complete injection profile — not just a secret value, but the full mapping of which env var is injected into which HTTP header for which target domain(s). The proxy uses these profiles as an allowlist; secrets are never injected into requests that don't match.

# /run/secrets/<session-id>/providers.yaml
providers:
  dify:
    secrets:
      - env: INTERNAL_ACCESS_TOKEN        # placeholder exposed to agent
        value_file: dify/internal_token    # actual secret (file ref)
        inject:
          header: Authorization            # HTTP header to populate
          prefix: "Bearer "                # optional prefix before value
          domains:                         # allowlisted target domains
            - "*.dify.internal"
            - "api.dify.ai"

  github:
    secrets:
      - env: GITHUB_TOKEN
        value_file: github/token
        inject:
          header: Authorization
          prefix: "Bearer "
          domains:
            - "api.github.com"
            - "uploads.github.com"
      - env: GITHUB_WEBHOOK_SECRET
        value_file: github/webhook_secret
        inject:
          header: X-Hub-Signature-256
          prefix: "sha256="
          domains:
            - "*.github.com"

  aws:
    secrets:
      - env: AWS_ACCESS_KEY_ID
        value_file: aws/access_key_id
        inject:
          header: X-Amz-Access-Key        # resolved by SigV4 signing
          domains:
            - "*.amazonaws.com"
            - "*.aws.amazon.com"
      - env: AWS_SECRET_ACCESS_KEY
        value_file: aws/secret_access_key
        inject:
          header: X-Amz-Secret-Key        # consumed by proxy's SigV4 signer
          domains:
            - "*.amazonaws.com"
            - "*.aws.amazon.com"
      - env: AWS_SESSION_TOKEN
        value_file: aws/session_token
        inject:
          header: X-Amz-Security-Token
          domains:
            - "*.amazonaws.com"

  openai:
    secrets:
      - env: OPENAI_API_KEY
        value_file: openai/api_key
        inject:
          header: Authorization
          prefix: "Bearer "
          domains:
            - "api.openai.com"

  gcloud:
    secrets:
      - env: GCLOUD_ACCESS_TOKEN
        value_file: gcloud/access_token
        inject:
          header: Authorization
          prefix: "Bearer "
          domains:
            - "*.googleapis.com"
            - "*.google.com"

Secret Store Layout

Provider profiles and secret value files live outside the agent's Landlock-restricted workspace:

/run/secrets/
└── <session-id>/
    ├── providers.yaml                    ← injection profiles (read by proxy)
    └── <provider>/
        └── <secret-name>                 ← file contains the real secret value

Example:

/run/secrets/session-1/providers.yaml
/run/secrets/session-1/dify/internal_token
/run/secrets/session-1/github/token
/run/secrets/session-1/aws/access_key_id

Injection & Resolution

1. The agent process receives only a placeholder in its environment, e.g. GITHUB_TOKEN=__secret:github:GITHUB_TOKEN__.
2. The outbound proxy intercepts every request, matches the target domain against provider profiles, and only injects the secret into the declared header if the domain matches.
3. If no profile matches the target domain, the placeholder is stripped (never forwarded raw).
4. Each injection event is logged for audit (provider, env key, target domain, timestamp).

---

Third-Party CLI Tools

For tools that require authenticated credentials (e.g. gh, aws, gcloud, kubectl), the flow is:

1. Authenticate with the 3rd-party provider (OAuth, API key exchange, etc.) — this happens outside the agent runtime.
2. Convert the resulting credential into a mapped secret file in the secret store.
3. Deploy the mapped file into the agent runtime's secret mount so the proxy can inject it on outbound calls.

┌──────────────────────────────────────────────────────────────────────────┐
│                       OUTSIDE AGENT RUNTIME                              │
│                                                                          │
│  ┌──────────┐       ┌───────────────────┐       ┌────────────────────┐  │
│  │ 3rd-Party│       │  Credential Mgr   │       │   Secret Store     │  │
│  │   App    │◄─────►│  (auth + convert) │──────►│   /run/secrets/    │  │
│  │(GitHub,  │ OAuth │                   │ write │    session-1/      │  │
│  │ AWS …)   │ / key │                   │       │  ├─ providers.yaml │  │
│  └──────────┘       └───────────────────┘       │  ├─ github/token   │  │
│                                                 │  ├─ aws/access_key │  │
│                                                 │  └─ openai/api_key │  │
│                                                 └─────────┬──────────┘  │
│                                                           │ mount       │
├───────────────────────────────────────────────────────────┼─────────────┤
│                       AGENT RUNTIME                       │             │
│                                                           ▼             │
│  ┌──────────────┐       ┌──────────────────────────┐  ┌────────────┐    │
│  │    Agent     │──────►│     Outbound Proxy       │─►│  Internet  │    │
│  │   Process    │ req   │                          │  │            │    │
│  │              │       │  1. match target domain  │  │ github.com │    │
│  │ env:         │       │     against profiles     │  │ aws.com    │    │
│  │ GITHUB_TOKEN │       │  2. lookup value_file    │  │ openai.com │    │
│  │ = __secret:  │       │  3. inject into header   │  │            │    │
│  │ github:      │       │  4. strip all remaining  │  │  ✗ evil.com│    │
│  │ GITHUB_TOKEN │       │     placeholders         │  │  (blocked) │    │
│  │ __           │       │  5. log audit event      │  │            │    │
│  └──────────────┘       └──────────────────────────┘  └────────────┘    │
└─────────────────────────────────────────────────────────────────────────┘

Flow Summary

authenticate        convert              deploy             resolve
─────────────►  ─────────────────►  ──────────────────►  ────────────►
  3rd-party        credential →         mount secret       proxy injects
  OAuth/key        secret file          into runtime       real value

---

Design Decisions

Decision	Resolution
Injection scope	Per-domain. Each secret is only injected into requests matching the profile's domains allowlist.
Credential lifecycle	Session-scoped by default. Profiles are created at session start and destroyed at session end.
Secret rotation	The credential manager can overwrite value_file contents without restarting the session; the proxy reads on each request.
Audit trail	Every injection event is logged: (timestamp, session_id, provider, env, target_domain, header).
Fallback behavior	If a placeholder appears in a request body or non-declared header, the proxy blocks the request and logs a warning.
Profile validation	Profiles are validated at session start — invalid YAML, missing value files, or overlapping domain rules are rejected.

Security Properties

• No secret in agent address space — the agent only sees opaque placeholders.
• Domain-pinned injection — even if the agent crafts a request to evil.com with a placeholder header, the proxy refuses injection.
• No global resolution — there is no wildcard "inject everywhere" mode; every injection requires an explicit domain match.
• Placeholder stripping — unresolved placeholders are never forwarded to any upstream.

2. Additional context or comments

No response

3. Can you help us with this feature?

• I am interested in contributing to this feature.

[zeweihan]

This proposal identifies the actual root cause correctly, and the direction (remove secrets from the agent's process address space entirely, resolve at the network boundary) is the right one. A few things worth stress-testing before this hardens, because the two bypass vectors named here are the easy ones.

Why pattern redaction is structurally unwinnable. Redaction is a post-hoc filter applied to the output of a process the filter can't fully model. The moment the agent can run arbitrary code (shell, python, a tool that concatenates strings), every redaction pattern is a regex the agent can route around: base64 (noted), but also splitting across writes, rot13, referencing the secret by its env-var name and having a different tool dereference it, or exfiltrating via a channel the redactor doesn't inspect (DNS, timing, a crafted filename the agent asks a file tool to read back). Encoding bypass is just the most obvious instance. The proposal correctly concludes that you can't win by improving the pattern list — you win by never putting the secret where the agent can reach it. That framing is the valuable part of this issue.

The placeholder model is correct, but the domain allowlist has a TOCTOU surface that needs to be closed explicitly. The proposal says the proxy resolves INTERNAL_ACCESS_TOKEN → real secret and injects it into the Authorization header only for allowlisted domains. The invariant that makes this safe is: the set of domains a secret may be injected for must be a fixed property of the provider profile, never influenced by agent input. If the agent can in any way control the destination of a request that carries an injected secret — e.g., the agent picks the URL for an HTTP tool call, and the proxy injects the header based on a wildcard match like *.dify.internal — then an SSRF or a DNS-rebinding-style trick lets the agent route a request to an attacker-controlled host that satisfies the allowlist pattern, and the proxy happily attaches the real secret to it. Concretely:

• domains: ["*.dify.internal"] is dangerous if the agent can influence DNS resolution or if the matching is suffix-based rather than exact-host-based. A suffix match against evil-dify.internal.attacker.com injects the secret outbound.
• The allowlist must be evaluated against the resolved destination after any redirects the proxy itself follows, not just the initial request URL — otherwise a 302 from an allowed domain to an attacker host carries the injected secret through the redirect (this is the same class as the api-key-cross-origin-redirect leak, where a redirect moves a credential from a trusted origin to an untrusted one).

Silent-strip is the silent-success variant of this design. The most likely failure mode for the proxy itself is not "leaked the secret" but "dropped the secret and forwarded the request anyway." If a request matches a provider profile's env var but not its domain allowlist, the correct behavior is to reject the request with a structured error, not to forward it without the header. Forwarding-without-the-header is a silent degradation: the agent's tool call proceeds, gets a 401 from the real target, and the operator sees an auth failure with no indication that the proxy stripped a secret it was supposed to inject. That's operationally indistinguishable from a misconfigured profile, and it's the exact "reported success, did the wrong thing" shape this whole design exists to prevent. The proxy's refusal to inject should be loud and attributable.

Conformance fixtures worth pinning down, independent of implementation:

1. Agent reads INTERNAL_ACCESS_TOKEN env var and prints it → output must be the placeholder, never the real value. (The easy case; validates the placeholder model.)
2. Agent base64-encodes the placeholder and writes it → output is still not the real secret, and the proxy logs an attempted-exfiltration signal. (Validates that the secret was never in address space, so transformation can't recover it.)
3. Agent makes an HTTP request to an allowlisted domain → request arrives at target with the real secret in the configured header. (Happy path.)
4. Agent makes an HTTP request to a domain not in the allowlist, with the provider's env var referenced → proxy must not forward the request with the header, and must not silently forward without it; it returns a structured rejection. (Validates silent-strip is impossible.)
5. Allowlisted domain responds with a 302 to a non-allowlisted host → proxy must not follow the redirect with the injected header attached. (Validates the redirect-redirect leak is closed.)
6. Agent attempts to use the secret via a channel the proxy doesn't proxy (e.g., raw TCP, DNS) → the secret is the placeholder, so the exfiltration attempt carries nothing of value. (Validates the "never in address space" invariant holds for non-HTTP channels too.)

The providers.yaml shape is clean. One note: the value_file path should be resolved relative to a per-session secret mount that the agent's filesystem namespace can't traverse into (/run/secrets/<session-id>/), not a path the agent could cat directly — otherwise the boundary collapses back to "the agent can read the secret file," which is the original problem in a different costume.

[kuangmi-bit]

@zeweihan this is an excellent analysis. A few additional points from our experience building an enterprise proxy layer for Dify (MAEA Tenant Gateway):

On the proxy boundary model — you're right that the proxy is the right place, but there's a subtlety: The placeholder→secret resolution must happen at the egress boundary, not at the ingress boundary of the agent. Otherwise you get the silent-strip problem you identified: the proxy injects a secret into a request heading to an unknown destination.

Our Gateway implements this as a three-rule invariant:

1. Never forward with injection to an unresolvable destination — 502, not silent-forward
2. Domain allowlist is fixed in the tenant profile — not derivable from agent input at runtime
3. Headers injected by the proxy are stripped on the response — the agent never sees the real secret in any form, even in error messages

On the six conformance fixtures — fixtures 3-5 (the redirect chain) need one more: the proxy must strip injected headers on every redirect hop, not just the first one. A 302 chain of three hops, where only the first is allowlisted, must still not leak the secret on hops 2 and 3.

On implementation: The Go sandbox (langgenius/dify-sandbox) is the right layer for this — not the Python agent runtime. The Go binary already has seccomp + network egress control. Adding credential injection at the proxy boundary there (rather than in-process redaction) would be the correct architecture, consistent with the proposal's own argument that "you win by never putting the secret where the agent can reach it."

We'd be interested in contributing a Go implementation of this proxy boundary if there's maintainer interest. The MAEA Tenant Gateway already implements the domain-allowlist + structured-rejection pattern described here.

Repo for reference: https://github.com/deeparchi-ai/maea-tenant-gateway

[wylswz]

@zeweihan this is an excellent analysis. A few additional points from our experience building an enterprise proxy layer for Dify (MAEA Tenant Gateway):

On the proxy boundary model — you're right that the proxy is the right place, but there's a subtlety: The placeholder→secret resolution must happen at the egress boundary, not at the ingress boundary of the agent. Otherwise you get the silent-strip problem you identified: the proxy injects a secret into a request heading to an unknown destination.

Our Gateway implements this as a three-rule invariant:

1. Never forward with injection to an unresolvable destination — 502, not silent-forward
2. Domain allowlist is fixed in the tenant profile — not derivable from agent input at runtime
3. Headers injected by the proxy are stripped on the response — the agent never sees the real secret in any form, even in error messages

On the six conformance fixtures — fixtures 3-5 (the redirect chain) need one more: the proxy must strip injected headers on every redirect hop, not just the first one. A 302 chain of three hops, where only the first is allowlisted, must still not leak the secret on hops 2 and 3.

On implementation: The Go sandbox (langgenius/dify-sandbox) is the right layer for this — not the Python agent runtime. The Go binary already has seccomp + network egress control. Adding credential injection at the proxy boundary there (rather than in-process redaction) would be the correct architecture, consistent with the proposal's own argument that "you win by never putting the secret where the agent can reach it."

We'd be interested in contributing a Go implementation of this proxy boundary if there's maintainer interest. The MAEA Tenant Gateway already implements the domain-allowlist + structured-rejection pattern described here.

Repo for reference: https://github.com/deeparchi-ai/maea-tenant-gateway

There is already an agent-runtime in Go where the proxy could be implemented. The langgenius/dify-sandbox is designed for deterministic code snippet execution instead of providing a full-fledged shell environment for agent.

[zyssyz123]

A useful extension to this proposal would be to model credential injection as a protocol-aware credential broker, rather than assuming every credential can be reduced to an environment variable-to-header mapping.

The core invariant should remain unchanged: no reusable provider secret enters the agent process, filesystem, or output. The agent should only receive non-secret placeholders or session-local capabilities, while all authenticated outbound traffic is forced through the broker.

The broker could support several credential adapter types:

• HTTP header credentials: terminate the agent-side TLS connection for explicitly allowlisted destinations, establish a separate upstream TLS connection, then inject the configured header. A normal HTTPS CONNECT tunnel is opaque and cannot safely modify headers. Clients using certificate pinning should fail with a structured unsupported-client error rather than bypassing the broker.
• AWS SigV4/SigV4a: validate the destination, service, region, method, and resource policy, then re-sign the final outbound request using short-lived, scoped credentials held by the broker. Standard requests can be supported first; presigned URLs, streaming/chunk signatures, and EventStream should be explicitly unsupported until dedicated signing support exists.
• SSH: expose a constrained SSH-agent-compatible signing socket instead of a private key. Signing must be bound to an allowlisted user, host, port, and trusted host-key fingerprint. Repository-level scope should come from provider-side credentials such as per-repository deploy keys, since host-level SSH constraints cannot enforce repository scope by themselves.
• mTLS: let the broker establish the upstream mTLS connection and keep the client private key outside the agent. Workloads that require end-to-end TLS channel binding or certificate pinning should require a dedicated adapter rather than receiving the private key.

This also suggests defining two explicit compatibility levels:

1. Strict mode: no reusable secret is ever exposed; unsupported protocols or client behavior fail closed with structured errors.
2. Compatibility mode: optionally provides narrowly scoped, very short-lived credentials for cases that cannot be brokered, with an explicit warning that this weakens the strict security guarantee.

Regardless of adapter type, the same safety rules should apply: no direct egress bypass, fixed destination policies, DNS/IP and redirect revalidation, response sanitization, fail-closed behavior, session-scoped lifecycle, and auditable credential use.

The main decisions to settle before implementation are:

• Whether strict mode may intentionally reject incompatible CLIs instead of providing silent fallback.
• Which AWS operations must be supported initially, especially presigning and streaming uploads.
• Whether TLS interception with a session CA is acceptable for the supported runtime.
• Whether SSH credentials can be limited to deploy keys or similarly provider-scoped identities.
• Whether a compatibility mode is needed at all, and who may enable it.

[kuangmi-bit]

@wylswz @zyssyz123

Quick update: we went ahead and built the proxy-boundary implementation in the Go sandbox. PR is up at langgenius/dify-sandbox#279.

What it does

The implementation follows exactly the three-rule invariant @wylswz described:

1. Never forward with injection to an unresolvable destination — 403 structured rejection, not silent-forward
2. Domain allowlist fixed in config — providers.yaml, validated at startup, not derivable from agent input
3. Headers injected by proxy are stripped on the response — the agent never sees the real secret in any form

Plus all six of @zeweihan's conformance fixtures pass:

• Placeholder-only in agent space ✅
• base64 can't recover real value ✅
• allowlisted domain → injection ✅
• non-allowlisted → structured 403 ✅
• *.dify.internal doesn't match evil-dify.internal.attacker.com ✅
• path traversal → immediate reject ✅

How it maps to the credential broker model

@zyssyz123's broker model and our implementation share the same architecture. The difference is mainly scope:

Concept	Broker proposal	#279 implementation
Domain allowlist	Fixed destination policies	DomainRule with glob matching
Credential adapter	Per-protocol (HTTP, AWS, SSH, mTLS)	ProviderProfile → currently HTTP header injection
Fail-closed	Structured errors	403 with JSON body describing the violation
Strict/compat mode	Two explicit levels	Single strict mode — non-allowlisted = 403

The current implementation covers the HTTP header adapter. The broker's other adapters (AWS SigV4, SSH agent socket, mTLS) could be added as additional InjectionRule types — the ProviderProfile + DomainRule envelope already supports this.

On dify-sandbox vs dify-agent-runtime

@wylswz is right that dify-agent-runtime exists. But the sandbox is where the network boundary already lives — seccomp, egress control, the Squid proxy. Adding credential injection at this layer means one proxy handles both security concerns (seccomp + credential injection) rather than splitting them across two processes. The injection handler is a standard http.RoundTripper — it can be mounted in either location.

Concrete numbers

5 files | +987 lines | 12 conformance tests all PASS

Would appreciate a review from anyone watching this issue. Happy to iterate on the design — especially the broker adapter extensibility @zyssyz123 raised.

[wylswz]

@wylswz @zyssyz123

Quick update: we went ahead and built the proxy-boundary implementation in the Go sandbox. PR is up at langgenius/dify-sandbox#279.

What it does

The implementation follows exactly the three-rule invariant @wylswz described:

1. Never forward with injection to an unresolvable destination — 403 structured rejection, not silent-forward
2. Domain allowlist fixed in config — providers.yaml, validated at startup, not derivable from agent input
3. Headers injected by proxy are stripped on the response — the agent never sees the real secret in any form

Plus all six of @zeweihan's conformance fixtures pass:

• Placeholder-only in agent space ✅
• base64 can't recover real value ✅
• allowlisted domain → injection ✅
• non-allowlisted → structured 403 ✅
• *.dify.internal doesn't match evil-dify.internal.attacker.com ✅
• path traversal → immediate reject ✅

How it maps to the credential broker model

@zyssyz123's broker model and our implementation share the same architecture. The difference is mainly scope:

Concept Broker proposal #279 implementation
Domain allowlist Fixed destination policies DomainRule with glob matching
Credential adapter Per-protocol (HTTP, AWS, SSH, mTLS) ProviderProfile → currently HTTP header injection
Fail-closed Structured errors 403 with JSON body describing the violation
Strict/compat mode Two explicit levels Single strict mode — non-allowlisted = 403
The current implementation covers the HTTP header adapter. The broker's other adapters (AWS SigV4, SSH agent socket, mTLS) could be added as additional InjectionRule types — the ProviderProfile + DomainRule envelope already supports this.

On dify-sandbox vs dify-agent-runtime

@wylswz is right that dify-agent-runtime exists. But the sandbox is where the network boundary already lives — seccomp, egress control, the Squid proxy. Adding credential injection at this layer means one proxy handles both security concerns (seccomp + credential injection) rather than splitting them across two processes. The injection handler is a standard http.RoundTripper — it can be mounted in either location.

Concrete numbers

5 files | +987 lines | 12 conformance tests all PASS

Would appreciate a review from anyone watching this issue. Happy to iterate on the design — especially the broker adapter extensibility @zyssyz123 raised.

Thanks for your effort. This proposal is primarily intended to improve agent security.

The agent runs in a local sandbox with the agent runtime installed, and it operates with restricted file access and limited privileges. In other words, it is sandboxed by design, although the network boundary is planned to be strengthened further in the future.

Also, to avoid confusion: dify-sandbox is the runtime for code snippets (for example, Code nodes and Jinja templates), not the agent runtime itself.

[kuangmi-bit]

@wylswz Appreciate the clarification — that's an important distinction.

You're right: dify-sandbox handles code execution (Code nodes, Jinja), while the agent runtime (dify-agent-runtime) is where agent-level security boundaries live.

The good news is the implementation is a portable http.RoundTripper — the same InjectionHandler + DomainRule + providers.yaml pattern ports directly to dify-agent-runtime without architectural changes. The three invariants (destination validation, fixed allowlist, response stripping) and all six conformance fixtures remain identical — only the mount point changes.

I'll adapt the PR to target dify-agent-runtime instead. Same design, right layer. Thanks for the pointer.