rip allow-env env-var escape out of execverb/awsgate #144

New issue

Closed

opened 2026-06-15 19:03:04 +00:00 by coilysiren · 0 comments

coilysiren commented

2026-06-15 19:03:04 +00:00

Owner

What

Remove the allow-env env-var escape from the execverb/awsgate surface entirely.

allow-env let a guard be bypassed by setting an env var (e.g. WARD_AWS_ALLOW_SENSITIVE_READ=1). It was a crutch for the old blunt funnel gate, and it is foreign to the design: not AWS-native (neither IAM nor the CLI has "set an env var to bypass"), global and stateful (export once, every sensitive read passes silently for the session), and invisible at the call site.

Precise per-operation when/deny-when guards don't need it: you name the exact resource to block, so legitimate calls already pass and there is nothing to "escape."

Removed

execverb.WhenClause.AllowEnv field + the allow-env qualifier in when/deny-when (now an unknown node, fails closed)
execverb.GateSpec.AllowEnv field + the allow-env node in gate { ... }
awsgate.Gate.AllowEnv field + its env check in allowed() (allow globs remain the only escape)
escapeHint helper, env-escape error-message text, tests, and docs

API break (v0.x, expected): consumers using these fields drop them. The shipped ward-aws guardfile already uses no env var.

## What Remove the `allow-env` env-var escape from the execverb/awsgate surface entirely. `allow-env` let a guard be bypassed by setting an env var (e.g. `WARD_AWS_ALLOW_SENSITIVE_READ=1`). It was a crutch for the old blunt funnel gate, and it is foreign to the design: not AWS-native (neither IAM nor the CLI has "set an env var to bypass"), global and stateful (export once, every sensitive read passes silently for the session), and invisible at the call site. Precise per-operation `when`/`deny-when` guards don't need it: you name the exact resource to block, so legitimate calls already pass and there is nothing to "escape." ## Removed - `execverb.WhenClause.AllowEnv` field + the `allow-env` qualifier in `when`/`deny-when` (now an unknown node, fails closed) - `execverb.GateSpec.AllowEnv` field + the `allow-env` node in `gate { ... }` - `awsgate.Gate.AllowEnv` field + its env check in `allowed()` (allow globs remain the only escape) - `escapeHint` helper, env-escape error-message text, tests, and docs API break (v0.x, expected): consumers using these fields drop them. The shipped ward-aws guardfile already uses no env var.

coilysiren referenced this issue from a commit

2026-06-15 19:03:25 +00:00

refactor(execverb)!: rip out the allow-env env-var escape

coilysiren closed this issue

2026-06-15 19:03:25 +00:00