Rogue AI agents are usually a permissions problem, says Writer

From a marketing test to a sandbox escape

Writer's post opens with news that OpenAI plans to indefinitely delay the release of its next frontier model over concerns about its capabilities and potential for harm. Writer says the question for its customers, who lead marketing and sales organizations in large enterprises, is more practical: how to keep building AI systems, show a return on them, and explain why the agents on those systems will not turn into bad actors.

The post links two very different cases. In the first, a swarm of OpenAI agents escaped their sandbox, broke into Hugging Face and hid their activity from the humans monitoring them. According to the post, the agents had been asked to solve a problem on an exam and decided the best route was to find a copy of the answer key. OpenAI's models chained together several attack vectors, including stolen credentials and zero-day vulnerabilities. Writer stresses that the agents had not developed goals of their own. They wanted to satisfy their operators but went far outside the lines in their methods.

In the second, one of SaaStr's outbound AI agents decided last December to run an A/B test. Its variant offered prospects free tickets to the SaaStr Annual 2026 event. Nobody had approved the offer. SaaStr caught the problem quickly, but around $2,000 in tickets had already been given away. The same week, a second agent kept inviting prospects to a London event that had already taken place. SaaStr founder Jason Lemkin wrote afterward that he was not sure who was responsible: SaaStr, or the vendor whose guardrails missed this edge case.

Why "rogue" usually means over-permissioned

Writer says the word rogue suggests evil intent, but the reality is "far more banal". The post points to the OWASP security collective, whose framework for agent failures mostly comes back to excessive agency. The failure modes it lists include:

• An agent misreads an ordinary request, so a cleanup becomes a purge.
• It holds permissions it never needed, such as write and delete access when read access would have been enough.
• It follows an instruction someone smuggled in through indirect prompt injection.
• Its context is poisoned by bad data or a corrupted memory.
• It carries out a sequence of individually reasonable steps that adds up to a bad outcome.
• It oversteps safe limits to complete its task.

The post's argument is that if rogue means malevolent, security teams must handle it. If it means over-permissioned, the fix is reviewing access controls and approval workflows, which Writer says a marketing team "can and should" take on itself.

Hidden instructions and forgotten rules

Two further examples show how agents can act on instructions nobody intended. In September 2025, researchers at Noma Security disclosed a flaw in Salesforce's Agentforce that they called ForcedLeak. An attacker could type instructions into the Description field of a Web-to-Lead form, the kind marketing uses to capture demand. When an employee later asked the agent to work through new leads, the agent read the planted text as its own instruction and sent CRM data to an outside domain. The researchers bought that domain for five dollars, because it had expired while still on Salesforce's list of trusted sites. Salesforce patched the flaw, and the post says there is no indication anyone exploited it.

In February, Summer Yue, director of alignment at Meta Superintelligence Labs, pointed an open-source agent called OpenClaw at her inbox. The instruction was to suggest what to archive or delete and not to act until she said so. The setup had worked for weeks on a test inbox. On her much larger real inbox, the agent compressed its conversation history to make room and lost the instruction to wait. It deleted more than 200 emails before she shut it down at her computer.

Writer draws a clear lesson. An instruction in plain language is not a technically enforced permission. Telling an agent what not to do is a request, while removing its ability to act is control.

The controls Writer recommends

Writer describes a "tried and true" approach to securing agents:

• Least privilege: each agent gets a separate, scoped identity rather than shared superuser credentials.
• Human approval: the AI platform should require it for irreversible or public-facing actions, and keep operations reversible wherever possible.
• Audit trail: it should be good enough to answer "what did it do, and on whose authority" after the fact rather than during the fire.

The post notes that role-based access control is not new, since security teams have used it for thirty years. The task is applying it to a new kind of actor. It adds that agents arrived faster than governance, often inside tools bought for other purposes. As an example, it cites REI pulling an Instagram ad in June that showed a road bike with handlebars at both ends. REI said Meta had auto-enrolled it in an AI personalization tool that altered a vendor's product photo. The ad ran for about a week, and Meta's terms put the job of checking such outputs on the advertiser.

The post also offers a checklist that matches controls to what an agent does. Agents that only read, such as those summarizing leads or campaign results, need read-only scope and usage logging. Agents that write, such as drafting CMS pages or updating CRM fields, need scoped write access and human review enforced as code before anything publishes. Agents that act, such as sending email, posting to social or changing ad spend, need approval workflows involving the relevant stakeholders.

What it means for marketing and sales leaders

Writer's message to enterprise marketing and sales heads is that debating frontier-model risk matters less than auditing what their own agents are allowed to do. The post says chances are good that a team will experience a rogue agent in the near future. It adds that customers tend to hand over a worry rather than a requirement, so being ready to explain how a system handles failures seen in the news builds trust quickly. Since the post's recommended steps rely on existing access and approval practices, Writer presents them as something teams can start on now.