← Back to Blog
Architecture

Secure Isolation: How Credentials Stay Protected

A critical security requirement for ADLC is simple: agent containers must never hold raw credentials. Not GitHub tokens, not API keys, not database passwords. This article explains how the egress proxy pattern achieves this without sacrificing functionality.

The Threat Model

When you run an AI agent in a container, the code running inside that container can read environment variables, access files, and exfiltrate secrets to external services. If a model generates malicious code or if an injection attack succeeds, raw credentials become an immediate liability.

ADLC solves this by ensuring credentials never reach the agent container in the first place.

The Egress Proxy Pattern

Instead of giving the agent direct access to GitHub, Linear, or your cloud infrastructure, we run a lightweight egress proxy sidecar co-located with the agent container.

Agent Container Egress Proxy Sidecar Upstream Services ┌─────────────┐ ┌──────────────┐ ┌──────────────┐ │ Planner │──POST──→│ Proxy │──auth──→ │ GitHub API │ │ (no creds) │ /repos │ (has token) │ └──────────────┘ │ │ │ │ │ Coder │ │ Injects real │ ┌──────────────┐ │ (no creds) │ │ credentials │──auth──→ │ Linear API │ │ │ │ │ └──────────────┘ └─────────────┘ └──────────────┘

The agent makes requests to http://localhost:8080 with a sentinel token—a placeholder that proves the request came from an approved container. The proxy:

  1. Verifies the sentinel token matches the container's identity.
  2. Strips the sentinel token from the request.
  3. Injects the real credential (GitHub token, API key, etc.).
  4. Forwards the authenticated request to the upstream service.
  5. Returns the response to the agent.

From the agent's perspective, it just makes normal HTTP calls. From the upstream service's perspective, it received a properly authenticated request. The real credential never touched the agent container.

How Credentials Are Stored

Credentials are managed in a secure, centralized location:

  • Managed credentials: Platform-provided keys for shared services (like a GitHub App) are mounted on the egress proxy at startup as read-only files or environment variables, separate from agent containers.
  • Customer credentials: Organization-specific API keys are stored encrypted in a per-organization vault using Cloud KMS envelope encryption. The egress proxy queries the vault on a per-request basis and never caches the key in memory longer than needed.
  • No agent access: Agents cannot query the vault or read the egress proxy configuration. They only know the loopback address and the sentinel token they were issued.

Per-Request Isolation

Each agent task gets a unique sentinel token with an expiration time. If a token is compromised:

  • It only works for a limited window (minutes to hours).
  • It only authenticates requests from that specific task's container.
  • It can be revoked immediately if an issue is detected.

This means a compromised token cannot be used to access other tasks' work or to create persistent backdoors.

Audit and Compliance

Every credential use is logged by the egress proxy:

  • Which agent task requested authentication.
  • Which service was accessed (GitHub, Linear, etc.).
  • The timestamp and outcome of the request.
  • The HTTP method and resource path (for security review).

This audit trail is essential for compliance audits and for investigating unusual activity. If a task behaves unexpectedly, you can trace every authenticated request it made.

Deployment Considerations

ADLC is typically deployed as multi-container workloads where both the agent and the proxy run in the same network namespace:

  • Cloud Run: Multi-container deployments with shared loopback networking. The proxy and agent communicate over localhost.
  • Kubernetes: Sidecar pattern where both containers share a Pod. Network policies prevent external access to the proxy.
  • Local development: The same proxy runs locally so development workflows are identical to production.

What This Enables

By isolating credentials, ADLC enables:

  • Safe model experimentation: Test new models or vendors without exposing credentials to third-party inference services.
  • Reduced secret sprawl: No need to create service accounts for each agent instance. One set of credentials, safely injected.
  • Confident delegation: Teams can run agents in cloud infrastructure without worrying that a compromised model will exfiltrate secrets.
  • Compliance alignment: Meet requirements like "no secrets in containers" and "all credential access audited."

Read the full brief: ADLC Brief
Back to blog: All posts