Security researchers uncovered a vulnerability chain in AWS AgentCore that demonstrates how one compromised AI agent could threaten an entire connected environment. For revenue leaders, the implications extend well beyond cybersecurity.
One prompt. One AI agent. An entire network of agents potentially exposed.
That’s the latest concern from a newly disclosed vulnerability chain in Amazon Web Services’ AI infrastructure.
Security researchers at Zenity Labs identified a series of weaknesses in AWS Bedrock AgentCore that could allow an attacker to move from a single public-facing AI agent to other agents operating within the same AWS account and region.
The discovery, dubbed AgentCorruption, raises a question that every company deploying autonomous AI should be asking: How much access does one AI agent really need—and what happens when that access is exploited?
For CROs, CMOs, and revenue operations leaders, the implications are significant. As organizations connect AI agents to customer records, sales pipelines, forecasting systems, and internal workflows, a security weakness in one component can create exposure far beyond its original purpose.
The biggest concern isn’t necessarily that an AI agent might make a bad decision.
It’s that a compromised agent could gain access to decisions, data, and systems it was never supposed to control.
What Zenity researchers discovered
According to Zenity Labs’ October 8 disclosure, the researchers demonstrated how three security weaknesses could combine to compromise agents beyond the original target.
The attack began with a prompt sent to a public-facing AI agent running on AWS Bedrock AgentCore.
That agent had access to a tool capable of making outbound network requests. Researchers used that capability to reach the AWS Instance Metadata Service, which exposed temporary cloud credentials.
The problem escalated because those credentials belonged to an execution role with permissions extending beyond the original agent.
Using the credentials, researchers demonstrated the ability to access other agents within the same AWS account and region, including internal agents that were not intended to be publicly accessible.
How the AgentCorruption attack spread
- One malicious prompt
- Public-facing AI agent receives attacker instructions
- Cloud credentials exposed
- Agent reaches metadata service and retrieves its execution-role credentials
- Access spreads to other agents
- Broad permissions allow access across the account and region
- Sensitive systems and data exposed
Private conversations, source code, secrets, and persistent agent memory
Illustration of the attack demonstrated by Zenity Labs, not an active AWS incident.
The researchers also demonstrated how malicious instructions planted in agent memory could influence future interactions and direct conversations to an attacker-controlled destination.
This is particularly concerning because an agent could appear to function normally while operating under unauthorized instructions.
The biggest AI security risk may be excessive permissions
AI agents need access to information and applications to perform useful work. A sales agent might need customer account information. A forecasting agent might need pipeline data. A compensation agent might need quota attainment and commission records. But useful access and unlimited access are two very different things.
Zenity’s research illustrates the danger of assigning broad permissions to agents that require only limited capabilities.
Michael Bargury, co-founder and CTO of Zenity, summarized the tension, “Cloud security is all about segmentation and least-privilege access.”
His point is that AI agents need flexibility to accomplish tasks, while security requires restrictions on what those agents can access.
For revenue organizations, this creates a practical governance challenge. Consider a hypothetical company running several AI agents:
- A customer service agent answers product questions.
- A sales agent manages prospect engagement.
- A RevOps agent evaluates territory assignments.
- A finance agent analyzes compensation and revenue performance.
These agents may operate within the same cloud environment, but they should not automatically share the same permissions.
A customer service agent has no business accessing confidential commission calculations. A prospecting agent should not be able to modify companywide quota assignments.
The fact that two AI agents can communicate does not mean they should have unrestricted access to each other.
Why this matters for CROs: Your revenue data is becoming an attractive target
The growing adoption of AI agents is changing how revenue data moves through an organization. Customer conversations, pricing strategies, pipeline forecasts, contracts, and compensation records are increasingly accessible through automated workflows. That creates opportunities for efficiency, but it also increases the importance of controlling access.
Imagine a customer-facing AI agent connected to a company’s CRM.
A successful compromise might expose more than the information used to answer customer questions. Depending on the agent’s permissions and connected systems, it could create opportunities to access internal sales information, customer records, or other applications.
For CROs, the consequences could include compromised customer relationships, disrupted sales operations, and loss of confidence in sensitive business information.
For CFOs, the concerns extend to financial controls, compliance obligations, and the integrity of compensation data.
For CMOs, a compromised customer-facing agent could expose confidential interactions and undermine brand trust.
These are potential business scenarios, not incidents Zenity reported at a particular revenue organization.
The central lesson remains relevant: The security of an AI-powered revenue engine depends on more than the security of each individual agent. It also depends on the permissions and connections between them.
AWS addressed the vulnerabilities. The governance lesson remains.
There is an important distinction between the vulnerabilities Zenity discovered and the current state of AWS AgentCore.
Zenity responsibly disclosed its findings to AWS beginning in December 2025.
According to its technical research and disclosure timeline, AWS introduced IMDSv2-only behavior for new AgentCore deployments in February 2026.
By September 29, Zenity had also verified substantial restrictions to AgentCore’s default execution role, including removal of permissions that had allowed cross-agent invocation, access to private conversations, and access to secrets.
These mitigations addressed the reported attack chain. Organizations should still review existing configurations and permissions rather than assuming all deployments have identical protections.
The broader lesson applies to every organization deploying AI agents, regardless of cloud provider. Security controls need to be designed around the entire agent environment, not simply the application exposed to users.
Five questions every revenue leader should ask before deploying AI agents
Revenue leaders do not need to become cybersecurity engineers. They do need to understand the business implications of AI permissions and access.
- Can one compromised agent reach other agents?
Security teams should test whether a public-facing agent can access internal applications, credentials, or agent workflows outside its intended responsibilities.
- Are permissions limited to the agent’s actual job?
Agents should operate under least-privilege access policies rather than broad default roles.
- Can agents access sensitive revenue information?
Review which agents can retrieve customer records, pipeline data, pricing information, forecasts, and compensation details.
- Can unauthorized actions be detected and reversed?
Organizations need monitoring, audit trails, and intervention procedures that help identify suspicious activity and limit damage.
- Who owns agent governance across the revenue lifecycle?
IT and security teams should manage technical protections. Revenue operations leaders should help define business permissions, workflow ownership, approval requirements, and acceptable actions.
These responsibilities need to work together.
A secure infrastructure does not automatically guarantee sound revenue decisions. And well-defined revenue policies cannot compensate for compromised cloud credentials.
Where Fullcast fits: Govern the revenue process before giving agents access
The AgentCorruption discovery reinforces a broader challenge for revenue organizations: Automation is becoming more powerful, but operational accountability cannot disappear.
Revenue teams need consistent policies governing how territories are assigned, how leads are routed, how performance is measured, and how commissions are calculated.
Fullcast’s revenue orchestration approach brings planning, execution, performance, and compensation into a more connected operating model.
That foundation becomes particularly valuable as organizations introduce AI agents into revenue workflows.
- Fullcast Plan supports structured territory, quota, and capacity planning.
- Fullcast Perform connects revenue execution with routing policies and performance visibility.
- Fullcast Pay helps manage commission calculations and compensation rules.
Together, these capabilities support more consistent revenue governance.
They are not substitutes for cloud security controls, agent isolation, or identity and access management. Those protections must be implemented in the underlying technical environment.
But clear business rules help organizations define what automated systems should be allowed to change, which decisions require authorization, and how outcomes should be evaluated.
The objective is not to give every AI agent access to the entire revenue engine. It’s to give each agent the access necessary to perform its assigned role—and nothing more.
The next AI security challenge is controlling the connections
Zenity’s AgentCorruption research demonstrates how quickly a vulnerability can expand when access controls fail.
The attack began with a single public-facing agent. The demonstrated impact extended across an account’s AgentCore environment within the same region.
AWS has since implemented mitigations, but the incident offers a broader lesson for enterprises investing in autonomous AI.
Connecting more agents can increase productivity. It can also increase the consequences of a compromised identity or overly permissive configuration.
Revenue leaders should work with security teams to understand those dependencies before agents become essential to daily operations.
Because the real measure of an AI-powered revenue operation isn’t how many tasks its agents can perform.
It’s whether the organization can control what those agents are permitted to do.
Four key takeaways
- What is the AWS AgentCore AgentCorruption vulnerability?
AgentCorruption is a chain of security flaws discovered by Zenity Labs that allowed researchers to compromise multiple AWS Bedrock AgentCore agents within the same account and region through a single public-facing agent.
- Why is AI agent isolation important for revenue operations?
Agent isolation helps prevent a compromised customer-facing or internal agent from accessing unrelated systems, sensitive customer information, revenue data, or confidential business processes.
- How can enterprises reduce AI agent security risks?
Organizations should enforce least-privilege access, separate sensitive workloads, review agent identities and permissions, monitor activity, and establish incident response procedures.
- What is the role of RevOps in AI agent governance?
RevOps helps define the business policies, workflow ownership, approval requirements, and accountability needed when AI agents interact with revenue-critical systems.