The Agent Had to Ask Permission. It Could Also Turn Permission Off.

A consent gate is supposed to be the boring, reliable part of an agent's design. Before the shell tool runs a command, it stops and asks. That is the whole idea. AWS's own Strands Agents Tools package shipped exactly that gate on its shell tool. It also shipped a parameter that could turn the gate off, and the parameter sat in the same place as everything else the model was allowed to fill in.

What CVE-2026-18733 actually is

Strands Agents Tools is AWS's open source package of pre built tools for the Strands Agents SDK, distributed on PyPI as strands-agents-tools and on GitHub as strands-agents/tools. One of its tools gives an agent a shell: the ability to execute operating system commands on whatever host the agent process runs on. Because that capability is dangerous by construction, the tool included a human consent gate, a step meant to require operator approval before a command actually executed.

The tool's input schema, the set of fields the model fills in when it calls the tool, also exposed a parameter named non_interactive. AWS's advisory, published as CVE-2026-18733 on 3 August 2026 in AWS security bulletin 2026-072-AWS, describes the failure precisely: crafted input, including indirect prompt injection carried in untrusted content the agent reads, could influence the model to set non_interactive to true. When that happened, the consent gate did not fire. The command executed. AWS's advisory states that arbitrary operating system commands could then run with whatever privileges were available to the agent process.

Versions of strands-agents-tools before 0.8.0 carried this. Version 0.8.0 addressed it. GitHub's own security advisory for the issue, GHSA-mqvc-p852-wf8x, which we read directly, corroborates the same affected and patched versions, records a CVSS 3.1 base score of 8.8, high severity, under CWE-1427, improper neutralization of input used for LLM prompting, and states the same exploit shape: an attacker able to inject crafted text into content the agent processes, such as a web page, a message or a file, without needing any credential of their own. The advisory records the reporter as yonib05, and the same reporter's name appears on every one of the four advisories this piece covers, which is itself informative: this is one researcher's systematic look at LLM controllable tool schemas across a package, not four unrelated discoveries.

The gate existed. The switch for the gate did not belong to the operator

It is worth being precise about what did and did not fail here, because the easy misreading is to file this next to ordinary prompt injection stories, and that undersells the structural point.

The shell tool was not missing a consent gate. It had one. An operator who configured the tool correctly got a real approval step standing between the model's proposed command and its execution, for the overwhelming majority of calls. What failed is narrower and, we think, more interesting: the field that decided whether that approval step ran at all was not reserved to the operator. It was part of the same input schema the model was already filling in on every call, alongside the command itself, the working directory and everything else the tool needed to do its job. A gate that is supposed to constrain an actor cannot survive being placed under that same actor's control, and the reason is not that the actor is malicious. It is that anything capable of influencing the model's output, whether the operator's own instruction or a hostile web page the agent happens to read, is now also capable of influencing whether the gate applies at all.

This is the distinction the question at the top of this piece is trying to isolate. A tool call routinely carries two different kinds of information. One kind is the action: the command to run, the URL to fetch, the record to write. The other kind determines the authority boundary of that action: whether a human has to sign off, which credential is permitted to reach which host, whose data the action is allowed to touch. Treating both kinds identically, as ordinary fields the model fills in because the schema asked it to, is the choice that turned a working consent gate into a gate the model itself held the key to.

Three more parameters that did the same kind of work

Strands Agents Tools carried three further vulnerabilities in 2026, each disclosed separately, each already patched, and each worth reading on its own terms rather than folded into the shell tool's story. Moona Intelligence is deliberately not claiming they are the same bug. They are not. What we are testing is whether they share a family resemblance: a parameter that set the authority boundary of an action sitting in the same LLM controllable schema as the action itself.

CVE-2026-15746, disclosed 15 July 2026 in AWS security bulletin 2026-056-AWS and corroborated by GitHub Security Advisory GHSA-ppcf-fpr3-x46v, concerns the elasticsearch_memory tool. Its input schema exposed connection parameters, including es_url, cloud_id and api_key, to the model. When a caller omitted api_key, the tool fell back to the operator's own environment credential and sent it to whichever host the model had specified. Because the destination host was itself model controlled, a crafted prompt could point that fallback credential at an attacker's server, disclosing it in the Authorization header. The GitHub advisory records this at CVSS 3.1 base score 6.5, moderate severity. Version 0.7.0 fixed it.

