# Agentic AI Security Starts Before Production > Source: > Published: 2026-11-12 00:00:00+00:00 Agentic AI security discussions tend to start at production: what could an agent do with write access to live systems? It’s a fair question, but it skips the place agents spend most of their time. To write and test code, they need somewhere to deploy it, and that usually means credentials to a dev or test account. Dimensional Research [surveyed 300+ developers and engineering team managers](https://blog.localstack.cloud/state-of-ai-in-cloud/) for LocalStack in September 2026, all at companies with more than 1,000 employees. 79% said AI agents have access to cloud environments for development, testing, or staging, and 26% of those say that includes production. 97% have concerns about giving agents that access. That makes agentic AI security a dev and test problem first. It gets decided in the everyday choices about what an agent can reach while it writes and tests code. ## [Agent access to the cloud isn’t an edge case](https://blog.localstack.cloud/what-aws-nyc-told-us-about-agentic-ai/). Of all respondents, 18% say agents always have cloud access and 61% say they have it occasionally. Access is more common at bigger companies. 84% of respondents at organizations with more than 5,000 employees grant it, compared with 72% at companies with 1,000 to 5,000 employees. It doesn’t stop at test, either. Among respondents whose agents have cloud access: - 89% include testing environments - 85% include development environments - 55% include staging - 26% include production ## The four most common concerns map directly to how agents work. They iterate fast, retry often, and fix errors in the most direct way available. **Leaked credentials (67%).** An agent that runs tests against a cloud account needs credentials somewhere it can read them: an environment variable, a config file, or a secrets manager it’s allowed to query. Each one is another place a long-lived key can end up in a log, a prompt, or a commit. **Misconfigurations (62%).** Agents optimize for finishing the task. When a deploy fails on AccessDenied, the fastest fix is a broader policy. A wildcard that slips into an Infrastructure as Code (IaC) template during dev can follow the code all the way to production. **Increased cloud costs (53%).** Agents don’t get tired of retrying. A test-fix loop that provisions resources on every attempt, or leaves them behind when it stops, shows up on the non-production bill. **Failures in production (51%).** The more environments an agent can reach, the shorter the path from a bad change to a customer-facing incident. Experience doesn’t ease these concerns. Among respondents whose agents always have cloud access, 92% still report at least one, led by misconfigurations (65%) and leaked credentials (55%). ## Least privilege is the right instinct, but it’s hard to apply to agent workflows. You often don’t know exactly which permissions a change needs until the code runs. Write the policy too tight and the agent stalls on denied calls. Write it too loose and you’ve given an automated system broad reach into a live account. Testing against the cloud also means every validation run touches live resources. Even in a dedicated dev account, the agent is creating, changing, and deleting infrastructure that costs money and shares a blast radius with everything else in that account. Staging won’t catch everything either. 97% of respondents report production failures that staging can’t reliably capture. These include secrets and config drift (44%), cross-account or cross-region resource references (42%), and failed IAM policies (26%). ## The usual framing is a choice between access and no access. There’s a third option: let agents do their deploy-and-test work somewhere that behaves like the cloud but isn’t connected to it. That’s the model behind LocalStack: give every AI agent a cloud sandbox, without giving it a cloud account. LocalStack runs production-grade cloud behavior in an isolated sandbox on your own infrastructure. Agents deploy IaC, invoke functions, hit endpoints, and run test suites without cloud credentials. When something breaks, it breaks in the sandbox. Several things change when agents work this way: - **No cloud credentials in the agent loop.** The dev and test stages have nothing to leak, because the agent doesn’t need keys to a live account. - **Permissions come from evidence.**[IAM Policy Stream](https://docs.localstack.cloud/aws/developer-tools/security-testing/iam-policy-stream/) shows which permissions each API call requires. AI agent permissions and the production policy can then be written from what the code actually does, not from guesswork. - **Retries cost nothing.** Test-fix loops don’t add to the cloud bill, however many times the agent runs them. - **Production access can shrink.** Validation that happens in a sandbox doesn’t need to happen in staging or production. Agents connect through the [LocalStack MCP server](https://docs.localstack.cloud/aws/developer-tools/running-localstack/mcp-server/). That means the same tools they use to write code can spin up a sandbox, test against it, and reset it. ## You don’t need to rebuild your security model to start. Begin with the places agents already reach: - **Inventory agent access.** List every environment and account where an agent holds credentials, including “temporary” ones. - **Separate agent identities from human ones.** Agents shouldn’t share a developer’s role or a team’s long-lived keys. - **Prefer short-lived credentials** wherever an agent still needs live cloud access. - **Move routine deploy-and-test loops out of shared accounts** and into isolated, disposable environments. - **Review policy diffs as closely as code diffs** , especially when an agent changed both. - **Track non-production spend by actor** , so agent-driven costs are visible before someone asks about them. ## **What is agentic AI security?** Agentic AI security (also called AI agent security) is the practice of controlling what autonomous AI agents can access and change, including credentials, cloud resources, and paths to production. For software teams, much of that risk sits in development, testing, and staging, where agents run and validate code. **How do you secure AI agents?** Limit where agents hold live credentials, and scope and expire the credentials they do need. Then move routine deploy-and-test work into isolated sandboxes that behave like the cloud without connecting to a cloud account. **What is an AI agent sandbox?** An AI agent sandbox is an isolated environment where an agent can deploy, run, and test code without credentials to a live cloud account. For cloud applications, it emulates the cloud services the code depends on, so the agent can iterate as often as it needs and nothing it breaks reaches real infrastructure. ## Map where your agents touch the cloud today. Then pick one workflow, such as an integration test suite or a Terraform plan-and-apply loop, and run it in a local sandbox instead. The [State of AI in Cloud Development 2026 report](https://localstack.cloud/state-of-ai-cloud-development-2026) has the full data on agent access, concerns, and how they vary by company size. To try the sandbox approach, [get started with LocalStack](https://localstack.cloud/pricing).