A per-context command allowlist can be bypassed with `--use-context` (no way to lock an agent to its context)

Start by tracing how the CLI parses --use-context and --config-file, selects the current context, and enforces commands.allowed; the issue does not name specific files or tests. Compare the parsed-argument path with the bypass examples, then check what existing test coverage exercises context selection and policy enforcement. Done means context switching and config-file overrides are rejected before requests when a lock is enabled, with a structured error.

Summary

A context's commands.allowed list only applies while that context is active. Any caller can switch to another context in the same config file by passing --use-context <name>, or can point at a different file with --config-file. A context with no allowlist has no restrictions, so switching to it removes the restrictions.

So the allowlist can't restrict an agent that is allowed to run elastic. A config file commonly holds both a restricted agent context and an unrestricted admin context (the pattern that --save-as admin produces). An agent that runs elastic --use-context=admin ... gets full admin access, and the CLI gives no indication that it left the restricted context.

Why this matters for agents

The typical setup for letting an AI agent use the CLI is:

• Layer 1 (Elasticsearch): give the agent context a read-only API key.
• Layer 2 (CLI): attach a commands.allowed list to the agent context and make it the current context.
• Layer 3 (agent harness): allow the agent to run only elastic ..., and add deny rules for --use-context and --config-file.

Layer 3 is there only to stop the agent from escaping layer 2. But harness deny rules match the command's text, and the CLI accepts many spellings of the same flag. Using Claude Code with --allowedTools "Bash(elastic *)" and --disallowedTools "Bash(elastic * --use-context *)" "Bash(elastic * --config-file *)":

Command the agent runs	Harness result	CLI result
elastic <cmd> --use-context admin	denied	n/a
elastic <cmd> --use-context=admin	allowed	runs as admin
elastic --use-context admin <cmd>	allowed	runs as admin
elastic --config-file=/other.yml <cmd>	allowed	runs against the other file
elastic <cmd> --use-cont''ext=admin (shell quote-splitting)	allowed	runs as admin

Wider patterns such as Bash(elastic *--use-context*) catch the first three but not the quote-splitting form. No text pattern can cover every way a shell can spell a flag. The CLI has the parsed arguments, so it is the only layer that can enforce this reliably.

How the quote-splitting row was checked: Claude Code's permission check allowed elastic status --json --use-cont''ext=nope under the wider deny pattern. The original pattern can't match it either, because it needs the literal text --use-context with spaces on both sides. And the CLI answered Context "nope" not found, so it had parsed the flag as --use-context. Against the reproduction config below, the same form switches to admin (see the last two commands under "Actual result"). In later runs where the target context was admin, the model itself declined to run the obfuscated command, saying it looked like an attempt to evade a deny rule. That refusal is the model's judgement, not an enforced control, so a prompt-injected or differently configured agent can't be relied on to make it.

Steps to reproduce

No cluster is needed. The unreachable URL shows whether the request got past the allowlist: command_blocked means the allowlist stopped it, and connection_error means the CLI tried to send it.

1. Create repro.yml:

   current_context: agent
   contexts:
     agent:
       elasticsearch:
         url: http://127.0.0.1:9
         auth:
           api_key: read-only-key
       commands:
         allowed:
           - status
           - stack.es.search
     admin:
       elasticsearch:
         url: http://127.0.0.1:9
         auth:
           api_key: admin-key
   

2. Run:

   chmod 600 repro.yml
   export ELASTIC_CLI_CONFIG_FILE=$PWD/repro.yml
   
   elastic es indices delete --index products --yes --json
   elastic es indices delete --index products --yes --json --use-context admin
   elastic es indices delete --index products --yes --json --use-context=admin
   elastic --use-context admin es indices delete --index products --yes --json
   elastic status --json --use-cont''ext=admin
   elastic es indices delete --index products --yes --json --use-cont''ext=admin
   

Actual result

$ elastic es indices delete --index products --yes --json
{"error":{"code":"command_blocked","message":"command \"stack.es.indices.delete\" is not allowed by the current policy"}}

$ elastic es indices delete --index products --yes --json --use-context admin
{"error":{"code":"connection_error","message":"fetch failed"}}

$ elastic es indices delete --index products --yes --json --use-context=admin
{"error":{"code":"connection_error","message":"fetch failed"}}

$ elastic --use-context admin es indices delete --index products --yes --json
{"error":{"code":"connection_error","message":"fetch failed"}}

$ elastic status --json --use-cont''ext=admin
{"context":"admin","services":{"elasticsearch":{"ok":false,"url":"http://127.0.0.1:9","error":"network error: fetch failed"}}}

$ elastic es indices delete --index products --yes --json --use-cont''ext=admin
{"error":{"code":"connection_error","message":"fetch failed"}}

The first call is blocked as expected. All the others get past the allowlist: the CLI tries to send the delete as admin (the status call confirms that the active context is admin), and against a real cluster it would succeed. --config-file=<other file> behaves the same way.

Expected result

A config file should be able to lock callers to the current context, so that the allowlist can't be escaped from the command line. With the lock on, every --use-context / --config-file call above should fail with command_blocked (or a similar structured error) before any request is sent.

Possible approaches

Any of these would solve it. The first is probably the simplest:

1. Context lock in the config file. For example, a root-level or per-context setting like allow_context_override: false. When the current context sets it, the CLI rejects --use-context and --config-file (in any spelling) with a structured error.
2. The allowlist covers context switching. Treat switching contexts as a command that the current context's commands.allowed must permit. With no entry, you can't leave the context.
3. A lock environment variable. For example, ELASTIC_CLI_LOCKED_CONTEXT=agent, set by whatever launches the agent. The CLI then refuses to run as any other context. This also covers ELASTIC_CLI_CONFIG_FILE being overridden inside the agent's shell, as long as the harness doesn't let the agent change its environment.

Workarounds considered

• Root-level commands.allowed: a context's list replaces the root list, and the root list would also restrict admin, which the operator needs.
• Separate config files for admin and agent: the agent can still use --config-file=<admin file> if it can guess or find the path.
• Harness deny rules: they match text, so they can be bypassed (see the table above).

Environment

• Elastic CLI: 0.5.0 (elastic version --json)
• Node.js: v22.22.3
• OS: Linux 7.0.0
• Agent harness used for the bypass table: Claude Code 2.1.284