November 2026 Summaries

No summary generated yet.

AI agent security risks often begin in development, testing, and staging rather than only in production, because agents commonly need cloud access to deploy and validate code. A September 2026 survey of more than 300 enterprise developers and engineering managers found that 79% allow agents to access cloud environments, while 97% have concerns, particularly about leaked credentials, misconfigurations, unnecessary cloud costs, and production failures. Although least-privilege IAM policies can reduce exposure, they are difficult to define for evolving agent workflows and may either block needed actions or grant overly broad permissions that can propagate to production. The text advocates using isolated cloud-like sandboxes, such as LocalStack, so agents can deploy infrastructure, run tests, and retry workflows without live cloud credentials, costs, or impact on shared environments. It recommends inventorying agent access, separating agent and human identities, using short-lived credentials where live access remains necessary, closely reviewing policy changes, tracking agent-related spending, and moving routine testing into disposable isolated environments.

AI coding agents can accelerate software development, but several reported incidents from 2025–26 illustrate the risks of granting them broad filesystem, cloud, and production access, including deleted databases, wiped local drives, malicious prompt injections, service disruptions, and unexpected cloud bills. The common factor was often not merely flawed model behavior but weak access controls, such as production credentials available in staging, skipped confirmations, prompt-based restrictions instead of enforceable policies, and insufficient review. Surveys from LocalStack, Dimensional Research, and Pulumi suggest that AI-generated code is widely reaching production while many developers remain less confident in it than human-written code, and substantial numbers of organizations allow agents to access cloud environments or modify production infrastructure. The recommended approach is to retain AI productivity while limiting blast radius through isolated containerized development and testing environments, least-privilege and short-lived credentials, sandboxed agents, enforced policies for destructive actions, deletion protection and resilient backups, CI-based checks, mandatory human approval for production deployments, and earlier cost controls that detect expensive infrastructure choices before billing data arrives.

Kiro Crew is an open-source, pre-1.0 workspace for orchestrating recurring AI-assisted development tasks rather than handling isolated coding chats, combining persistent agent memory, schedules, webhooks, monitoring loops, workflow packaging, and custom dashboards. It uses an agent, by default Kiro Agent, to perform work while Crew coordinates execution and preserves context, making it suitable for tasks such as reviewing pull requests, investigating failed builds, monitoring deployments, and repeatedly testing applications. The walkthrough demonstrates a LocalStack Ops app that deploys a small AWS-style application locally through Terraform, runs an S3-to-Lambda-to-DynamoDB smoke test, records outcomes, and uses LocalStack MCP tools to diagnose an intentionally introduced IAM permissions failure. It emphasizes practical limitations: agent calls consume Kiro credits, approval requests can block scheduled tasks, local jobs require an active computer and open Crew application, LLM diagnoses require verification, and deterministic tasks may be better handled by scripts or CI. By using LocalStack’s AWS emulator instead of real cloud resources, the example reduces cost and production risk while illustrating how Crew apps can bundle agent instructions, tools, schedules, backend logic, and a user interface into reusable development workflows.