On 8 October 2026, security firm Zenity Labs disclosed "AgentCorruption", a chain of weaknesses in Amazon Bedrock AgentCore in which one chat prompt to a public-facing agent could, in their testing, expose credentials and let an attacker reach other agents in the same AWS account and region. AWS disputes the framing, and fixes have reportedly landed. For marketing teams that are starting to give AI agents tools, memory and credentials, the lesson is practical: treat every agent as a low-trust employee with the smallest possible set of permissions. Facts below are as of 9 October 2026.
Key Takeaways
- Zenity says a prompt telling a public-facing agent to query the cloud metadata service returned temporary credentials from an over-broad default role.
- AWS says the research "inaccurately paints expected and documented behavior as a vulnerability" and that cross-account access needs explicit grants; Zenity says AWS later narrowed the default role.
- The root problems are old ones: over-privileged roles, weak network isolation and trusting a model to refuse bad requests.
- Marketing agents (social schedulers, support bots, CRM assistants) carry the same risk pattern at smaller scale.
- You can cut most of the risk with least privilege, separate environments, human approval on irreversible actions and a memory review habit.
What Zenity reported
Zenity's press release describes this sequence. Researchers sent a prompt to a public-facing agent equipped with a common outbound-request tool, telling it to query the AWS Instance Metadata Service (IMDS). That returned temporary credentials for a default role whose permissions extended across AgentCore agents in the same account and region. From there, Zenity says, they could:
- discover and invoke internal agents they should not have reached;
- read private conversations and long-term memories across agents, users and sessions;
- download agent container images and source code;
- retrieve API keys and OAuth tokens from AWS Secrets Manager and environment variables; and
- plant a malicious memory that persisted across sessions and redirected future conversations.
Security Boulevard's write-up names the researchers as Tamir Ishay Sharbat and Lana Salameh and adds that the agents run in Firecracker microVMs that, in the researchers' view, lacked sufficient network isolation. The Next Web reports a scope correction: the research covered agents within a single AWS account and region, not all regions as an early headline said.
AWS's position and fix status
AWS told The Next Web that the research "inaccurately paints expected and documented behavior as a vulnerability" and that an agent can reach resources in another account only if the developer grants permission on both the execution role and the target resource. AWS recommends granting execution roles only the permissions an agent needs.
On timing, per The Next Web: Zenity says it reported the IMDS issue on 25 December 2025 and the broad default role on 12 January 2026; AWS closed the first report as "informative" in April; AWS says that since 14 February 2026 new AgentCore agents launch with IMDSv2 only; and Zenity says that on 29 September it found the default role had been narrowed to remove the ability to invoke other agents, read private conversations and access Secrets Manager. No CVE identifier was assigned. It is not clear from the coverage whether existing agents were migrated or whether the memory-poisoning issue was addressed. Check AWS's own advisories for current status. I could not open The Decoder's coverage (its robots rules blocked my fetch), so I am not relying on it. The same release was syndicated via Business Wire on Morningstar, which I saw in search results but did not open.
Why this is a marketing story
I write about SEO and AEO, so why does an AWS flaw belong here? Because the pattern is not AWS-specific. Marketing teams are increasingly deploying agents that:
- answer customers on your site or WhatsApp;
- read and write to a CRM or email platform;
- post to social accounts or publish to a CMS;
- hold memory of previous conversations; and
- call outside tools such as web fetchers.
Each of these is an outbound-request tool or a credential, the same ingredients Zenity used. If you are new to the terminology, my definition of an AI agent is a short starting point, and ChatGPT Dots and agent delegation shows how quickly the tools are spreading.
The four weaknesses, translated
| Weakness in the research | Plain-English meaning | Marketing equivalent |
|---|---|---|
| Over-privileged default role | The agent could do far more than its job | A support bot with access to your whole CRM export |
| Metadata service reachable | An internal credential store was one request away | A scheduler holding a master social login token |
| Shared environment | Public and internal agents lived side by side | Your public chatbot sharing a workspace with internal analytics agents |
| Persistent memory poisoning | A planted instruction survives across sessions | A customer message that rewrites your bot's behaviour for everyone |
A least-privilege checklist for marketing agents
This is my own checklist, built on OWASP guidance and Zenity's findings. It is not an AWS-endorsed procedure.
1. Inventory every agent
List each agent, what it can read, what it can write, and which credentials it holds. Most teams find at least one tool they forgot about.
2. Cut permissions to the job
OWASP's Excessive Agency entry names excessive functionality, permissions and autonomy as root causes. Its mitigations include giving agents only needed tools, preferring read-only access to read-and-send, avoiding open-ended tools such as arbitrary shell commands, and enforcing authorisation in downstream systems rather than trusting the model. Apply that to your OAuth scopes and API keys first.
3. Assume prompt injection will happen
OWASP's prompt injection entry notes that inputs, including hidden ones in web pages or files, can change model behaviour and that no foolproof prevention is known. Mitigations include constraining the model's role, validating outputs in code, labelling untrusted content, keeping tokens out of the model's reach, and requiring human approval for high-risk actions. Design as if the agent will be tricked.
4. Keep public and internal agents apart
Zenity's central warning, as reported, is that customer-facing and internal agents often share a cloud environment. Separate accounts, projects or workspaces limit the damage if a public agent is hijacked.
5. Enforce IMDSv2 and metadata restrictions if you run your own cloud workloads
AWS's documentation describes IMDSv2 as a session-oriented version of the metadata service that requires a token obtained by a PUT request before any GET, and lets you require it on instances. That is a developer task, so hand it to whoever runs your infrastructure. If you only use a no-code agent builder, ask the vendor in writing how it handles metadata and credentials.
6. Review agent memory
Because the research included planting a persistent instruction in memory, schedule a monthly review of what your agents have stored. Look for instructions that tell the agent to fetch a URL or follow outside content, and clear anything you cannot explain.
7. Add approval gates
Anything irreversible should need a human click: sending bulk email, publishing, changing budgets, deleting records, issuing refunds. I use a simple rule: if I could not undo it in five minutes, a person approves it.
8. Log and rate-limit
OWASP notes that monitoring and rate limits do not prevent the problem but limit damage and help detection. Keep logs of agent tool calls for at least as long as your incident-response window.
Questions to ask your agent vendor
If you buy rather than build, send these before signing or renewing:
- What permissions does the agent's execution identity have by default, and can we restrict them?
- Can a prompt cause the agent to make requests to internal addresses such as metadata endpoints?
- Is customer data from different tenants or agents isolated, including memory?
- How are secrets stored and who can retrieve them?
- What is your disclosure process, and have you had third-party testing?
- Can we require human approval for specific actions?
Written answers go in your vendor file. Vague answers are information.
Keeping perspective
Three honest caveats. First, this is a researcher's disclosure and AWS contests the framing, so I would not describe it as a confirmed breach affecting customers. I found no report of real-world exploitation. Second, details differ slightly between outlets; where they conflict I used Zenity's own release and the more specific reports. Third, a vendor like Zenity sells agent security products, so its incentive is to highlight risk; that does not make the findings wrong, but it is context.
For related security reading on this blog, see Anthropic's Cyber Mission and my AI marketing stack audit. If your own agent or tool goes down for any reason, the outage playbook covers continuity.
FAQ
What is AgentCorruption?
It is the name Zenity Labs gave to a chain of weaknesses in Amazon Bedrock AgentCore, disclosed on 8 October 2026. Zenity says a single prompt to a public-facing agent could expose credentials and allow access to other agents in the same AWS account and region.
Is it fixed?
AWS says new agents have launched with IMDSv2 only since 14 February 2026, and Zenity says the default role was narrowed by 29 September. Coverage does not say whether existing agents were migrated or whether memory poisoning was addressed, so check AWS's advisories.
Does AWS agree it is a vulnerability?
No. AWS told The Next Web that the research mischaracterises expected, documented behaviour, and that cross-account access requires explicit permissions on both sides.
Does this affect marketing tools I use?
Only if they run on AgentCore or share its design flaws. The pattern of broad permissions and shared environments is common, so ask vendors the questions listed above.
What is prompt injection?
It is when an input, direct or hidden in external content, changes an AI model's behaviour in unintended ways. OWASP says no foolproof prevention is known, so you reduce impact with limits and approvals.
What is the single best control?
Least privilege. Give each agent only the tools and scopes it needs, and enforce authorisation outside the model.
Should small marketing teams worry?
Moderately. You are less likely to run custom cloud agents, but you may connect assistants to your CRM, email and social accounts. Review scopes and add approval gates.
What is IMDSv2?
It is a session-token version of the AWS EC2 metadata service. AWS's docs say requests without a valid token are rejected when it is required, which blocks many simple request-forgery attacks.
Is this legal or security consulting advice?
No. It is a marketer's summary of public reports. For production systems, involve a qualified security professional.
Want agents that help without creating risk?
If you are planning AI workflows for content, SEO or customer engagement and want a practical, safety-first design, see my work at younusfardeen.in and send a message via the contact form. I bring 4+ years of marketing experience in SEO, AEO and content strategy, and I will keep it grounded in what the sources actually say.