CVE-2026-18394, disclosed 31 July 2026 in AWS security bulletin 2026-069-AWS and corroborated by GitHub Security Advisory GHSA-qhw6-2h72-m84v, concerns the http_request tool. Operators could bind a credential to a set of approved hostnames using HTTP_REQUEST_TOKEN_CONFIG, an allowlist meant to keep that credential from ever reaching a host nobody had approved. The tool's schema also exposed a proxies parameter to the model. A crafted prompt could route the request through an attacker controlled proxy while the nominal destination still passed the hostname allowlist check, and the bound credential travelled to the proxy's first hop regardless. The GitHub advisory records this at CVSS 4.0 base score 6.9, moderate severity. Version 0.8.2 fixed it. This is a credential scope failure, not a human approval failure: the control the model got to reach past was an allowlist meant to bound where a credential could travel, and the fix, per the advisory, removed the LLM controllable proxy field and moved proxy configuration to operator set environment variables instead.

CVE-2026-19111, disclosed 6 August 2026 in AWS security bulletin 2026-077-AWS and corroborated by GitHub Security Advisory GHSA-mpxq-953j-42m4, concerns three memory tools at once: mongodb_memory, elasticsearch_memory and mem0_memory. Each used a namespace parameter as its sole tenant isolation key, and each exposed that same parameter to the model as an ordinary tool input. AWS's advisory states that a forged namespace could let an authenticated remote user read, modify or delete another tenant's stored memories, or inject false memories into a tenant's namespace that was not theirs. The GitHub advisory records CVSS 3.1 base score 8.1, high severity. Version 0.8.3 fixed it.

What the current source actually does, verified directly

Advisory text describes a vulnerability. It does not always describe the fix in enough detail to know whether the fix actually removed the authority defining field from the model's reach, or just validated it more carefully while leaving it in the schema. That distinction matters enough that this record went and read the current strands-agents-tools source directly, rather than inferring the remediation architecture from AWS's or GitHub's prose, and the four fixes turn out not to be identical.

The shell tool's current source no longer defines non_interactive as a parameter at all. It is gone from the function signature the model fills in. The value now comes exclusively from an environment variable, STRANDS_NON_INTERACTIVE, read at call time with os.environ.get, alongside a second environment variable, BYPASS_TOOL_CONSENT, that governs the consent prompt itself. Both are operator set, out of band, before the agent ever runs, and neither appears anywhere in the tool's LLM facing schema. This is the distinction this record has to be precise about: current Strands documentation still describes BYPASS_TOOL_CONSENT and STRANDS_NON_INTERACTIVE, and a reader skimming for those variable names could mistake their continued existence for the vulnerability persisting. It does not. What CVE-2026-18733 fixed was not the existence of a non interactive mode. It was where the switch for that mode lived. An operator setting an environment variable before deployment is a different actor, at a different point in time, than a model filling in a tool call in response to content it just read, and the fixed version keeps those two firmly apart in a way the vulnerable version did not.

The memory tools' fix for CVE-2026-19111 takes a related but distinct shape, and it answers a question the original advisory language did not fully settle: not merely tighter checks on a supplied namespace, but the removal of namespace, and the credentials alongside it, from the model's reach entirely. The current mem0_memory and elasticsearch_memory tools are built around a class a developer instantiates once, at construction, with user_id, agent_id, cloud_id, api_key and namespace passed in as constructor arguments and stored as private instance attributes. Elasticsearch_memory's own docstring is explicit about why: credentials and the tenant namespace, it states, are securely managed by the class and not exposed to agents. The tool schema the model actually fills in in the class based pattern carries only content, query, memory_id and similar action fields, none of them tenant or connection scoped. Each tool's standalone function variant, kept for callers who are not using the class, reads the same values from environment variables, MEM0_USER_ID, MEM0_AGENT_ID, ELASTICSEARCH_CLOUD_ID, ELASTICSEARCH_API_KEY, and again exposes none of them as a schema field. Namespace, in the patched design, is not supplied out of band by the caller on each request. It is pinned once, at construction or in environment configuration, by whoever is deploying the tool, and the model has no field through which to override it.

The http_request fix for CVE-2026-18394 removes proxies from the schema outright rather than restricting it. The tool's current docstring states the reasoning in terms close enough to this record's own that they are worth quoting rather than paraphrasing: proxies, it says, are configured by the operator at process level, through the standard HTTP_PROXY, HTTPS_PROXY and NO_PROXY environment variables, or by setting session.proxies in code, and are intentionally not part of the LLM controllable tool input, because an attacker influenced model could otherwise route a credentialed request through an actor controlled proxy, bypassing the HTTP_REQUEST_TOKEN_CONFIG hostname allowlist. That is, as far as this record can tell, AWS's own engineers describing the exact failure mode CVE-2026-18394 exploited, in the tool's own source comments, as the reason the field was removed.

Read together, the pattern across all four fixes is not tighter validation of a field the model still supplies. It is relocation: the authority defining value moves out of the schema entirely, into an environment variable an operator sets before the agent runs or a constructor argument a developer supplies when the tool is built. AWS's own advisory language for CVE-2026-15746 and CVE-2026-18394 also recommends, as a precaution, that operators rotate the ELASTICSEARCH_API_KEY and any credential configured through HTTP_REQUEST_TOKEN_CONFIG on an affected version, explicitly even absent evidence either credential was actually exposed. That is a narrower, more concrete step than a general call to patch, and this record treats it as evidence AWS itself judged the exposure risk, in those two cases, as extending to the credential's confidentiality going forward, not only to the immediate request that carried it.

Does the pattern actually hold across all four

We want to be honest about where this argument is strong and where it is doing more work than the evidence supports.

It holds cleanly for the shell tool and the memory namespace case. In both, the parameter in question was not incidental to the action. It was the thing that determined who or what was allowed to authorize the action, in the shell tool's case, or whose resources the action could touch, in the memory tools' case. Treating either as an ordinary field the model fills in because the schema asked it to is the exact mechanism of the failure.

It holds with a little more qualification for the two credential cases. The api_key fallback and the proxies parameter are not approval mechanisms. Nobody was skipping a human's sign off in either one. What they share with the other two is that a field determining the effective security boundary of the call, which host a credential could legitimately reach, sat in the same schema as the destination the model was choosing for an entirely different reason. Moona Intelligence's term for that shared property, authority defining parameter, is our own analytical language, not AWS's. AWS's advisories describe each of these four as a distinct incorrect authorization or credential disclosure issue in its own right, and none of AWS's four advisories uses language that groups them together. We think the grouping survives independent reading of the primary sources. We do not think it would survive being stretched further than these four cases, and we are not extending it to every vulnerability that happens to share the strands-agents-tools package.

What this does not establish

Four patched CVEs are not four incidents. We found no evidence, in AWS's advisories, in GitHub's advisories, or in our own search of public reporting, that any of these four vulnerabilities was exploited against a real deployment. Nothing here is a report of a production breach. It is a report of a design pattern AWS identified, disclosed and fixed, apparently through one external researcher's sustained look at the package rather than an internal audit that AWS's advisories credit to itself.

Nor is any of this present in the package as currently released. We read strands-agents-tools' PyPI listing directly: the latest version at the time of this piece is 0.8.6, several releases past every one of the four patches described above. The same listing carries its own caveat, worth quoting rather than summarizing, because it is current package context and not evidence about any specific vulnerability: "The tools in this repository are experimental. Many of them grant agents powerful capabilities, executing code, accessing the file system, calling AWS APIs, connecting to external servers, and automating browsers and desktops, which carry real security implications," and it recommends that "any production use should be preceded by your own independent security review." That is AWS's own standing description of the package today. It is not a comment on CVE-2026-18733 specifically, and we are not treating it as one.

Two adjacent AWS findings that do not belong in this cluster

Reading the four Strands Agents Tools advisories turned up two other AWS security bulletins from the same window that touch related ground. Both are worth naming precisely, and neither belongs folded into the four vulnerability cluster this record's thesis rests on.

CVE-2026-18830, published 4 August 2026 as AWS security bulletin 2026-073-AWS, concerns Amazon Bedrock AgentCore's InvokeHarness API, a managed service entirely separate from the open source strands-agents-tools package. AWS's advisory, read through corroborating reporting after this session's direct network access to aws.amazon.com was blocked, describes a request whose most recent message already contained a tool use content block: the agent event loop could dispatch the named configured tool directly, without the model ever being invoked, skipping whatever security controls sit between a model's decision and a tool's execution. AWS assigned this a CVSS 4.0 score of 8.6 and states the fix is server side input validation, applied automatically to the managed API, that rejects a caller supplied tool use block in the final message before it reaches the agent event loop. This is a related failure, not the same one. In every one of the four Strands Agents Tools vulnerabilities, the model was the actor whose output an attacker steered, through a prompt, into a field that determined an action's authority boundary. In CVE-2026-18830, the caller crossed a boundary the model was supposed to sit behind entirely, by handing the system a representation of a tool call the system trusted without ever asking the model to produce one. Moona Intelligence treats that as a different point of failure in the same execution pipeline, worth distinguishing precisely rather than treating as one more instance of the authority defining parameter pattern, because collapsing the two would blur exactly the distinction this record exists to keep sharp: who supplied the input that mattered, the model or the party sending the request to the model's harness.

CVE-2026-18954, published 5 August 2026 as AWS security bulletin, concerns a third and again separate package, the Amazon AWS Labs DocumentDB MCP Server, read directly from GitHub Security Advisory GHSA-j694-4m5j-w8hc. Its aggregate tool checked for ordinary write operations, insert, update, delete, when a server was configured in read only mode, but did not validate aggregation pipeline stages for write capability. A client could submit a pipeline containing $out or $merge, both of which write to the database, and the server's read only mode did not catch it. AWS assigned this CVSS 3.1 6.5, patched it in version 1.0.12, and documented a workaround worth quoting exactly: configure the MCP server with database credentials for a genuinely read only database user, one without write privileges at the database level, because that enforces read only access regardless of the MCP server's own mode setting. This is not an authority defining parameter sitting in an LLM controllable schema; read only mode here was, as far as this record could verify, an operator configured setting, not a model supplied one. What failed was that the server's own enforcement logic did not recognize every path to a write, and AWS's own workaround corroborates a different, adjacent principle this desk has tracked separately: authority is more reliably enforced at the resource itself, where a database level permission cannot be argued around by an application layer bug, than at an upstream layer's representation of what mode it believes itself to be in. Moona Intelligence records this as corroborating evidence for that separate principle, not as a fifth instance of the pattern this record is about.

Where this sits against what we have already argued

Moona Intelligence has covered two adjacent arguments already, and CVE-2026-18733 is evidence for a claim that sits next to both of them without being identical to either.

TrueFoundry's MCP Gateway put its approval decision at a network boundary an individual agent builder cannot skip, and the argument there was about where the approval control lives: inside a per agent configuration that a builder can forget, or at a shared boundary the agent's traffic has to pass through regardless. CVE-2026-18733 is not that story. The Strands Agents Tools consent gate was not missing and it was not left to a builder's discretion to configure. It existed, by default, inside the tool itself. What failed was a level below where TrueFoundry's argument operates: even a gate that exists and runs by default is not a boundary if the actor it constrains can supply the input that decides whether it fires.

The broader claim that instructions are not authority, and that authority has to be evaluated independently of the model at the moment of execution, is the family this piece belongs to, but CVE-2026-18733 sharpens it rather than restating it. That earlier piece is about whether a system prompt, an instruction, can be trusted to hold a boundary. This piece is about something that happens one layer downstream of the prompt: even a control implemented in code, not in a prompt, running by default rather than by configuration, still fails if the specific field that determines its applicability is exposed as an ordinary input the model is allowed to set. The fix AWS shipped in 0.8.0 makes the point concrete: non_interactive stopped being something the model's tool call could set at all.

GitHub's approve-workflow-run safe output raised the question of who is authorized to give an approval once approving becomes an executable operation, and answered it by keeping the approval decision behind a deterministic handler the agent cannot influence, even though the agent can request the approval. CVE-2026-18733 shows what the same question looks like when the answer goes the other way: the field that decided whether approval was required at all sat inside the same schema the requesting party filled out.

The Authority Provenance ledger

Authority grantor. Documented at the operator level for every one of the four vulnerabilities, and worth stating precisely because the vulnerable design made it easy to blur. The operator, the person or team deploying strands-agents-tools, is the one who configures which tools an agent has, sets ELASTICSEARCH_API_KEY, HTTP_REQUEST_TOKEN_CONFIG, BYPASS_TOOL_CONSENT and the memory tools' construction time arguments. The model is not the grantor of any of these authorities, in either the vulnerable or the patched version. What the vulnerability let happen was narrower and more specific: a field the operator was supposed to control, not a field the model was supposed to control, sat inside the same schema the model was already filling in, so the model's output, itself steerable by attacker supplied content, could set a value only the operator's configuration should have set. That is a control failure that let the model's output reach an operator's field. It does not make the model the grantor of the authority that field defined.

Mandate or basis. Undocumented, in every one of the four cases, and this record is not aware of any AWS or GitHub material that speaks to it. AWS's advisories establish what a tool is technically configured to do and what an operator's environment variable or constructor argument controls. None of the four advisories, nor the package's own documentation, addresses why the operator who configured the shell tool's consent gate, the Elasticsearch credential, the HTTP proxy allowlist or a tenant's memory namespace held organizational standing to grant an agent that capability in the first place, on whose behalf, or under what internal authorization. Possessing the credentials and the deployment access to configure a tool is not evidence of a mandate to do so; this record treats that as an open question the advisories were never written to answer, not as one the technical fix resolves.

Delegated scope. Distinct for each of the four, and collapsing them into one generic permission would lose exactly what makes the cluster instructive. The shell tool's delegated scope is the ability to execute operating system commands on the agent's host; the consent gate was intended to constrain when that scope could actually be exercised, not to define the scope itself. The memory tools' delegated scope is read and write access to a tenant's stored memories; namespace was intended to constrain which tenant's memories a given call could reach, not the memory operations available. The elasticsearch_memory credential's delegated scope is whatever the ELASTICSEARCH_API_KEY itself grants inside the operator's Elasticsearch deployment; the destination host was intended to constrain where that credential could be sent, not what it could do once it arrived. The http_request tool's delegated scope is issuing HTTP requests bearing a bound token; the hostname allowlist was intended to constrain which destinations were permitted to receive that token, and the proxies parameter cut across that constraint by changing the request's path rather than its declared destination.

Explicit limits. Six distinct limits sit across the four vulnerabilities and the two adjacent findings, and each failed, or held, on its own terms rather than as one interchangeable control. Approval requirement: the shell tool's consent gate, undermined because non_interactive was model reachable. Credential destination: the elasticsearch_memory fallback credential's intended host restriction, undermined because the destination host itself was model chosen. Tenant identity: the memory tools' namespace boundary, undermined because namespace was an ordinary model suppliable field. Connection target: the http_request hostname allowlist, undermined not by the allowlist failing its own check, but by a second, model controlled parameter, proxies, changing where the request actually travelled after the allowlist had already approved the nominal destination. Configured tool set: AgentCore's InvokeHarness, where the limit was which tools a harness exposed at all, undermined not by the model but by a caller supplied representation that reached the event loop without the model being invoked. Read only state: the DocumentDB MCP Server's mode flag, undermined by the server's own enforcement logic failing to recognize every operation capable of writing, independent of who controlled any input parameter.

