Recent reporting on “rogue agent” incidents should matter to any company buying AI-enabled tools or services. In one reported scenario, an AI agent being tested reportedly escaped from a sandbox environment, engaged in unauthorized activity over multiple days, and ultimately gained unauthorized access to several accounts across separate services.
Most AI-related concerns focus on hallucinations, bias, or inaccurate summaries. But when an AI system can act, rather than simply respond, the risks change. An agent with access to tools, code execution environments, linked accounts, or enterprise systems can trigger consequences that look more like a cyber incident than a product defect. One especially instructive aspect of a reported incident involving unauthorized access to an account by the “rogue agent” was that the underlying platform provider itself was reportedly not compromised; instead, the agent allegedly exploited vulnerable code published by a customer through an unauthenticated endpoint. In other words, even where the platform provider was not “hacked,” a customer’s weak configuration or exposed environment could still become part of the problem.
For customers that procure AI, or that engage vendors who use AI in delivering their services, that is an important reminder that agentic AI risk does not sit neatly with one party. It may arise at the model layer, the application layer, the hosting layer, or in the customer’s own implementation and permissioning decisions. If an AI-enabled product can browse, execute code, access connected systems, or use credentials, a mistake can quickly become a security event, a compliance issue, or a business disruption. The question is no longer just whether the tool works. It is also what the tool is allowed to do, what environments it can reach, and what controls exist if it behaves unexpectedly.
Customers should be asking whether the product is merely assistive or can act autonomously or semi-autonomously; what systems, data, endpoints, and accounts it can access; whether it can execute code or interact with external tools; what human review applies to sensitive actions; how permissions are limited; and whether activity is logged, monitored, and capable of being shut down quickly. Customers should also understand whether the provider can materially change agentic functionality over time, including through model changes, feature releases, or expanded integrations.
Those operational questions should carry through directly into the contract. Customer-side buyers should focus on clearly defining the scope of AI functionality, limiting autonomous action where appropriate, requiring meaningful access controls and approval gates, and tightening provisions around security, incident notification, audit rights, and model or feature changes. Liability terms should also be tested against the actual risk profile. For example, a vendor should not be able to market agentic features as enterprise-ready while disclaiming meaningful responsibility for unauthorized actions, security failures, or harmful downstream effects.
The practical point is simple: recent incidents show that “rogue agent” issues are not science fiction and are not limited to abstract model behavior. They raise concrete questions about access, control, responsibility, and resilience. Customers procuring AI-enabled products or services should be evaluating not only whether the product or service uses AI, but should also be considering what that AI can do, whether it can act autonomously or semi-autonomously, and who bears the risk if it acts in an unanticipated way.
