An operations bot that answers to natural language and an AI assistant that answers to natural language look like cousins, and in 2026 they increasingly share the same channel. That convergence is why the myths below deserve retirement now rather than later. ChatOps is the discipline of running operational work through shared chat: bots announce events, execute commands from a reviewed list, and keep every action, result and argument visible to the room, wrapped in permissions and backed by logs. Teams working on AIOps keep adopting it, and keep inheriting assumptions that were never true. Each myth below is stated the way practitioners actually say it, then checked against the record.

Myth One: The Bot Is Just a Messenger

The comforting picture — a small program that relays messages — collapses the moment you inventory what it can touch. A command bot holds credentials for deployments, restarts, page-outs and sometimes cloud consoles. It is a privileged system with a friendly face, and it inherits the oldest privilege bug in computing: the confused deputy, where an intermediary with legitimate authority is persuaded to spend that authority on someone else’s behalf. Automation platforms have shipped this way by default; StackStorm, for instance, historically executed chat-initiated runs under a single shared account, chatops_bot, flattening every human into one identity until someone configured otherwise.

The precise correction: treat the bot like any other service account holding production reach. Inventory its grants, rotate its secrets through a secret manager, and record which human requested each action through an identity map of your own — the immutable platform identifier, never the nickname.

Myth Two: AI Can Read the Room, So It Can Approve the Room’s Actions

Assistants joined these channels promising triage: summarize the incident, draft the fix, run the rollback. The defensible division of labor is one-directional — assistants propose, humans approve — and the reasons are empirical. PromptArmor’s August 2024 disclosure showed a Slack AI assistant surfacing attacker-planted instructions drawn from public channel content, a prompt-injection path from a message any stranger could write to a tool with organizational reach. OWASP’s LLM risk list anticipated the shape of the problem (LLM01, prompt injection) and its quieter cousin (LLM06, sensitive information leaking into contexts it should never reach).

So the rule stands even when the assistant is confident and the requester is impatient: no model grants its own permission, no matter how well it argues. Log the prompts and the tool calls either way, because when the post-mortem comes, the transcript of what the assistant was asked and what it did is the difference between an investigation and a shrug.

There is a channel-hygiene corollary. The practice names two standing problems — bot and command security, and signal versus noise — and an unmoderated assistant worsens the second while everyone watches the first. A bot that comments on every commit, summary of every thread, and reply to every alert trains humans to skim. Assistants earn channel space the same way human colleagues do: by saying less, less often, about things that matter.

Myth Three: The ChatOps Scrollback Doubles as the Audit Trail

Channel history feels like a ledger — timestamped, searchable, appended in order. It fails as a record on every property that matters. Messages can be edited and deleted by their authors. Retention policies silently expire old threads. And platforms themselves come and go, retiring products and taking history with them. Verification guidance for ChatOps states the conclusion flatly: keep the audit log outside chat, written append-only to a store the chat vendor cannot revise, in a schema stable enough to compare entries across quarters.

The scrollback remains useful — as color, context, the human texture around decisions. It simply cannot be the system of record, any more than a whiteboard photograph can be the contract.

Myth Four: The Platform Verifies Senders, So We Are Covered by Default

Every major chat product offers some proof that a request genuinely came from the platform, and the implementations differ enough to sink careless teams. Slack signs each request and expects the receiver to check the HMAC-SHA256 signature, with a five-minute window against replays and an acknowledgement expected within 3,000 milliseconds. Teams presents signed JWTs naming their issuer. Mattermost’s usual credential is a static token with no signature over the payload whatsoever, so the body of a request says whatever its sender decides it says — a property attackers find generous.

“Covered by default” therefore means: covered exactly as much as your receiver checks, and no further. A receiver that skips the signature check converts a signed platform into an open relay. The precise version of this myth is that verification is a per-platform engineering task with per-platform failure modes — not a checkbox the vendor already ticked for you.

Myth Five: Migrations Are a Weekend Configuration Change

The last decade of chat platforms reads as a warning label. Hipchat and Stride shut down entirely. Slack retired its legacy custom bot platform on March 31, 2025. Microsoft ended Office 365 Connectors in Teams in May 2026. Opsgenie goes dark on April 5, 2027. Each retirement broke automations that had been quietly running, and each taught the same lesson: logic that lives inside the chat adapter dies with the adapter.

The architecture that survives keeps three layers apart — translation (adapter), decision (gateway), action (executors) — so the policy about who may restart a database outlives the particular WebSocket it arrived on. Newer integrations keep arriving; Slack announced an MCP server in February 2026, and assistants will attach to it the way they attach to everything. Attach through the gateway, not around it, and the next retirement becomes a scheduling note instead of an incident.

Myth Six: A Growing ChatOps Command Library Means Growing Maturity

Command counts and message totals make flattering dashboard lines and poor measures of progress. What actually improves is narrower and more countable: audited change coverage, meaning the share of production-touching actions that flow through the permissioned path — one worked example puts it at 93.9%; a command success rate that the same documented setup holds at 98.1%; the refusal rate and its mix, which show the guardrails actually intercepting risky requests; approval latency, which exposes where humans have become the bottleneck; and the actionable notification ratio, 23% in that worked example against a stated target of 50%.

The pattern a mature team shows is not more commands. It is a larger fraction of consequential work inside the guarded path, fewer pages per shift, and refusals that cluster around genuinely dangerous requests rather than around typos.

What the Corrected Picture Looks Like

Assemble the corrections and a precise architecture appears, none of it exotic:

• A privileged bot with inventoried credentials, acting for named humans rather than a shared alias.
• A trust chain run in order: verify origin, map the immutable user identifier, authorize, obtain approvals where the action warrants them, then write the audit entry to storage the chat vendor cannot revise.
• Actions graded by blast radius — reversible writes require a defined role in a defined channel, and the gravest operations wait for two people.
• AI participants confined to proposing, with every prompt and tool call logged for the post-mortem nobody hopes to hold.

Two working examples show the corrected picture in motion. GitHub ran deploys through chat for years — hundreds per week through a queue with CI guards and locks — and by 2021 had moved the deploy state itself into a state machine with its own UI, leaving chat as the trigger rather than the store of truth. GOV.UK took the opposite, gentler path: read-only bots that nudge engineers when a pull request sits unmerged too long or a scheduled scan never ran — proposing work without holding the authority to execute any.

For readers mapping a career through this territory, the DevOps engineer roadmap on this site slots this skill set between pipeline work and reliability work, and the site’s explainer on AI-supported business decisions argues the same principle from the other direction: automation earns trust by showing its reasoning to a human who can veto it. For the full history and the failure catalogue behind these six corrections, consult the Ops Atlas ChatOps entry, the reference against which every claim above was checked — precise where precision matters, and candid about where the practice is still finding its footing.