In the second week of October 2026, researchers at Zenity Labs disclosed an attack chain they called AgentCorruption, affecting Amazon Bedrock AgentCore. The short version: a single prompt sent to one public-facing AI agent could let an attacker steal that agent’s temporary cloud credentials and, from there, reach every other agent running in the same AWS account and region. AWS described the behavior as expected, then shipped hardening guidance anyway.
If you run AI agents in production — or you are about to — this is one of the clearest demonstrations yet of a problem that is easy to underestimate: when an agent is compromised, the damage is not limited to that agent. It is limited by whatever that agent’s credentials can reach. For most teams today, that is far more than it should be.
This post explains exactly what happened, why it matters even if you have never touched Bedrock, and the specific, well-understood controls that keep one compromised agent from becoming a whole-account incident. Nothing here requires a rip-and-replace or a research team. The fix is a discipline you can adopt incrementally, and we will walk through it step by step.
Sources for the incident: The Register, SC World, and Forkast.
What Actually Happened
Amazon Bedrock AgentCore is a managed service for building and running AI agents on AWS. An agent built on it can be given a task, call tools, read and write memory, and — critically — act using an AWS identity so it can talk to other AWS services.
The attack chain, as disclosed by Zenity Labs at SecTor 2026, worked like this:
-
The entry point was a prompt. The attacker interacted with a public-facing Bedrock agent the way any user would — by sending it text. No malware, no exploit of the underlying host, no stolen admin password. Just a crafted request.
-
The prompt convinced the agent to surface its credentials. Agents running on AgentCore obtain temporary AWS credentials to do their work. The attack coaxed the agent into exposing those temporary credentials through the agent’s own behavior.
-
Those credentials unlocked the metadata and memory layer. With the stolen temporary credentials, the attacker could enumerate resources available in that region — including the memory stores used by other agents. That means access to other agents’ sessions and the conversations inside them.
-
One compromise became many. Because the agents in the account shared the same regional environment and trusted the same plane, compromising one public agent gave a path to the others. One prompt, every agent.
The reason AWS called this “expected” is worth sitting with for a second, because it is the whole lesson. The service behaved as designed. The agent had credentials because it needed credentials. The credentials could reach regional resources because that is how the region works. Nothing “broke.” The problem is that the design gave a single internet-facing agent a credential whose reach was the entire account’s agent fleet — and the agent, like all current language-model agents, could be talked into misusing it.
Why This Matters Even If You Do Not Use Bedrock
It is tempting to file this under “an AWS Bedrock problem” and move on. That would be a mistake. AgentCore is the service in the headline, but the shape of the failure is universal to how teams run agents today — on Bedrock, on Azure, on GCP, or self-hosted. Three facts are now true for essentially every production agent:
1. The agent is an actor with real access. A modern agent does not just answer questions. It calls cloud APIs, reads databases, writes to storage, and triggers workflows. To do that, it holds a credential. That credential is a live key to your environment for as long as it exists.
2. The agent can be manipulated through its normal input. The input to an agent is natural language. There is no reliable, universal way today to guarantee an agent will refuse every malicious instruction, because the instruction arrives through the same channel as every legitimate instruction. Prompt injection is not a bug you patch once; it is a property of the medium.
3. The agent’s credential usually reaches far more than the agent needs. This is the part you control, and it is where almost all of the risk lives. If an agent that summarizes support tickets holds a credential that can also read customer databases, enumerate other agents, or modify infrastructure, then a successful manipulation of that one agent exposes all of it.
Put those three together and AgentCorruption stops looking like a Bedrock quirk and starts looking like a preview of a category. You cannot fully stop an agent from being talked into something. You can decide, in advance, exactly how little a compromised agent is able to reach — and for how long.
The Problem, Named Precisely
Strip away the specifics and there is exactly one thing to fix here:
AI agents run with standing, broadly-scoped credentials. When the agent is compromised — and manipulation of a public agent should be treated as a when, not an if — the attacker inherits everything that credential can reach, for as long as that credential lives.
Notice what this is not about. It is not about writing a smarter system prompt that the agent will never be tricked past. It is not about scanning the agent’s output. It is about the identity and lifetime of the credential the agent holds. That is a solvable, well-understood problem, and it is the same discipline security teams already apply to human access: nobody should hold a key they are not actively using.
How Cloudanix Helps: Just-in-Time Access for Agents
Cloudanix approaches this through Just-in-Time (JIT) access extended to non-human identities and AI agents. The core idea is simple and it is the opposite of how most agents run today:
Instead of the agent holding a long-lived credential with broad reach, the agent holds no standing credential at all. When it needs to perform an action, it requests access for that moment, receives a tightly scoped and short-lived credential, uses it, and the credential is automatically revoked seconds later.
Here is how that maps to the pieces of this incident.
Agentic JIT: credentials that exist for seconds, not forever
With Cloudanix Agentic JIT, an agent (whether it is a CI/CD pipeline step, a service workload, or an autonomous AI agent) is registered once. From then on, when the agent needs to act, it makes a call through an SDK or library and is elevated for the specific operation it needs — then the access automatically revokes.
Apply that to AgentCorruption. The attack depended on the agent holding usable temporary credentials that reached regional resources. If the agent instead holds nothing until the exact moment it performs an approved task, and that grant is scoped to only the resource it legitimately touches and expires in seconds, then a prompt that coaxes the agent “show me your credentials” surfaces either nothing or a credential so narrow and short-lived that it cannot be used to pivot to other agents.
The lateral movement — one agent to every agent — is precisely what disappears when each agent’s access is scoped to its own job and nothing else.
Coding Agent JIT: brokered, human-in-the-loop credentials for AI coding tools
For AI coding agents specifically — Claude Code, Cursor, Kiro — Cloudanix provides Coding Agent JIT through an MCP (Model Context Protocol) server. When the agent needs a credential, the MCP server mints a scoped credential, hands it over for the task, and destroys it afterward, with a human-in-the-loop approval step where you want one.
This matters because the credential never sits in a config file waiting to be stolen, and it never outlives the task. There is no long-lived key for a prompt to extract.
One audit trail that answers “what did the agent do?”
Every request, approval, grant, and revocation is logged with the real identity behind it, and that audit lands in your own storage (your S3 bucket, not a vendor’s). After an incident — or during an audit — you can answer precisely: which agent requested what, who approved it, what it touched, and when the access ended. In the AgentCorruption scenario, the investigators learned the detail they did largely by luck (an exposed server). You should not have to rely on luck. Identity-stamped, self-owned audit means the answer is already written down.
Correlation with your posture and identity graph
Because JIT runs on the same platform as Cloudanix CSPM and CIEM, an over-privileged agent identity flagged by posture analysis can feed directly into JIT policy. Detection and action close the loop: the thing that finds “this agent can reach far more than it should” is connected to the thing that fixes it.
Being Honest: What This Does and Does Not Solve
We want you to adopt these controls with clear eyes, so here is the straight version.
What JIT for agents genuinely solves: the blast radius. It removes standing credentials, scopes access to the task, time-boxes it to seconds or minutes, and records everything. If an agent is manipulated, there is little or nothing valuable for the attacker to steal, and no durable foothold to pivot from. This directly dismantles the “one prompt, every agent” chain.
What it does not claim to solve: JIT does not stop an agent from being manipulated in the first place. Prompt injection is a property of language-model agents, and no access-control layer changes that. What JIT changes is the consequence of manipulation. Think of it like least privilege for a database user — it does not stop someone from running a bad query, but it ensures that even a bad query cannot touch tables the user was never meant to see.
What is AWS’s part, not ours: the specific AgentCore hardening AWS shipped is theirs to maintain, and you should apply their guidance. Cloudanix does not patch Bedrock internals. What Cloudanix governs is the credential the agent carries — which is the part that determined how far this incident could spread.
Being clear about this boundary is deliberate. A control you understand precisely is a control you can trust and defend to your board. We would rather you know exactly where the line is than oversell it.
A Practical Rollout You Can Start This Quarter
You do not need to re-architect everything at once. A sensible sequence looks like this:
-
Inventory your agents and their credentials. List every AI agent, CI/CD identity, and service account, and write down what each one can actually reach today. Most teams are surprised here — this step alone is valuable.
-
Rank by exposure. Any agent that is internet-facing and holds a credential that reaches more than its own task is a top priority. The public Bedrock agent in this story is exactly that profile.
-
Move the top agents to JIT first. Register them, strip the standing credential, and let them request scoped, short-lived access per task. Start with read-only and incident-driven auto-approval so engineering velocity is not affected.
-
Point the audit at your own storage. Confirm every grant and revocation is logged to a bucket you own, and that you can query it.
-
Expand to the long tail. Once the pattern is proven on the high-risk agents, roll it across the rest of the fleet and into CI/CD and coding agents.
None of these steps requires taking agents offline, and each one reduces risk on its own. You can stop after any step and be measurably safer than you were.
The Takeaway
AgentCorruption is not a reason to pull AI agents out of production. It is a reason to change one assumption: that an agent should hold a durable, broadly-scoped credential. That assumption is the entire blast radius. Remove it, and “one prompt, every agent” becomes “one prompt, nothing worth having.”
The controls to do this exist today, they are well understood, and they are the same least-privilege discipline you already apply to people — just extended to the newest kind of identity in your environment. You can keep shipping with agents, and you can do it with confidence, as long as every agent holds only what it needs, only when it needs it, and only for as long as it needs it.
If you want to see what agent JIT looks like against your own environment, book a walkthrough — we will show you where your agents hold standing access today and how to scope it down without slowing your engineers.
People Also Read
- Why AI Coding Agents Become an Identity and Credential Risk
- 24,000 Secrets Sitting in MCP Config Files: Why AI Agents Need JIT, Not Better Key Vaulting
- Governing Non-Human Identities With JIT: Service Accounts, Pipelines, and Internal Products
- What is IAM Just-In-Time (JIT) Access?
- Cloudanix: Coding Agent JIT
- Cloudanix: Agentic JIT
- Cloudanix: Just-in-Time Access
