---
title: "Your Agent Can Run printenv (and Your Runtime Can't Stop It)"
description: "Work-Bench's Agent Runtime framing is solid - but 'Constrain = IAM' doesn't cover subprocess trees and env var leaks. Execution-Layer Security fills that gap."
doc_version: "1"
last_updated: "2026-03-02"
date: 2026-03-02
tags: [AI, Agents, Security, AgentSH, Execution Layer Security, Runtime, IAM, Environment Variables]
canonical: "https://eran.sandler.co.il/post/2026-03-02-your-agent-can-run-printenv/"
---

## Sitemap

- [Home](https://eran.sandler.co.il/)


![Tool calls are the postcard. Process trees are the trip.](/img/tool-call-subprocess-hydra.png)

[Work-Bench's post](https://www.work-bench.com/post/the-rise-of-the-agent-runtime) is one of the clearer attempts to name what's happening: a new "agent runtime" layer built to **execute, constrain, observe, and improve** agent work at scale.

I mostly agree with that framing. Where I think it stops short is *inside* their "Constrain" pillar.

They explicitly define "Constrain" as "two things: identity and permissions." That's correct - but incomplete once you accept the premise of agents: they execute arbitrary code, spawn subprocess trees, and interact with the OS in ways that don't map cleanly to "API permission checks."

The missing piece is what [AgentSH](https://www.agentsh.org) calls **Execution-Layer Security (ELS)**: enforcement where intent becomes side effects. ELS is the lens I use - and what we're building with [AgentSH](https://www.agentsh.org) at [Canyon Road](https://www.canyonroad.ai). Not as a replacement for identity, permissions, or containers, but as the layer that governs what happens *inside* them.

## What Work-Bench gets right

**Execute needs isolation.** The [post](https://www.work-bench.com/post/the-rise-of-the-agent-runtime) is clear that agents are nondeterministic and execute untrusted code determined at runtime. That's why sandboxes and isolated environments show up as a core runtime primitive.

**Constrain needs identity.** Their identity argument is solid: if every action is logged under the initiating human, accountability and audit trails collapse, and incident reconstruction becomes a mess.

**Constrain needs permissions.** They go deep on why fine-grained authorization matters and why RBAC alone is often ill-suited for agents.

So far, yes.

## "Isn't IAM already 'what can an identity do'?"

Yes. IAM absolutely answers "what can this identity do," *when the action is mediated by an IAM-aware system* (cloud APIs, SaaS APIs, internal services).

The gap is that a lot of what agents do is **OS-mediated**, not IAM-mediated:

* reading local files, configs, and mounted credentials
* spawning processes and letting them do work
* opening outbound sockets
* dumping secrets via environment variables

[Work-Bench](https://www.work-bench.com/post/the-rise-of-the-agent-runtime) is talking about constraining *agent authority across systems*. Containers limit the blast radius. ELS is about what happens *inside* the execution environment - constraining what the agent actually does at runtime.

IAM is policy at **service boundaries**. ELS is policy at the **OS boundary** - files, processes, network - including what happens inside subprocess trees.

You need all of these layers.

## Tool calls aren't the unit of control (and env vars make this worse)

Most agent systems model behavior as "tool calls" because it's legible. But the machine executes **process trees**.

One "install deps" or "run tests" can fan out into postinstall hooks, scripts, and child processes the agent framework doesn't really "see." [AgentSH](https://www.agentsh.org) calls this out as "subprocess blind spots." Containers help with isolation, but they don't automatically give you fine-grained policy on what a process does once it's running. The agent is *supposed* to be inside the container, running `npm install` or `python -c` with a forty-line inline script. The question is what those commands do once they're running.

Now add the most common secret delivery mechanism in modern infra: **environment variables**. Env vars are the default secret transport for CI, build tools, and cloud SDKs, which means they're often present even in "sandboxed" agent runs.

Secret exposure through environment variables, `.env` files, and mounted credentials is one of the attack vectors [AgentSH](https://www.agentsh.org) protects against. And env vars are *trivially exfiltrated*:

* run `env` / `printenv`
* read `.env`
* print process environment and ship it out over the network

That entire class of behavior often happens "under" your nice IAM story.

## What Execution-Layer Security (ELS) is, precisely

ELS is all about intercepting the action before it happens - where the model meets the real world. Instead of relying on prompts, tool descriptions, or alignment, [AgentSH](https://www.agentsh.org) intercepts the actual system calls - file I/O, network connections, process spawning, signals - and enforces policy at the syscall boundary.

**Deterministic enforcement at execution time, even when the agent is nondeterministic.**

## How AgentSH "adds ELS" (concretely, including env vars)

Here's how this works for env vars in [AgentSH](https://www.agentsh.org):

1. Env dumping is an explicit policy target - an example rule blocks `env` and `printenv`.
2. `.env` is treated as a first-class sensitive artifact - an example policy denies `**/.env*`, and deleting `/project/.env` requires approval.

The point isn't that `env` and `printenv` are the only leak paths - it's that ELS gives you an execution-time control plane to prevent common leaks and constrain exfiltration (file reads + outbound connects), even when the leak is indirect.

The broader pattern: don't try to "teach" the agent not to leak secrets - enforce at the point where the leak becomes an OS action (read, exec, connect). That's the core philosophy behind what we're building at [Canyon Road](https://www.canyonroad.ai): enforcement over persuasion.

## Re-reading Work-Bench's pillars with ELS in mind

[Work-Bench's four pillars](https://www.work-bench.com/post/the-rise-of-the-agent-runtime) still hold. ELS just tightens what "constrain" means in practice:

* **Execute:** sandboxes reduce blast radius; ELS governs what happens inside them when code gets weird.
* **Constrain:** IAM constrains service access; [ELS](https://www.agentsh.org/docs/) constrains OS side effects (files/network/process/env dumping) at runtime.
* **Observe:** tool logs show what the framework thinks happened; [execution-layer events](https://www.agentsh.org/docs/) show what the OS actually did.
* **Improve:** policy decisions + attempted side effects become clean signals for evals and hardening.

## The quick checklist I use (now with env vars explicitly)

If a runtime says it can "constrain agents," I look for:

1. Can you enforce file policy by path (including secrets like `.env`)?
2. Can you restrict outbound connects by destination?
3. Does enforcement follow subprocess trees?
4. Can you gate destructive operations with approvals?
5. Do you have an explicit story for **environment variables** (preventing trivial dumps like `env` / `printenv`, and preventing accidental exposure in workflows)?

This is the checklist [AgentSH](https://www.agentsh.org) is designed around.

## Bottom line

[Work-Bench](https://www.work-bench.com/post/the-rise-of-the-agent-runtime) is right that "agent runtime" is a real infrastructure layer and that identity + permissions are foundational.

My critique is that "Constrain = IAM" doesn't fully cover what happens once the agent is executing code - especially around subprocess trees and secret exposure via env vars and `.env` files. You still need identity. You still need permissions. Containers still limit your blast radius. But none of those layers govern what happens inside a chained bash command, an embedded Python script, or an `npm install` postinstall hook. That's where enforcement at the execution boundary comes in. ELS is that layer.