{"schema_version":"1.0","service":"Publicasta","type":"article","id":769,"slug":"aws_agentic_development_security_bulletins_october_2026","title":"AWS’s October security bulletins turn agentic development tools into an incident-response issue","excerpt":"AWS has disclosed serious flaws across Loom for AWS, its security-agent MCP server, SageMaker Unified Studio and Kiro. The practical lesson is not simply to install patches: teams need an inventory of agent tools, connected credentials, writable paths and recent cloud activity.","language":"en","default_language":"en","canonical_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=en","image":{"url":"https://publicasta.com/storage/projects/17/pages/769/2026/10/623b081b-3f35-486a-999f-b2a9e7cfbe8d.webp","alt":"Security operations workspace showing a laptop monitoring connections between an AI agent, tools, credentials, files and cloud infrastructure."},"publisher":{"id":17,"slug":"it_today_news","name":"IT Today","url":"https://publicasta.com/it_today_news"},"author":{"name":"Anton R"},"published_at":"2026-10-05T13:52:08+00:00","updated_at":"2026-10-05T13:52:08+00:00","content_markdown":"AWS’s latest security bulletins point to a change in the shape of developer-tool risk. The affected products are not all versions of the same platform, and the bugs do not share one technical root cause. They do share an operational pattern: an AI-assisted development or data environment can sit between a user’s prompt and credentials, files, internal network services, or cloud APIs. A flaw in that layer can therefore become a security event with a wider blast radius than a normal editor bug.\n\n ![Security operations workspace showing a laptop monitoring connections between an AI agent, tools, credentials, files and cloud infrastructure.](https://publicasta.com/storage/projects/17/pages/769/2026/10/623b081b-3f35-486a-999f-b2a9e7cfbe8d.webp)\n\n In the past few days AWS has published or updated important advisories for Loom for AWS, the open-source `security-agent-mcp-server`, SageMaker Distribution in SageMaker Unified Studio, and Kiro IDE. The disclosures cover authentication bypass, token disclosure, unsafe outbound requests, argument injection, command execution, and agentic writes into global configuration. AWS’s bulletins give different affected versions and different remediation paths, so a single blanket instruction such as “update your AWS tools” is not enough.\n\n The immediate response is still straightforward: identify whether any affected component is installed or deployed, move to the fixed release, restart services where AWS says the fix is delivered on restart, and rotate credentials when the advisory says they may have been exposed. The more important work is structural. Development teams need to treat agent tools as privileged software components and make their permissions, network reach, local write scope and audit trail visible to security operations.\n\n ## What AWS disclosed\n\n The newest bulletin in the group concerns CVE-2026-104019 in the startup process for SageMaker Spaces in SageMaker Unified Studio. AWS says the startup script validates network connections available in a project. Under certain conditions, insufficient sanitization of connection details could allow code execution in another project member’s Space. In projects using Trusted Identity Propagation, a contributor or higher could potentially obtain another member’s temporary execution-role credentials and call downstream services on that member’s behalf.\n\n AWS says the fix has been deployed globally and is applied when supported Spaces restart. The advisory lists fixed SageMaker Distribution versions including 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5 and 4.4.3. Several older minor lines have no fix because they are out of support. AWS’s recommendation is to restart Spaces running affected minor versions so they receive the patched image. There is no workaround listed. That makes the restart and version check an operational control, not a suggestion to postpone until the next maintenance window.\n\n The Loom for AWS bulletin is different and particularly relevant to teams experimenting with agent orchestration. Loom is described by AWS as an AWS Labs open-source platform for AI-agent orchestration. Three CVEs affect versions before 1.7.0. One authentication issue in versions before 1.6.1 could allow an unauthenticated network client to obtain administrative authority over the agent control plane when no identity provider was configured. AWS says that authority could include registering tool servers, reading stored integration credentials and rewriting IAM role policies attached to managed agent roles.\n\n A second issue in versions before 1.7.0 concerns OAuth2 discovery handling. AWS says an authenticated user with `mcp:write` or `a2a:write` scope could configure a discovery URL that caused the backend to send OAuth2 client secrets or another user’s access token to a third-party-controlled endpoint. The earlier 1.6.1 release blocked access to internal addresses but did not fully close the token-disclosure path. The third issue affected tool-server and remote-agent connections and could let an authenticated user direct requests to arbitrary internal network locations, including the container’s credential-vending endpoint.\n\n AWS’s resolution for Loom is version 1.7.0, with the separate authentication issue also addressed in 1.6.1. The bulletin explicitly calls for rotating OAuth2 client secrets, revoking and reissuing access tokens that were active during the affected window, and rotating IAM role session credentials if container credentials may have been accessed. This is the clearest example in the group of why a patch can be necessary but insufficient: once secrets may have crossed a trust boundary, remediation includes identity recovery.\n\n The `security-agent-mcp-server` issue is narrower in product scope but important because it concerns the boundary between a local AI assistant and the host filesystem. AWS describes the project as an open-source MCP server in the `awslabs/mcp` repository that assistants use to run local security scans, including differential scans. CVE-2026-97662 affected versions from 0.1.1 up to but not including 0.2.0. A crafted reference value supplied to the diff scan could be interpreted as a command-line option rather than a revision. AWS says the result could be creation, overwriting or truncation of arbitrary files outside the intended workspace, bypassing the server’s workspace-confinement control.\n\n AWS lists version 0.2.0 as the fix and says there is no workaround other than upgrading. Until then, its guidance is to run diff scans only against trusted repositories and use a least-privileged account in an isolated environment. That advice matters beyond this one package. A local agent that can invoke a scanner, compiler, package manager or deployment helper is a local automation system. A bug in argument handling can turn a carefully described workspace boundary into an assumption that the operating system does not enforce.\n\n Kiro IDE illustrates another version of the same problem. AWS’s bulletin for CVE-2026-95985 says Kiro versions before 1.0.242 could allow a remote unauthenticated actor to execute arbitrary commands and inject crafted instructions into the agent’s context when a user ran the agent in a crafted repository as an untrusted workspace. AWS says a user only needed to send a message for agent modifications to be made to automatically loaded global configuration paths.\n\n The fixed Kiro version is 1.0.242. AWS says there is no workaround, and asks users who ran the agent in an untrusted workspace on an earlier version to inspect the global Kiro configuration directory for entries they did not create. The listed paths are `~/.kiro` on macOS and Linux and `%USERPROFILE%\\.kiro` on Windows. The important operational detail is that a repository can be untrusted even when the person opening it is trusted. The trust decision is about the content that an agent parses and the tools it can invoke, not merely the identity of the developer at the keyboard.\n\n ## The common thread is not “AI is insecure”\n\n It would be easy to flatten these advisories into a warning about AI software. That would be too broad to guide a response. The useful common thread is privilege concentration. Each product combines ordinary software components with a capability that can cross a boundary: a local file writer, an MCP or A2A connector, an OAuth2 client, a temporary execution role, a startup script, or an agent context that influences later actions.\n\n Those boundaries are familiar to security teams. What changes with agentic tooling is the number of steps that can happen after the initial input. A repository can influence an agent’s context. The agent can call a tool. The tool can reach an internal endpoint or invoke a command. The command can read or alter files. A cloud service can then use temporary credentials to make API requests. The sequence is not necessarily an exploit chain in every deployment, but the architecture makes it possible for a small parsing or authorization mistake to have consequences outside the original application.\n\n That is why the right unit of review is not just the package or IDE. It is the package plus its execution identity, local filesystem scope, network egress, connected tools and cloud permissions. A team that upgrades Kiro but leaves every developer agent with administrator credentials has reduced one known defect while retaining a large uncontrolled blast radius. A team that patches Loom but does not rotate tokens after a possible disclosure has closed the code path without closing the incident.\n\n AWS’s own IAM guidance recommends temporary credentials for workloads, least-privilege permissions, regular review of unused permissions, conditions that narrow policies, and permissions guardrails across accounts. AWS also recommends using CloudTrail activity and IAM Access Analyzer to refine policies. Those are general controls, but these bulletins show where to apply them: at the identities and integrations used by agent tooling, not only at production services.\n\n ## Who should act first\n\n The first group is any team that deployed Loom for AWS beyond a developer’s loopback machine, especially if an identity provider was not configured before the application became reachable from a network. The second is any team that granted Loom administrative integration scopes such as `mcp:write` or `a2a:write` to more people than a small administrator group. The third is teams using Loom with OAuth2 integrations, remote agents, or tool servers that hold credentials.\n\n The next group is data and AI teams using SageMaker Unified Studio Spaces with Trusted Identity Propagation. The risk depends on project configuration and the distribution line, but the remediation is concrete: identify Spaces on affected versions, restart them after the patched images are available, and verify that older unsupported minor lines are not still in service. A restart should be tracked as a change with an owner and evidence, not assumed because the platform is managed.\n\n Developer-platform and application-security teams should check for the AWS `security-agent-mcp-server` in local tool manifests, editor integrations, CI helper images and shared development containers. The package may be installed under a name that is not obvious from an inventory of AWS services. Search the source repositories and developer bootstrap configuration that declare MCP servers, then map each installation to a version and execution account.\n\n Finally, endpoint-management teams should verify Kiro versions on developer workstations and managed virtual desktops. This is especially important where developers routinely open external repositories, issue trackers or generated code. A workstation review should include the global Kiro configuration directory if an affected version was used with an untrusted workspace. The purpose is not to inspect every file manually without context; it is to compare configuration history with known-good management baselines and investigate entries that appeared during the affected period.\n\n ## A practical response sequence\n\n ### 1. Build a capability inventory\n\n Start with capabilities, not vendor names. List every developer or data tool that can do one or more of the following: write outside the project directory, execute local commands, call MCP or A2A servers, access cloud credentials, resolve network addresses, create or modify IAM roles, or read integration secrets. Include IDE extensions, local daemons, shared containers, CI runners, notebook images and internal wrappers around open-source projects.\n\n For each item record the installed version, installation source, owner, host or container, identity used to access cloud resources, reachable networks, and the repositories or projects that can supply input. The inventory does not need to be a perfect asset database on day one. It needs enough fidelity to answer whether a named AWS advisory applies to a real installation and what other systems were reachable from it.\n\n ### 2. Patch according to the product’s actual boundary\n\n For Loom, upgrade to 1.7.0 and inspect forks or derivative code. AWS explicitly says derivatives need the fixes incorporated, so a repository that copied the upstream code is not covered merely because the upstream release is current. For the MCP server, upgrade to 0.2.0 and confirm that shared images and developer bootstrap scripts no longer install an older range. For Kiro, move to 1.0.242 or later and review global configuration when an affected version was used with an untrusted workspace.\n\n For SageMaker Unified Studio, identify the distribution minor line and restart affected Spaces so the globally deployed fix is applied. AWS’s version list matters because some old lines are unsupported rather than patched. A managed service can remove part of the patching burden, but it does not remove the need to confirm which runtime is actually being used or whether a Space has restarted.\n\n ### 3. Recover identity material when exposure is plausible\n\n Do not wait for proof that a token was used. AWS’s Loom advisory recommends rotating OAuth2 client secrets and revoking and reissuing active access tokens when the affected window could include them. If a container role credential may have been accessed, rotate the session credentials and review CloudTrail for unintended use. The exact sequence should follow the organization’s incident process and the identity provider’s capabilities.\n\n The principle is to separate code remediation from credential remediation. A fixed binary prevents a repeat of the known path. It does not invalidate a secret that may already have been copied. The same distinction applies to configuration files, developer tokens, CI credentials and temporary role sessions.\n\n ### 4. Review cloud activity around the exposure window\n\n CloudTrail records AWS API calls with information such as the calling identity, time, source IP address, request parameters and response elements. Use that record to establish whether the affected role or integration performed unusual actions during the period in which the vulnerable component was exposed. Pay attention to role assumptions, changes to IAM policies, creation of new access keys, changes to trust policies, access to secrets, unexpected data reads and activity from unfamiliar networks.\n\n The goal is not to search for one magic event name. Build a timeline from the vulnerable component, its identity and its connected services. A token-disclosure case may appear as access from an unexpected address. A role-policy rewrite may appear as an IAM change followed by access from a new principal. A compromised data-development Space may produce activity under a legitimate temporary role, which is why time, source and expected project activity must be considered together.\n\n ### 5. Reduce permissions before returning to normal\n\n Patch windows are a good time to remove permissions that were granted for experimentation and never reduced. Start by separating read-only discovery, code scanning, deployment, secret access and IAM administration into different roles. Use temporary credentials and short sessions where possible. Put powerful actions behind approval or a separate operator role rather than making them available to every agent-connected identity.\n\n AWS recommends least privilege and permissions guardrails. In practice, that means an agent should have only the API actions required for the task and only on the resources required for that task. A code scanner does not automatically need the authority to change IAM policies. A tool server that reads source code does not automatically need access to production secrets. A notebook contributor should not inherit another project member’s identity simply because a trusted propagation feature is enabled.\n\n This is also where network controls matter. Restrict outbound access from agent containers and development services to the destinations they need. Block access to credential-vending endpoints except through the supported mechanism. Keep local tools in isolated environments when they process untrusted repositories. Network isolation does not replace patching, but it can prevent a parser, connector or command wrapper from turning a local mistake into access to a broader environment.\n\n ## What not to conclude from the bulletins\n\n These disclosures do not prove that every agentic IDE or MCP server is compromised. They do show that security review must include ordinary software defects in the control plane around the agent. The risk is not determined by whether a product advertises AI. A non-AI plugin with command execution and cloud credentials can be just as sensitive. Conversely, an agent with no credentials, no network access and a read-only workspace has a different impact profile from an agent that can change deployment roles.\n\n They also do not justify banning open-source agent tooling as a category. AWS’s Loom and `security-agent-mcp-server` advisories show why teams need a way to track forks, pinned versions and local wrappers. Open source can make fixes visible and auditable, but it also means that a copied repository, internal patch or container image can continue carrying a vulnerability after upstream has released a fix. The control is version and provenance discipline, not a simplistic label.\n\n Finally, a vulnerability score alone cannot determine urgency. An authentication bypass in an internet-reachable control plane, an argument-injection issue on a developer workstation, and a code-execution issue inside a multi-user data environment may have very different likelihoods and consequences. The priority should reflect exposure, credentials, network reach, affected data and evidence from logs.\n\n ## The durable lesson for platform teams\n\n Agentic development is becoming a collection of small control planes: the IDE, the local tool server, the orchestration layer, the repository, the cloud workspace and the identity provider. Each component may look like a productivity feature when viewed alone. Together they form a path from untrusted input to privileged action. Security ownership cannot stop at the application team that installed the tool.\n\n The immediate AWS advisories offer a useful test for organizational maturity. Can the team answer which developers use Kiro, which repositories contain the MCP server, which Loom deployments are reachable, which SageMaker Spaces run affected distributions, and which roles those systems can assume? Can it rotate an integration secret without rebuilding an entire platform? Can it distinguish a normal temporary-role call from a suspicious one? If the answer is no, the missing control is not another AI policy document. It is an asset, identity and audit workflow for developer automation.\n\n For now, the sensible sequence is short: identify exposure, apply the vendor fixes, restart managed Spaces where required, rotate potentially exposed material, review CloudTrail, and narrow permissions before re-enabling broad access. AWS’s bulletins are about specific products and versions, but the operational message reaches further. When software can interpret a repository, call a tool and act under a cloud identity, its security patch belongs in the incident-response queue as well as the developer-upgrade queue.\n\n ### Sources and scope\n\n This article focuses on AWS’s security bulletins published between September 24 and October 2, 2026, with emphasis on the operational actions stated by AWS. It does not claim that exploitation occurred in any of the affected deployments. Technical exploit steps are intentionally omitted; teams should use the vendor advisories and their own incident procedures for investigation.\n\n The primary disclosures are [AWS Bulletin 2026-125 for CVE-2026-104019 in SageMaker Distribution](https://aws.amazon.com/security/security-bulletins/2026-125-aws/), [AWS Bulletin 2026-124 for the three Loom for AWS CVEs](https://aws.amazon.com/security/security-bulletins/2026-124-aws/), [AWS Bulletin 2026-121 for CVE-2026-97662 in security-agent-mcp-server](https://aws.amazon.com/security/security-bulletins/2026-121-aws/), and [AWS Bulletin 2026-117 for CVE-2026-95985 in Kiro IDE](https://aws.amazon.com/security/security-bulletins/2026-117-aws/). The permissions and audit recommendations are grounded in AWS’s [IAM security best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html), [least-privilege guidance](https://docs.aws.amazon.com/wellarchitected/2024-06-27/framework/sec_permissions_least_privileges.html), and [CloudTrail API documentation](https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/).","available_translations":[{"language":"ar","title":"نشرات AWS الأمنية لشهر أكتوبر تجعل أدوات التطوير الوكيلة جزءاً من الاستجابة للحوادث","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=ar","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=ar","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=ar"},{"language":"de","title":"AWS-Sicherheitsbulletins im Oktober machen agentische Entwicklungstools zur Sache der Incident Response","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=de","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=de","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=de"},{"language":"en","title":"AWS’s October security bulletins turn agentic development tools into an incident-response issue","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=en","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=en","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=en"},{"language":"es","title":"Los boletines de seguridad de AWS de octubre convierten las herramientas de desarrollo agéntico en un asunto de respuesta a incidentes","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=es","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=es","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=es"},{"language":"fr","title":"Les bulletins de sécurité AWS d’octobre font du développement agentique un sujet de réponse aux incidents","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=fr","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=fr","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=fr"},{"language":"pl","title":"Październikowe biuletyny bezpieczeństwa AWS zmieniają narzędzia do agentycznego programowania w problem reagowania na incydenty","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=pl","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=pl","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=pl"},{"language":"ru","title":"Октябрьские бюллетени AWS превращают безопасность агентных инструментов разработки в задачу реагирования на инциденты","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=ru","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=ru","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=ru"},{"language":"zh","title":"AWS 十月安全公告：代理式开发工具已成为事件响应问题","html_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=zh","markdown_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=zh","json_url":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=zh"}],"_links":{"self":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=en","api":"https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_agentic_development_security_bulletins_october_2026?lang=en","html":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=en","canonical":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026?lang=en","markdown":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.md?lang=en","json":"https://publicasta.com/it_today_news/aws_agentic_development_security_bulletins_october_2026.json?lang=en","channel":"https://publicasta.com/api/public/v1/channels/it_today_news","channel_articles":"https://publicasta.com/api/public/v1/channels/it_today_news/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}