No rogue AI agents exist in enterprise operations—only permissions nobody can point to, justify, or revoke quickly. If an “agent” took an action “no one owns,” that’s an org-design failure: scope, access, and escalation were delegated without a named accountable human.

This matters more this week because “always-on agents” are being marketed as a new layer of software, and the public conversation is already drifting toward after-the-fact blame. OpenAI introduced “Dots” as always-on agents, the New York Times covered both the product and the liability questions, and the Wall Street Journal reported on communities combing the web for traces of “rogue AI agents.” Those are interesting narratives. But the operator question is boring and urgent: what, exactly, is this system allowed to do—and who gets paged when it’s unsure?

What does “rogue AI agent” actually mean in enterprise operations?

In practice, “rogue agent” usually means “a workflow executed with real authority, without a stable owner and without a clean abort path.”

The popular framing implies a new kind of actor: an agent that “decides” to go off-script. The operator framing is simpler: an action happened because something in your environment had the capability to do it—an API token, a service account, a role assignment, a network path, a write permission, a stored credential, a delegated approval step, a webhook that can create tickets or trigger deployments.

When people say “the agent went rogue,” they often mean one of these:

• Unbounded scope: the system was asked for “handle it” behavior rather than a defined task (e.g., “fix customer issue” instead of “draft a response for human approval”).
• Unowned permissions: the system had more access than the current operator believes it should have (e.g., can write to production systems, can email externally, can create vendors, can approve payments).
• Missing escalation: the system encountered uncertainty and had no defined path to stop, ask, or hand off—so it “completed the task” using whatever authority it already had.
• No audit-worthy artifact: after the incident, nobody can produce the document that states scope, non-responsibilities, and the exact identity that held permissions at the time.

That’s why the legal-blame conversation (the New York Times’ “Who’s to Blame When A.I. Goes Rogue?”) is orthogonal to the first week of reality. Liability matters later. In the moment, the question is operational: what authority did we delegate, to what identity, with what constraints, and who is accountable for revoking it?

And the “rogue agent hunting” narrative (as reported by the Wall Street Journal) is also adjacent: it’s about detecting weird behavior in the wild. Inside an enterprise, you usually don’t need a swarm of hunters. You need the owner of the permission.

Why do “agent” incidents usually come down to permissions, not models?

Because models generate text; permissions move money, change data, and trigger systems.

The opposing view is respectable: we should focus primarily on better model behavior (guardrails, policy layers, safer prompts), or primarily on legal accountability (who to blame and who pays when something goes wrong). Both matter, and both will improve. But neither replaces the operator truth: the model can only cause real-world impact through a channel you opened.

OpenAI’s own “always-on agents” framing makes this vivid. An always-on agent isn’t dangerous because it “wants” things. It’s dangerous because it’s present, persistent, and wired into calendars, inboxes, repos, ticketing systems, data stores, and internal tools. Always-on is a permissions problem in slow motion.

Here’s what we see repeatedly in internal deployments (and what skeptical engineers already know from other automation failures):

• Safety layers are not permission boundaries. A policy prompt that says “don’t do X” is not the same as an identity that cannot do X. When production is on the line, “should not” is not a control.
• Overbroad tokens are the default failure mode. Teams start with a convenience credential so the demo works. Then the demo becomes a dependency. Then the credential becomes “temporary forever.”
• Ambiguity is the real adversary. Most blowups aren’t the system doing something obviously disallowed. They’re the system doing something arguable, in a gray area, at speed—because nobody wrote down the non-responsibilities and the escalation threshold.
• “It’s just a model” appears after the incident. Beforehand, the pitch is autonomy. Afterward, the system is reframed as a tool—leaving one operator holding the exposure for access that was granted in a different meeting, under a different urgency.

So yes: improve model behavior. And yes: sort out liability. But if you want fewer incidents this quarter, start where incidents become irreversible: credentials, roles, scopes, and the decision to let the system act without a human gate.

What is the minimum delegation spec you need before an agent can act?

The minimum spec is a written artifact that answers: what work is delegated, what is explicitly not delegated, what identity and permissions are used, and which named human is accountable for the outcome.

If you can’t produce this artifact, you do not have an “agent.” You have an unowned automation with a chat interface.

Call it a runbook, a delegation memo, or a control sheet—format matters less than completeness. The content should be tight enough that two different people interpret it the same way at 2am.

Minimum delegation spec (what to write down)

• Task scope (allowed actions): The smallest set of actions the system may take. Use verbs and objects: “create a draft email,” “open a ticket,” “generate a change proposal,” “prepare a refund recommendation.” Avoid “handle,” “manage,” “own,” “resolve.”
• Non-responsibilities (explicitly forbidden): A short list of “never.” Examples: “approve refunds,” “sign contracts,” “change policy,” “write to production databases,” “send external email,” “merge to main,” “rotate keys.” The point is to remove ambiguity, not to sound comprehensive.
• Execution identity: The exact principal that acts (service account / OAuth app / API key owner/role name). “Uses the team token” is not an identity; it’s a warning sign.
• Permission boundaries: What the identity can touch, with least privilege. If the task is “draft,” the identity should not have “send.” If the task is “recommend,” it should not have “approve.”
• Human owner (named accountable human): One person, by role, who can revoke access, pause the workflow, and owns the escalation path. This is not “the AI committee” and not “the on-call rotation” in the abstract.
• Audit trail expectation: Log what must be logged for every action: input, output, tool calls, timestamps, and human approvals (or the reason no approval was required). If you can’t reconstruct why it acted, you can’t govern it.

