Skip to content

Agent-safe CLI execution needs secret-safe defaults

October 4, 2026 · Kishore Babu Gutta

Native CLIs are extremely useful.

They are also usually designed first for a human sitting at a terminal.

That assumption becomes important when the caller is automation or an AI agent.

While integrating provider-native command paths into Engineering Runtime, I found a class of failure worth treating as an architectural concern: sensitive values can cross execution boundaries through command arguments, process output or retained logs unless the runtime explicitly protects them.

The important lesson was not one command or one provider.

It was the boundary itself.

A CLI wrapper is not enough

A naive execution model looks like this:

Agent
  ↓
CLI command
  ↓
Provider

A governed execution model needs more:

Intent
  ↓
Admission
  ↓
Auth / Context
  ↓
Argument handling
  ↓
Command execution
  ↓
Sanitization
  ↓
Safe result
  ↓
Audit / Evidence

If sensitive material can appear before or after the command runs, sanitization cannot be treated as a presentation-layer convenience.

It is part of the execution contract.

What changed in the mental model

The Runtime should assume that any of these may contain sensitive values:

  • command arguments,
  • environment-derived values,
  • provider responses,
  • stdout and stderr,
  • structured result fields,
  • audit records,
  • diagnostic output.

The safe default is therefore:

A value does not become safe merely because a trusted CLI produced it.

Native tools remain valuable.

But an agent-facing runtime needs a defensive boundary around them.

Why this matters beyond one CLI

As more engineering systems become accessible to agents, the same pattern applies to cloud CLIs, source-control tools, cluster tooling and internal command surfaces.

The execution layer should provide common guarantees even when the provider transports differ.

That is one reason Engineering Runtime treats the Command Engine as one transport underneath a shared policy, authentication, sanitization and audit model.

This article intentionally describes the defensive design lesson rather than publishing reproduction details for exposing credentials.

The same problem appears in CI and Kubernetes

The local CLI case was only the first visible version of a broader agent-execution problem.

AI agents increasingly run inside CI jobs and Kubernetes workloads too. Those environments often receive provider credentials through different mechanisms, but the security question is the same:

Does the agent need possession of the reusable credential, or only authority to perform the admitted operation?

CI

A CI job may receive credentials through:

  • a workflow-scoped token;
  • a GitHub App installation token;
  • an injected environment secret;
  • a protected credential file prepared by the pipeline;
  • an external broker or secret manager.

For agent execution, these are not equivalent.

An environment secret has broad ambient visibility inside the job. A protected file can reduce accidental inheritance and logging exposure, while a GitHub App can reduce credential lifetime and scope. Where possible, the runtime should consume the strongest available source and keep the secret outside the agent-facing result and context.

A useful CI shape is:

CI identity / OIDC
      ↓
GitHub App or secret broker
      ↓
short-lived or externally prepared credential
      ↓
protected file / bounded runtime session
      ↓
Engineering Runtime
      ↓
admitted GitHub operation

A file is not proof of isolation. If the agent process can directly read it, the credential is still obtainable. The runtime should report that honestly.

Kubernetes

Kubernetes adds more delivery choices:

workload identity
      ↓
cloud IAM
      ↓
GSM / Secrets Manager / Key Vault / Vault
      ↓
direct brokered memory
        or
CSI / Vault Agent mounted file
        or
environment fallback
      ↓
Engineering Runtime

The secret manager is the source. Memory, file and environment are delivery mechanisms.

That distinction matters.

A GKE workload can use Workload Identity Federation to authenticate to Google Cloud without a long-lived Google key. If the workload then retrieves a GitHub token from Secret Manager, that downstream GitHub credential may be delivered directly to the executor or mounted as a protected file.

The same pattern applies to EKS and AKS with their native workload identities and secret stores.

The cross-surface goal

The security objective should therefore be consistent across local, CI and Kubernetes:

Agent expresses intent
        ↓
Runtime resolves and mediates authority
        ↓
Credential stays behind the strongest available boundary
        ↓
Provider operation executes
        ↓
Agent receives result + evidence, not credential material

The preferred direction is:

native / federated identity
        ↓
direct brokered retrieval
        ↓
protected file
        ↓
environment secret fallback

This is not a claim that every deployment achieves perfect isolation.

The stronger requirement is to measure the actual boundary:

  • can the agent obtain the secret from environment?
  • can it read the mounted file?
  • can it export a native CLI credential?
  • can it reach the broker or metadata endpoint directly?
  • can the admitted operation still succeed through the runtime?
  • does any credential material escape through output, logs, audit or agent context?

That is the direction behind the phrase:

Agent authority without credential possession, wherever the platform can support it.

The runtime should not replace Vault, Secret Manager, Key Vault, Kubernetes CSI drivers or CI secret systems. It should integrate with them and minimize how much credential material the reasoning process needs to see.