Zero Static Secrets: The Ephemeral Key Lease Broker Architecture for AI Agents

There is an uncomfortable truth that many enterprise security teams attempt to ignore: working with secrets is mandatory if you want autonomous AI agents to produce meaningful work.

A coding agent that cannot invoke an LLM inference API cannot think. An agent that cannot connect to an ephemeral Postgres testbench cannot verify database migrations. An agent that cannot interact with a staging object store cannot write integration tests for file uploads. If you completely strip an agent of all credentials and network connectivity, you do not have an autonomous software engineer—you have a glorified markdown generator.

To achieve real velocity, agents must be empowered to run builds, invoke models, deploy testbenches, and verify their work end-to-end. But that necessity creates a high-stakes engineering challenge: how do you give an agent the credentials it needs right now, without leaving your company vulnerable to total compromise if something goes wrong?

Look across the software industry today and you will find two dominant camps when it comes to AI agents and security. Both are fundamentally broken.

The Pragmatic Third Way: Acknowledge that the sci-fi fears are fantasy, but the mundane, operational security risks are very real. You do not lock down the machine until no work can happen; instead, you build a least-privilege, ephemeral lease boundary that provides exactly what the agent needs for 60 minutes and nothing more.

When an engineering team suffers a credential leak from an AI workflow, it almost never involves a self-aware AI breaking out of a hypervisor. It happens through mundane, predictable developer hygiene oversights. Here are the three primary vectors that actually destroy businesses:

Before discussing how leases work, we must establish a non-negotiable boundary: what an AI agent should never have access to under any circumstances.

Leasing is not a mechanism for giving an AI agent the keys to your production customer database, your primary Stripe secret keys, or your company's DNS registrar. Those are crown jewels. Autonomous coding agents belong in development and testing environments, interacting only with disposable, isolated infrastructure.

Instead of waiting for agent frameworks to magically solve secret distribution, engineering teams can solve the secrets paradox today with an out-of-band ephemeral key lease broker pattern. This is the exact operational pattern we use internally: instead of embedding static keys in local configuration, machines operate with zero ambient credentials. When an agent session requires model inference or compute provisioning, it requests a lease through an authenticated local loopback service.

The Four Architectural Pillars

1. Strict Loopback-Only Ingress (127.0.0.1): The broker daemon and its approval interface listen strictly on the host loopback interface (e.g. 127.0.0.1:8765) or a protected Unix domain socket. It never exposes an HTTP port to the public Internet or local LAN. Application-layer authentication is not a substitute for loopback binding.
2. Attended Human Approval for Elevated Targets: When a remote machine or autonomous run asks for access, the operator reviews the exact task scope: Session ID, Target, Duration, and Stated Purpose. The operator clicks approve on their primary workstation. The agent cannot self-approve its own leases.
3. Cloud IAM Conditional Policy Bindings (AWS, GCP, Azure, Cloudflare): Upon approval, the broker does not generate an unmanaged static API key. Instead, it activates a time-bounded condition in your cloud provider: Google Cloud IAM (CEL expression request.time < timestamp("2026-09-24T06:04:40Z")), AWS STS (DurationSeconds or aws:CurrentTime condition), Azure Entra ID role assignment conditions, or Cloudflare Workers KV TTLs. The cloud provider's own infrastructure enforces the hard cutoff.
4. In-Memory Token Retrieval (Zero Disk Residuals): The agent client retrieves the access token directly into process memory via standard output or Unix socket. No .env file is written. No static credential file is persisted. When the process terminates, the token vanishes from memory.

Here is a concrete reference implementation blueprint and operational pattern—modeled on our internal development setup—that you can deploy to lease model keys and compute access across development hosts and agent sandboxes.

1. The Client Lease Request Script (Reference: `agent-key-lease.sh`)

This lightweight bash client runs in the agent's environment, polling the loopback broker and fetching short-lived tokens directly into environment variables without writing to disk:

#!/usr/bin/env bash
set -euo pipefail

BROKER_CLIENT="${AGENT_LEASE_CLIENT:-./scripts/agent-key-lease.sh}"
ACTION="${1:-status}"

case "$ACTION" in
  status)
    $BROKER_CLIENT status --json | jq .
    ;;
  request)
    TARGET="${2:-frontier-models}"
    MINUTES="${3:-60}"
    PURPOSE="${4:-Routine task execution}"

    echo "Requesting lease for target: $TARGET ($MINUTES minutes)..."
    RESP=$($BROKER_CLIENT request --target "$TARGET" --minutes "$MINUTES" --purpose "$PURPOSE" --json)

    LEASE_ID=$(echo "$RESP" | jq -r .lease_id)
    echo "Lease created: $LEASE_ID. Awaiting human operator approval on workstation dashboard..."

    # Poll until approved or rejected
    while true; do
      STATE=$($BROKER_CLIENT check --lease-id "$LEASE_ID" --json | jq -r .status)
      if [ "$STATE" = "approved" ]; then
        echo "Lease approved! Conditional IAM policy active."
        break
      elif [ "$STATE" = "rejected" ] || [ "$STATE" = "expired" ]; then
        echo "Lease $STATE. Exiting." >&2
        exit 1
      fi
      sleep 3
    done
    ;;
  fetch-token)
    TARGET="${2:-frontier-models}"
    # Retrieve short-lived bearer token into process stdout only
    $BROKER_CLIENT fetch-token --target "$TARGET"
    ;;
  *)
    echo "Usage: $0 {status|request|fetch-token}" >&2
    exit 1
    ;;
esac

2. Hardened Systemd Unit for the Loopback Broker (Reference: `agent-key-broker.service`)

The lease broker runs as a restricted background daemon under systemd with strict OS-level sandboxing:

[Unit]
Description=Ephemeral Key Lease Broker for AI Agents
After=network.target

[Service]
Type=simple
User=agent-broker
Group=agent-broker
ExecStart=/usr/local/bin/agent-lease-broker --bind 127.0.0.1:8765 --iam-project cloud-access-control
Restart=on-failure
RestartSec=5s

# Defense-in-depth Linux Sandbox
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
NoNewPrivileges=true
ProtectKernelTunables=true
ProtectControlGroups=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
CapabilityBoundingSet=

[Install]
WantedBy=multi-user.target

Let us be completely honest about why so many engineering teams have terrible secret hygiene: configuring IAM policies, conditional role bindings, and service accounts is tedious, confusing, and annoying.

If an engineer has never wrestled with GCP Common Expression Language (CEL) conditions, AWS AssumeRole trust policies, or Azure RBAC conditions, the initial setup can feel overwhelming. It is infinitely easier to just run gcloud auth application-default login or aws configure on your laptop, paste a root API key into a .env file, and move on with your day.

The beauty of an automated lease broker pattern is that you only pay the setup tax once. You or your AI assistant configures the broker daemon and conditional IAM template once. From that moment forward, developers and AI agents simply run agent-key-lease.sh request and click approve. The friction disappears, while the security boundary remains airtight.

And for teams that want this capability out of the box without building custom brokers, native AI key and compute leasing is planned to be incorporated directly into Swarm in a future release.

Before running autonomous agent sessions on your development infrastructure, run this quick 5-point verification checklist to guarantee zero ambient credential exposure: