CVE-2026-115415: Strands Agent Secret-Masking Bypass

CVE-2026-115415 is a concrete example of a tool-boundary failure in an AI agent application. The affected component is the environment tool in the open-source Python package strands-agents-tools. In affected versions, a masking option accepted through the tool schema could be set by the model. Content processed by an agent could therefore prompt a tool call that turns off secret masking and returns environment variables in cleartext, including cloud credentials and API keys. Official advisory.

The AWS security bulletin says the issue is fixed in strands-agents-tools 0.8.6. It also says masking is now controlled only by the operator and that the environment tool is deprecated. AWS recommends rotating credentials that were present in environments of agents that loaded the affected tool. Those are the core actions: identify the package, upgrade, review exposure, and rotate potentially disclosed secrets.

This is not a statement that every Strands agent, Amazon Bedrock deployment, or AWS account is compromised. Exposure depends on whether an application used the affected package and tool, whether the tool was available to an agent, and what credentials existed in that process environment. The advisory does not describe this as a remote-code-execution flaw. Avoid compressing a specific tool configuration defect into a claim about all AI agents or all AWS infrastructure.

The trust boundary that failed

An agent can receive untrusted content, reason over it, and call tools. A tool schema describes arguments the model may provide; it should not grant the model authority over security policy. In this case, the environment tool exposed a masking parameter to the model. A crafted prompt in content the agent was asked to process could instruct the model to call the tool with masking disabled. The result was a response containing environment variables without operator consent, according to the AWS security bulletin.

The distinction between model intent and application authority is important. The model may propose a tool call, but the host application decides which tools exist, which arguments are accepted, what permissions the tool has, and what output is returned. A security-sensitive control belongs to the operator or application policy, not to untrusted text interpreted by the model.

En Strands Agents Tools advisory y CVE record identify the package-level issue. For general context, OWASP’s LLM application risk project and its prompt-injection risk description explain why untrusted content can influence model behavior. They are general references, not evidence about this vulnerability’s exact implementation.

A careful exposure assessment

Start by finding every runtime that imports strands-agents-tools, including local development, CI jobs, containers, notebooks, managed agent services, and production workers. A dependency declaration may be indirect or pinned only in a lock file. Search build manifests, lock files, image metadata, software bills of materials, and the package inventory used by the deployment platform. Record the exact version and image digest. A repository updated to 0.8.6 does not fix a container that has not been rebuilt and redeployed.

Next, establish whether the application exposes the environment tool to an agent. Confirm which agent definitions and tool registries include it, whether the environment was present during processing, and which secrets were accessible to that process. Environment variables are often used for credentials because they are convenient, but their existence does not mean the agent necessarily accessed or disclosed each value. Scope the response to actual runtime environments and evidence.

Treat as potentially exposed the credentials that were present in environments of agent processes that loaded the affected tool, as AWS recommends. This does not mean that every credential in a cloud organization must automatically be rotated. Inventory by workload and privilege, prioritize active and high-impact secrets, and rotate or revoke them through the service owner. If a credential is long-lived, disable or replace it. If the environment used short-lived role credentials, revoke active sessions where supported and allow the credential lifecycle to expire under the relevant controls.

AWS documents IAM security best practices y Secrets Manager rotation. These help plan credential hygiene but do not replace the affected-package upgrade. Use the secret’s own provider and policy to decide how rotation affects dependent workloads.

Upgrade and verify the fix

Actualizar strands-agents-tools to 0.8.6 or a later fixed release, then rebuild and redeploy every affected runtime. If the project carries a fork or derivative package, compare its environment-tool implementation with the upstream fix and apply the same security boundary: the model must not control whether secrets are masked. The upstream release information is available from the Strands Agents Tools repository and its 0.8.6 release page.

The AWS bulletin says the environment tool is deprecated as of the fixed release. Review whether the application still needs the tool at all. Remove unused tools from registries and reduce tool access to the minimum required. If a workflow legitimately needs environment inspection, provide a narrowly scoped, operator-controlled function that returns only approved values, rather than an unrestricted process environment.

After deployment, verify the installed version from the running artifact and test the policy with synthetic values. A useful test uses a fake variable such as TEST_SECRET=not-a-real-credential. The test input can request that masking be disabled, but the host-side test should assert that only the operator configuration determines redaction. It should also check that tool outputs, traces, exception messages, telemetry, and downstream model context do not contain the synthetic value in cleartext. Never put a real production secret in a prompt or test fixture.

A safe local validation pattern

The following pseudocode demonstrates a policy invariant. It is not an exploit and does not read the process environment:

def render_tool_output(value: str, *, operator_masks: bool, model_requested_masking: bool) -> str:
    # Security policy comes from the host, not from model-provided arguments.
    if operator_masks:
        return "[REDACTED]"
    return value

assert render_tool_output("TEST_SECRET", operator_masks=True,
                          model_requested_masking=False) == "[REDACTED]"

The security property is that changing the model-supplied argument cannot override the host’s policy. In an actual application, use the package’s documented API and the fixed version; do not assume this illustrative function matches Strands internals. Keep test values synthetic and run the test only in an isolated development or CI environment.

Review agent traces and secret sinks

The issue is a disclosure risk, so investigate where agent outputs can travel. Review tool-call records, model traces, application responses, debugging logs, observability pipelines, support exports, and any downstream action that receives tool output. A trace may preserve the prompt and the tool result even if the end-user interface masks it. Conversely, the absence of a visible value in one log does not prove that no other output channel received it.

If evidence indicates a potentially exposed secret, preserve the relevant telemetry before changing retention settings. Limit access to trace stores, redact or remove sensitive values in accordance with the incident process, and search for use of the affected credentials after the suspected exposure window. Cloud audit records can help identify credential activity, but absence of an event is not universal proof that no secret was viewed or copied.

Utilice la MITRE CWE-200 description as a general vocabulary for sensitive-information exposure. For agent design, maintain a clear separation between untrusted input, model-generated proposals, host-enforced policy, and tool output. A model can help select an operation; it should not be the only gate controlling access to secrets.

Controls for agent builders

• Keep policy outside the prompt. Do not accept authorization, redaction, or network-boundary decisions from model-generated arguments.
• Minimize tool scope. Register only tools the task requires. Prefer tools that expose a specific operation over general-purpose access to a host environment.
• Minimize secrets in the process. Use short-lived credentials and least-privilege roles. Do not pass secrets into agent context unless necessary.
• Treat tool output as sensitive. Apply redaction before output enters a model trace, user-facing response, or telemetry system.
• Test with adversarial content safely. Use synthetic secrets and controlled fixtures; do not probe third-party agents or production tenants without authorization.
• Version and rebuild. Pin dependencies, check transitive packages, and verify the deployed artifact rather than only the source manifest.

OWASP’s LLM security guidance provides a broader framework for prompt injection and insecure output handling. AWS’s Secrets Manager documentation explains managed secret storage. These controls complement the package update; none makes an affected version safe to continue running.

Model, tool, and host responsibilities

An agent system is not one security principal. It combines content sources, a model, an orchestration layer, tools, credentials, and destinations for results. Each component has a different responsibility. The model can interpret an instruction and propose an action. The orchestrator can validate the proposal. The tool executes within a host environment. The identity provider grants credentials to that host. Logging and tracing systems preserve some inputs and outputs. A control that is correct in only one layer can be defeated by data flowing through another.

For this issue, write down a data-flow diagram for the affected workflow. Mark where untrusted documents, web pages, tickets, source files, or user prompts enter. Mark when the agent can call the environment tool, what data that tool can read, and where its return value can go. Include the model context, end-user response, tool audit log, application log, telemetry pipeline, and any external integrations. The diagram should describe the actual deployed workflow, not a generic agent architecture.

Then assign an owner to each security decision. The host application should determine whether a tool is available. A policy layer should determine which operations are permitted. The tool should constrain what data it can access. A redaction layer should decide which values may leave the host. The model may make task-specific choices inside those boundaries, but must not be the sole authority that removes a protection. This principle applies beyond masking: model-generated arguments should not set an unrestricted filesystem root, disable domain allowlists, change authorization modes, or override tenant boundaries.

Prompt injection is difficult to eliminate through instruction text alone because the model processes both trusted and untrusted content in the same reasoning context. Keep the security boundary in code and policy. Treat documents as data, constrain available tools, validate arguments against schemas, and require explicit user or operator approval for sensitive side effects. For this CVE, however, do not imply that all prompt-injection defenses are equivalent to patching the vulnerable package. Upgrade the tool and rotate potentially exposed credentials first.

Credential exposure triage

Credential review is easiest when the organization has an inventory connecting a secret to the workload that receives it. For each agent environment, identify the variable name, secret provider, owning team, privilege scope, rotation method, and systems that depend on it. Avoid exporting secret values into the incident worksheet. A value-free inventory can still answer whether a credential was present and what permissions it had.

Prioritize credentials by ability to cause harm and by evidence of exposure. A cloud role with write access to production data, a long-lived deployment key, and a low-privilege test token should not be handled identically. Consider whether the agent’s tool output could reach an external user, a shared trace system, or an integration that stores the conversation. Review access to those systems and the retention window. If the secret’s scope is uncertain, ask the identity or service owner before assuming it is harmless.

When rotating, plan the dependency change. Create the replacement credential through the provider’s approved process, update the workload’s secret reference, deploy and validate the new identity, then revoke the old credential. For assumed roles, identify whether sessions are still active and whether the role trust relationship needs adjustment. Monitor for authentication failures caused by old tokens and for unexpected use of either identity. Record the time of issuance and revocation so responders can interpret later audit events.

Preserve affected agent traces before applying cleanup, but treat them as sensitive. Restrict access while determining whether they contain secret values. If they do, coordinate with the data owner to redact or remove copies under retention policy, while retaining the minimum evidence required for incident handling. Avoid mass deletion before legal, privacy, and security owners agree on evidence preservation.

Deployment and regression checklist

An upgrade can be considered complete only when the resolved dependency and runtime image agree. Add a build-time check that fails when an affected version is present. Generate or update an SBOM for the artifact, sign or attest the build according to the organization’s release process, and compare the deployed digest to the approved artifact. Include developer workstations and CI agents if they ran the vulnerable tool with credentials that matter.

The regression test should exercise the policy boundary rather than rely on a happy-path conversation. Use a synthetic value with a recognizable marker. Send untrusted content that requests the model to disable redaction. The test should verify that the tool’s host-side policy remains unchanged and that the synthetic value is masked or absent in all approved output channels. Include tests for tool errors and retries; exception paths sometimes expose arguments or environment details even when the normal return is redacted.

If the application no longer needs environment inspection, remove the tool and add a test that the tool is absent from the registered tool set. If it needs a limited environment value, expose a narrow getter that returns only the named non-secret field after validating the request. Do not allow the model to enumerate all variables. Keep the allowlist in operator-managed configuration and review changes as security-sensitive code.

Test upgrades against the same packaging path used in production. For a containerized application, rebuild from the lock file and verify the installed distribution inside the image. For a virtual environment, inspect the resolved package in the deployed artifact. For a fork, review the source diff and add a regression test that proves the model cannot change masking policy. A package version number alone may not describe a local fork or vendor-patched build.

Longer-term agent design review

This CVE is a useful trigger for reviewing tool authority across an agent fleet. Create a registry of tools with owner, purpose, allowed data, allowed side effects, authentication context, deployment versions, and logging behavior. Flag tools that can read process environments, files, shell output, cloud metadata, secret stores, or production records. The inventory should not assume a tool is safe because its name sounds read-only; its implementation and return values determine the actual boundary.

Apply least privilege at both the cloud identity and tool layers. A role with narrow permissions reduces the impact of an exposed credential, while a narrow tool reduces the data a model can request. These are complementary controls. Keep credentials out of agent context whenever possible; when a tool must use a secret, let the tool call the provider internally and return a result that does not include the credential.

Separate development, test, and production agent identities. A prompt-injection evaluation should never run with a production administrator token. Use synthetic datasets and fake credentials in red-team exercises. Keep exercise results and traces in a restricted environment because even a test can reveal configuration names, internal URLs, or real secrets if the harness is misconfigured.

Finally, define approval gates for actions that alter external state. Human review is not a substitute for sound tool design, but it is useful for high-impact operations such as deleting data, issuing transactions, changing access policies, or sending messages. Approval should be bound to a clear action summary and a stable target, not to a vague prompt. The model’s explanation of why an action is safe should not be the evidence that it is authorized.

Model a realistic agent data flow

An operator should be able to answer four questions for each affected workload: what untrusted content can the agent process, which tools are registered, what host data those tools can read, and where tool outputs are sent. A support assistant may ingest customer emails and retrieve ticket records. A code agent may inspect a repository and invoke development tools. A research agent may fetch pages and summarize them. The precise content differs, but each workflow can carry instructions that the application owner did not author.

Map the flow as a sequence, not only as a component list. Record content ingestion, normalization, context construction, model request, tool proposal, host validation, tool execution, output redaction, model continuation, and final response or downstream action. Mark the point where strands-agents-tools exposes the environment capability and where the masking setting was previously supplied. Mark which layer owns the fixed operator-controlled policy. If the workflow has retries, streaming responses, or secondary agents, include them; an output can reach a sink through a path that is not visible in the first response.

For each boundary, identify what is trusted and why. A system prompt may be controlled by the application team, but it does not make a web page or ticket trusted. A tool schema may be generated from code, but a model-provided argument remains untrusted input. A log pipeline may be managed by a trusted provider, but its readers and exports may be broader than the application runtime. This distinction helps avoid a common design error: treating instructions as the only defense while allowing untrusted content to choose a security-sensitive tool parameter.

The inventory should include environments where the tool was available but might not have been invoked. The absence of a recorded tool call can be meaningful only if the trace system is complete, immutable for the review period, and records failed and retried calls. If traces were sampled, expired, or disabled, state that limitation. Use dependency presence plus tool registration as a conservative exposure indicator, then refine with trustworthy runtime evidence.

Separate the secret classes and their owners

Environment variables do not all have equal sensitivity. Some contain non-secret feature flags or deployment names; others contain API keys, database credentials, signing material, access tokens, or internal URLs. The AWS advisory specifically calls out credentials and API keys among values that could be returned in cleartext. Build a value-free classification: record names or secret identifiers, owning service, privilege scope, lifetime, rotation procedure, and whether the variable was present in an affected agent environment. Do not copy the values themselves into the classification file.

Some credentials are injected by a platform at task start and expire automatically; others are long-lived static keys. Some are scoped to read-only access, while others can deploy or modify production resources. A rotation plan should reflect those differences. Revoke static keys promptly if exposure is credible. For short-lived role credentials, evaluate current session duration, role trust, and the provider’s revocation options. A short lifetime reduces a replay window but does not make a disclosed value harmless during that window.

Coordinate with service owners before revoking credentials that support critical workflows. A token used by a billing integration, deployment system, or customer notification pipeline may have downstream dependencies not visible to the agent team. Use a tracked change that identifies the replacement, deployment order, verification check, and old-credential revocation time. Confirm that no stale container or scheduled process continues to use the old identity.

If the same secret was reused across development and production, rotate it once and remove the reuse rather than merely distributing the replacement to the same broad set of environments. If the same cloud role serves multiple agents, consider whether those workloads need distinct identities. After immediate remediation, split identities so future exposure in a low-risk test agent does not automatically affect a production service.

Observability and evidence matrix

Use multiple sources to determine whether the vulnerable tool could have disclosed data and whether a credential was subsequently used. No one log source answers both questions. The matrix below is an investigation aid; availability depends on deployment configuration.

Evidence source	Question it can help answer	Important limitation
Dependency lock and SBOM	Was an affected package version part of the build?	Does not prove the tool was registered or the image was running.
Container image and deployment record	Which artifact ran and when?	Rollbacks, mutable tags, and emergency deployments can complicate history.
Agent tool registry	Could an agent call the environment tool?	A registry snapshot may differ from the runtime configuration.
Tool-call trace	Was the tool invoked and with what policy state?	Traces may be sampled, redacted, or retained for a limited period.
Application/model logs	Did cleartext appear in a response or trace?	A missing record is not proof if capture was incomplete.
Secret-provider audit	Were secrets accessed or rotated?	Secret reads may be mediated by a host role and may not show which process read them.
Cloud API audit	Was a credential used after the suspected exposure window?	Lack of events does not prove the value was never copied or tested elsewhere.
Endpoint/network telemetry	Did the agent communicate with an unexpected destination?	Encrypted traffic and shared egress make attribution difficult.

Preserve the configuration and evidence metadata before changing log retention. Record time ranges, clock sources, retention settings, sampling, redaction rules, and known gaps. If the system stores a raw model transcript, restrict it to the incident team because it may itself contain secrets or customer data. Use references and redacted excerpts in tickets rather than copying full transcripts.

When a tool call is observed, distinguish argument values from tool output and from the model’s final answer. The model may have requested a setting without receiving all environment values; the tool may have returned a masked subset; a downstream filter may have transformed it; or the agent may have stored it in a trace. Record each stage separately. Do not infer cleartext disclosure solely from the presence of an adversarial instruction in an input document.

A staged remediation runbook

Inventory and contain

Identify affected package versions in source, lock files, build artifacts, container images, CI environments, and running agents. Determine where the environment tool was registered. If it is not needed, remove it from the affected runtime as an immediate exposure reduction. Preserve dependency and deployment evidence before rebuilding. Restrict access to traces and logs that could contain variables, but do not destroy evidence needed for an investigation.

Upgrade and redeploy

Move to strands-agents-tools 0.8.6 or a later fixed version. Rebuild each artifact from the reviewed dependency lock, inspect the resolved version, and deploy through the organization’s normal release process. If code is forked, compare the fork to the upstream fixed code and document any differences. Verify that the runtime image digest matches the approved build and that old replicas have drained.

Rotate and monitor

Use the environment inventory to identify credentials that were present in agent processes that loaded the affected tool. Prioritize by privilege and exposure evidence. Rotate or revoke according to the credential owner’s process. Check relevant identity and cloud audit activity for the suspected window, while noting that not every local read creates a cloud-side event. Watch for continued use of old credentials, failures in dependent services, and unexpected actions by the replacement identity.

Verify and close

Run synthetic redaction tests through the real packaging path. Confirm the model cannot override the operator-controlled setting, the synthetic value is absent from all approved sinks, and the environment tool is no longer exposed if it is unnecessary. Record unresolved telemetry gaps, outstanding rotations, and owners. Close the immediate vulnerability ticket only after the fixed version is running and the credential assessment is documented; track broader agent-architecture changes separately so they do not delay remediation.

Risk-reduction patterns for agent applications

The first pattern is capability minimization. A broad environment inspection tool is more powerful than a function that returns one approved configuration value. If a task needs a deployment region, provide the region. If it needs a service status, provide the status. Do not expose unrelated credentials alongside that value. The best secret is one the model and its context never receive.

The second pattern is host-enforced policy. Masking, authorization, network access, filesystem roots, and approval requirements should be set by application configuration and validated before the tool runs. The model may express intent, but the host must check whether the proposed action is permitted. The policy owner should be explicit and protected by code review and change controls.

The third pattern is output minimization. Tool output should contain only information necessary for the next reasoning step. Redact sensitive values before they enter model context, traces, logs, or user responses. A second redaction layer is useful for defense in depth, but it should not be used to justify returning full secrets to the model. Treat errors, exceptions, debug output, and retries as output channels too.

The fourth pattern is credential isolation. Assign distinct identities to separate agents and tasks. Use short-lived credentials and narrowly scoped permissions. Keep development and production environments separate. Avoid mounting secret stores or host filesystems into a general-purpose agent when a dedicated brokered operation is sufficient.

The fifth pattern is auditable tool use. Record which agent, identity, tool, policy version, and approved target were involved in an operation. Avoid recording secret values. For high-impact actions, require approval bound to the exact action and target. Tool auditability helps answer what happened after a prompt-injection event, but logs themselves must be protected and reviewed for sensitive outputs.

Evaluation without unsafe production testing

An agent-security evaluation should test classes of input, not chase a single prompt string. Use an isolated harness with synthetic documents that contain conflicting instructions, requests to reveal a fake variable, and attempts to change tool arguments. The desired outcome is not that the model never notices the instruction; it is that the host policy remains enforced and sensitive data is not returned. This distinction makes the test stable across model versions and avoids treating refusal wording as the security boundary.

Test direct and indirect content sources separately. Direct user prompts may have a different trust level from retrieved documents or emails. Test HTML and plain text representations if the application ingests both, but keep the data benign and locally controlled. Include multi-turn conversations in which a later request refers to earlier content, and tests where the agent retries after a tool error. Do not use real secrets or live third-party services in the harness.

Measure concrete properties: whether an untrusted request can change masking configuration, whether environment enumeration is possible, whether secret-shaped synthetic values appear in tool output, whether outputs reach logs or model traces, whether unauthorized tools are available, and whether the fixed package is present. Store the test fixture version and runtime dependency version so regressions can be compared after upgrades.

Use a separate authorized assessment to test the broader application boundary. The evaluation should have a written scope, named owner, test tenant, time window, synthetic credentials, and stop conditions. Do not send adversarial prompts to another company’s production agent or use a public AI service to process secrets. If automated pentest tooling is used, constrain it to an owned target and verify that the tool cannot access unrelated cloud resources.

Build an agent exposure inventory

An inventory should answer operational questions without storing secret values. For each agent workload, record its owner, repository, runtime environment, package lock, deployed image digest, Strands tool version, registered tools, identity provider, and release cadence. Add whether the environment tool was enabled, what environment categories could be present, and which trace/log systems received tool output. Mark whether the deployment is production, staging, development, or a CI runner. This makes it possible to separate an affected package in a local test environment from a long-running production agent with privileged credentials.

Connect that record to a credential catalog. Use secret names or vault identifiers rather than values. Include the owning service, credential type, privilege scope, expiration behavior, rotation owner, and dependent applications. If the organization does not have this mapping today, start with the agent environments identified as affected and build a minimum inventory for them. Do not wait for a perfect enterprise-wide catalog before rotating a credential that is credibly exposed.

Record evidence quality. A deployed artifact digest is stronger evidence of the running package than a source manifest. A complete immutable tool trace is stronger evidence of whether the tool was called than an application log that records only final answers. A cloud identity audit can show credential use but may not show that a local process read a variable. Mark each evidence source as complete, sampled, expired, or unavailable. That allows incident owners to prioritize uncertainty instead of quietly treating missing logs as clean results.

A focused control test catalog

The core regression suite should cover the fixed package behavior and the surrounding application. Tests can be organized by control owner:

Test owner	Objetivo de la prueba	Safe test data
Dependency/build team	Reject affected package versions and stale artifacts	Lock file and build metadata
Agent orchestrator team	Ensure model arguments cannot override masking policy	Synthetic variable marker
Tool owner	Confirm outputs are minimized and environment access is removed or narrowed	Fake non-production values
Observability owner	Confirm redaction in traces, logs, retries, and error paths	Synthetic marker in generated events
Identity team	Confirm agent roles are scoped and credentials can be revoked	Dedicated test principal
Application owner	Confirm authorized workflows still function after upgrade	Isolated test tenant

The test should assert observable outcomes, not implementation internals alone. For example, a unit test can prove the host policy is used, while an integration test verifies the secret does not appear in model context or telemetry. Both are needed because a correct function can still be bypassed by a different output path.

Keep a small adversarial fixture library under version control. Each fixture should include its intended trust classification, expected security property, synthetic secrets, and owner. When the model or agent framework changes, run the same suite against the new build. If a fixture starts producing a different result, decide whether the changed behavior affects the security property; do not update expected output automatically without review.

Incident decisions and escalation

The incident lead should separate three questions: Was the affected component deployed? Could the tool have returned sensitive values? Is there evidence that a value was accessed or used? The first may be answered from dependency and deployment records. The second depends on tool registration, policy configuration, and runtime context. The third may require agent traces, local process information, log review, and cloud identity events. A “yes” to the first does not automatically imply “yes” to the third, but it does trigger patching and exposure assessment.

Escalate immediately when evidence shows a cleartext credential in an agent response, trace, shared log, or external destination; when a credential appears to have been used outside its expected workload; or when a privileged identity acted unexpectedly during the exposure window. Restrict access to the data, preserve relevant evidence, and rotate or revoke through the credential owner. If evidence is incomplete but a high-impact secret existed in an affected environment, use a risk-based rotation decision and document why.

Escalation does not always mean stopping the entire agent service. If the environment tool can be removed without affecting critical operations, disable it while the package is upgraded. If the service depends on the tool, constrain the workflow to approved non-secret values and apply a temporary operator-controlled policy. Any temporary exception should have an owner, expiration, and monitoring. Do not deploy an unreviewed patch that merely hides output while leaving the model in control of the security parameter.

Communicate that this is a package-level tool issue and identify the versions and workloads under review. Avoid saying AWS itself was breached or that all agent conversations were exposed. If a credential belongs to a customer or another business unit, follow the contractual and incident communication path rather than sending raw trace data to a broad channel.

Operational readiness after remediation

After the fixed build is deployed and credentials are assessed, keep an owner on the residual work. Confirm that trace stores with potential values have restricted access and an approved disposition. Check that the incident’s replacement credentials are live and old credentials are invalid. Verify that canary agents and scheduled jobs are on the fixed artifact. Make sure the old image cannot be selected by autoscaling, failover, or a rollback automation.

Update runbooks so future responders know how to disable or remove the environment tool, locate agent traces, inventory secret references without revealing their values, rebuild the package, and rotate the relevant identity. Add an alert or dependency policy for the affected version range. Review whether the broader tool registry contains other functions where a model-provided argument controls security enforcement. Keep that architecture review distinct from the urgent CVE remediation, but assign a date and owner so it is not lost.

When the response closes, preserve a concise timeline: affected package discovery, first confirmed runtime, tool-use evidence, package deployment, credential changes, telemetry review, and remaining limitations. Record what was not available, including expired traces or incomplete process telemetry. A later reviewer should be able to understand why the organization rotated some credentials, did not rotate others, or accepted a remaining risk without seeing the secret values themselves.

Distinguish a prompt attempt from a confirmed disclosure

An input that asks an agent to print secrets is evidence of an attempted influence, not proof that the tool returned them. Conversely, a user-facing answer that omits a secret does not prove the value never entered a tool response, model context, or trace. Track the sequence of events and the evidence for each stage. This avoids overstating an incident when an input was blocked, and avoids missing a disclosure that a later renderer masked.

Use precise terms in findings. “Untrusted content requested a masking change” describes an input. “The affected environment tool was invoked with masking disabled” describes a tool event. “The tool returned a synthetic or real variable in cleartext” describes an output. “The value was stored in a trace” describes persistence. “The credential authenticated to a service” describes subsequent use. Each claim needs its own evidence and confidence. A response can be urgent even when the final step is not known; patching and credential risk reduction do not require proof of successful abuse.

Review all transformations that occur between the tool and a reviewer. A UI may redact values for display while the database stores the original. A log shipper may truncate a long line, while a retry event stores the whole message. A support export may include a hidden field. A model may paraphrase or encode a value instead of printing it literally. Where evidence systems permit, test them with a fake marker and verify the stored, exported, and displayed versions. Do not use a real credential to test whether a filter works.

If traces have retention limits, determine the retention policy and access controls before searching. Searching raw logs can create copies in query history or incident exports. Use restricted roles and queries that return metadata or masked snippets. Do not paste a raw result into a public issue tracker, collaboration channel, or a model prompt. Store the minimum evidence necessary and reference it by a protected identifier.

Operator checklist

Fase	Acción	Completion evidence
Exposición	Find strands-agents-tools versions and all runtimes	Lock files, SBOM, image digest, deployment list
Tool scope	Find agents with the environment tool registered	Runtime tool registry or verified configuration
Secret scope	Identify credentials present without recording values	Secret identifiers, owners, permissions, lifetime
Containment	Remove an unnecessary tool and restrict sensitive traces	Change record and access-control check
Fix	Upgrade to 0.8.6 or later and rebuild/redeploy	Runtime version and artifact digest
Credential response	Rotate or revoke potentially exposed credentials	Rotation record and dependency health
Verificación	Test operator-only masking with synthetic values	Integration test across outputs and logs
Closure	Record evidence gaps and residual work	Incident timeline, owners, and deadlines

Do not mark the issue resolved when only the package manifest changed. The runtime deployment, credential assessment, and safe validation each address a different part of the risk. If the team cannot determine whether an old agent ran, record that uncertainty and use a risk-based credential decision rather than claiming no exposure.

What not to conclude

• “All Strands agents are compromised.” The advisory identifies a specific package and tool, not every Strands deployment.
• “Prompt injection alone exposed credentials.” The tool behavior and model-controlled masking parameter are part of the reported flaw; content supplies the influence path.
• “This is an AWS control-plane breach.” The affected component is an open-source tool package running in an agent environment.
• “A normal output filter is enough.” The fixed release changes control ownership; an external filter may be useful but should not substitute for upgrading.
• “Nothing was exposed because the model did not print it to the user.” Tool output may flow into traces or downstream systems.
• “Rotate every credential in the account without scoping.” Identify affected agent environments and credential scope, then rotate deliberately and verify dependencies.

Conclusión

CVE-2026-115415 is best understood as a host-policy failure at an AI tool boundary. Untrusted content can influence a model, but the decisive weakness was that the tool schema let the model control a security-sensitive masking option. A robust agent architecture expects that content may attempt to redirect the model and ensures that policy decisions remain outside model control. The fixed release moves the masking decision to the operator and deprecates the environment tool, which is why version verification matters more than a prompt-only defense.

For operators, the priority order is straightforward: identify the exact package and runtime, upgrade and redeploy, assess credentials that were present in affected environments, and validate with synthetic data across tool outputs and trace sinks. Do not assume all AWS or Strands deployments are affected, and do not assume that no risk exists because an agent never displayed a secret in its final answer. Exposure assessment should follow the data path and evidence quality.

For developers, remove broad environment access when a narrow operation will work. Keep secrets out of model context and logs, use least-privilege identities, test policy invariants rather than model wording, and make tool outputs auditable without recording sensitive values. These controls reduce the consequences of future prompt-injection attempts; they complement, but do not replace, the fixed release and credential response for this CVE.

The strongest closure record is one that states what was updated, which runtime artifacts were verified, which credentials were evaluated or rotated, what output channels were reviewed, and what evidence gaps remain. That gives platform owners a reproducible basis for resuming normal operations while keeping the scope of the incident honest.

PREGUNTAS FRECUENTES

• Which package is affected? strands-agents-tools, versions 0.1.0 through releases before 0.8.6, according to AWS.
• What is the fixed version? Version 0.8.6. Rebuild and redeploy the artifact that actually runs the agent.
• Is the flaw a prompt injection vulnerability? The advisory describes a masking control that the LLM could override; crafted content can influence the model to use that control. Prompt injection is the influence mechanism, while the unsafe tool-argument authority is the key implementation issue.
• Does it affect all AWS credentials? No. Risk is limited to credentials available in environments of agents that loaded the affected tool and potentially disclosed them.
• Should potentially exposed credentials be rotated? AWS recommends rotating credentials present in those agent environments. Scope rotation by workload and secret, and revoke sessions where appropriate.
• Is disabling the environment tool enough? Removing an unused tool reduces exposure, but upgrade affected packages and assess prior exposure as well.
• How can I test safely? Use synthetic values in an isolated test and verify operator-controlled masking across tool output and trace sinks.
• If the package was installed but the tool was not registered, is the workload affected? The described tool path may not have been available, but verify the running registry and deployed configuration rather than relying on the source manifest alone.
• Does a redacted user interface prove the trace is safe? No. Check the stored trace, exports, retries, and error paths with synthetic values; display masking and storage redaction are separate controls.
• Does credential rotation fix the package? No. Rotation addresses possible prior secret exposure. Upgrade the tool to the fixed version to close the vulnerable behavior.
• Is a model refusal a security control? No. The host should enforce the rule regardless of whether the model follows an instruction or refuses it.
• Can agent telemetry identify every disclosure? Not necessarily. Sampling, retention, redaction, and missing tool-call capture can limit conclusions; document those gaps.
• Should all environment variables be treated as secrets? Not every variable is secret, but many reveal internal configuration and some contain credentials. Classify values before sharing them with an agent and expose only what a task needs.
• Does the CVE establish that a particular deployment leaked credentials? No. It establishes a vulnerable behavior and potential disclosure path; deployment inventory and evidence determine the impact for a specific operator.

When an agent workflow is business-critical, remediation planning should include service continuity as well as security. Identify whether the environment tool supports a necessary task, whether a narrow replacement exists, and what safe fallback operators can use while the package is updated. Keep the temporary fallback read-only and narrowly scoped. Set an expiry date for any exception, and verify that the exception does not restore model control over masking or grant access to production secrets.

Referencias

• AWS Security Bulletin 2026-154
• GitHub Security Advisory GHSA-qjx4-hg6g-2f34
• CVE Record
• Registro NVD
• Strands Agents Tools repository
• Strands Agents Tools 0.8.6 release
• Strands Agents documentation
• OWASP LLM Top 10
• OWASP LLM01 Prompt Injection
• MITRE CWE-200
• AWS IAM best practices
• AWS Secrets Manager rotation
• AWS Secrets Manager overview