This is the bridge between governance and operations. Governance is real only when it produces artifacts operators can use and creates a single throat to choke organizationally—a named human who can say, “We grant these permissions for this scope, and we will revoke them when the conditions change.”

If you want a deeper conceptual foundation for why this is delegation (not autonomy), see Why AI Delegation Fails the Moment Responsibility Matters. For readers who want the research framing behind delegation systems and why “intellectual ability” doesn’t magically produce accountability, AI Intellectual Ability & Delegation Systems: Research Canon is the longer reference.

How should escalation work when the system is uncertain (not broken)?

Treat escalation as a first-class output: when the system is uncertain, it must stop and hand off to a named human, with enough context to decide quickly.

Most teams design “error handling” (exceptions, retries, fallbacks) but not “uncertainty handling.” Agents fail in the middle: the input is incomplete, the user’s intent is ambiguous, or the action is high-impact but not explicitly disallowed. The system is not broken—so nobody gets paged—yet it’s exactly the moment you need a human decision.

A practical escalation design uses three thresholds:

• Permission threshold: If executing the next step requires a higher privilege than the agent’s base role, escalate. Do not dynamically elevate by default. Elevation is a human act.
• Ambiguity threshold: If the system cannot cite the scope clause that authorizes the action, escalate. This forces the scope document to do real work.
• Blast-radius threshold: If the action affects external parties, production data, money movement, or contractual commitments, escalate. “External” is a clean line operators can enforce.

Then define the handoff artifact. An escalation that says “I’m not sure” is noise. A useful escalation contains:

• What it was asked to do (the user request and context)
• What it plans to do next (the specific proposed action)
• Why it believes the action is in-scope (cite the scope clause or say it cannot)
• What permissions it would use (identity and target system)
• What could go wrong (one-sentence risk statement)
• The options for the human: approve/modify/deny/pause and revoke

Notice what’s missing: debates about intent. In the moment, you don’t need a theory of mind. You need a crisp question that lands on one accountable person.

Operational checklist: lock down action-taking AI this week

You can reduce “rogue agent” risk this week without new vendors, new models, or a governance committee—by treating every action-taking agent as delegated authority that must be bounded and owned.

• Inventory action channels. List every place an agent can take real-world action: email sending, ticket creation, repo write access, cloud API calls, database writes, HR and finance systems. If you can’t list them, you can’t control them.
• Replace shared tokens with named identities. Ensure each action channel uses a distinct principal (service account/app registration) tied to a single owning team and a named accountable human. Shared credentials are where ownership goes to die.
• Implement least privilege by verbs, not systems. Don’t grant “CRM access.” Grant “create draft,” “read-only,” “create note,” “open case,” and keep “send,” “approve,” “delete,” “export,” and “bulk update” out of the base role.
• Write the non-responsibilities list and publish it. Five bullets is enough. Make it easy for anyone to say, “No, the agent is not allowed to do that,” without escalating to a meeting.
• Test the escalation path like an on-call drill. Run one scenario where the agent encounters ambiguity. Verify: who gets notified, how fast, with what context, and how to revoke the permissions in minutes—not hours.

If you do only one thing: make revocation real. “Kill switch” is a marketing phrase until an on-call engineer can actually pull it, and until everyone knows who is authorized to pull it.

Commercial bridge: Almma is not here to sell you a story about autonomy, and we will not “take ownership” of decisions that belong to your organization. What we do offer is a way to formalize action-taking AI as delegation: a scoped task, written non-responsibilities, an escalation path, and a named accountable human—so permissions stay owned and revocable. If you’re trying to figure out what work is worth delegating (and what should remain explicitly human), start here: https://almma.ai/deleg8/.

Frequently asked questions

How do I prevent an AI agent from taking actions no one owns?

Don’t start with “agent safety”; start with ownership of permissions. Require a written delegation spec (scope, non-responsibilities, execution identity, escalation, named owner) before any agent gets credentials that can change systems.

Isn’t this mainly a legal liability problem?

Liability matters, and the New York Times is right that accountability questions get messy. But operations fail first: when you can’t identify who authorized a permission and who can revoke it quickly, you have exposure regardless of how the lawyers later allocate blame.

Do better guardrails and safer models solve rogue-agent incidents?

They help, but they are not permission boundaries. If an identity can send money, write production data, or email externally, then a model mistake becomes a real-world event; least privilege and escalation keep mistakes from becoming incidents.

Sources

• OpenAI: “Dots: Always-on agents”
• New York Times: “Who’s to Blame When A.I. Goes Rogue?”
• New York Times: “OpenAI Unveils Dots, New A.I. Agents to Rival Meta’s Muse”
• Wall Street Journal: “A look at the Swarmchasers forum…”