Inherited permissions or assumptions. AWS's own advisory for CVE-2026-18733 states plainly that a bypassed consent gate lets a command execute with the privileges available to the agent process. That is the ambient authority the vulnerability actually exposed: not new privileges granted to an attacker, but the full range of what the agent process itself could already do, reachable without the approval step meant to gate it. The credential vulnerabilities are narrower in what this record can confirm they exposed. CVE-2026-15746 and CVE-2026-18394 expose one specific operator credential, an Elasticsearch API key or a token bound through HTTP_REQUEST_TOKEN_CONFIG, to a destination the model chose; nothing in AWS's advisories or in this record's own reading establishes that either vulnerability handed a model broader infrastructure access than that one credential's own scope. CVE-2026-19111's namespace failure is narrower still in the same direction: it is a tenant isolation failure inside the memory tool's own data model, and this record found no claim, from AWS or elsewhere, that it also exposed the underlying storage backend's own administrative credentials or reached beyond what the memory tool itself was built to store.

Revocation or modification path. What exists, across all four cases, is a version upgrade: 0.7.0, 0.8.0, 0.8.2 and 0.8.3 each close the specific vulnerable path, and AWS's advisories for the two credential cases add a recommendation, stated as a precaution independent of confirmed exposure, that operators rotate the ELASTICSEARCH_API_KEY and any HTTP_REQUEST_TOKEN_CONFIG credential. That is real, and it is more than many software vulnerabilities carry. It is not a per delegation revocation mechanism. Nothing in the four advisories describes a way to revoke or invalidate one specific agent's access to the shell tool, one specific credential's binding, or one specific tenant's namespace grant, independent of upgrading the whole package. This record records that finer grained mechanism as undocumented rather than assuming the version bump substitutes for it.

Challenge authority. Undocumented in every case this record reviewed. The shell tool's consent gate, even in its patched form, is an execution approval mechanism: a human is asked before a command runs. It is not a channel through which a resource owner, a tenant whose namespace was reached, an auditor or a second reviewer can dispute or invalidate a specific already made authority decision after the fact. No material this record read, from AWS, from GitHub or from the package's own documentation, describes such a channel for any of the four vulnerabilities, and this record does not infer one from the existence of the approval step itself.

Recovery path. Undocumented beyond what patching and rotation already cover, and worth stating plainly: those two things are forward looking. A patch closes a vulnerable path for future calls. Credential rotation invalidates a credential going forward. Neither reverses a command that already executed with the agent process's privileges while a version before 0.8.0 was deployed, restores a memory that was already read, modified, deleted or had a false memory injected into it while a version before 0.8.3 was deployed, or un-sends a credential that already reached an attacker's host while a version before 0.7.0 or 0.8.2 was deployed. This record found no source describing a reversal, compensation or restoration process for any of the four, and keeps recovery undocumented rather than assuming the fix covers it.

Provenance evidence quality. Uneven, and worth separating by question rather than blending into one confidence level. What a tool is technically configured to do, and what its patched schema now excludes from model control: well documented, independently confirmed against the current source rather than inferred from advisory prose. Who is documented as entitled to configure these tools, in an organizational rather than a technical sense: undocumented, for all four. What happened when each vulnerability was exploited, in the sense AWS and GitHub describe the mechanism: well documented, corroborated across AWS's own bulletin summaries and GitHub's advisories. Whether any of the four was exploited against a real deployment: this record found no evidence either way, and treats that as an open question rather than either an admission or a clearance. Whether a challenge or recovery mechanism exists for a decision already made or an action already executed: undocumented, for all four. The strongest evidence in this cluster is technical: what the schema exposed, and what the patched schema removed. The weakest is organizational: who was entitled to configure the exposure in the first place, and what happens after a boundary the schema failed to hold has already been crossed.

The question worth carrying forward

Every one of these four advisories reduces to a version of the same question a schema designer has to answer honestly, tool by tool, field by field: when a tool call contains both the action and the information that determines the action's authority boundary, whether that is a human sign off, a credential's permitted destination, or whose data the call can touch, which of those fields is the agent actually allowed to choose? AWS's own fixes answer that question the same way each time: move the authority defining field out of the model's reach, into operator configuration, an environment variable, or a value the deterministic layer sets rather than the value the schema asks the model to fill in. That is not a new idea. It is the same idea this desk has tracked in gateway architecture and in approval workflow design, applied here at the level of a single tool's own input schema, and confirmed by four vulnerabilities that existed, in one AWS package, for exactly as long as it took someone to notice they had not applied it.