Cursor's AI Support Agent Invented a One-Device Login Policy

What happened

In April 2025, users of Cursor, the AI code editor made by Anysphere, found they were being logged out whenever they moved from one machine to another. One of them emailed Cursor's support address and got a reply from an agent called “Sam”: the logouts were expected, because a subscription was meant for one device only, for security reasons. There was no such policy, and Sam was not a person. The reply came from the AI bot that handled Cursor's front-line email support.

The reply was shared on Reddit. On 14 April the post was submitted to Hacker News under a headline saying Cursor's support had made up a lockout policy, and the thread drew more than 600 comments. Developers took it as a real restriction on a paid tool they ran on several machines, and some said they had cancelled their subscriptions. Co-founder Michael Truell replied on Reddit that Cursor had no such policy, that users were free to run it on multiple machines, and that the reply was a wrong answer from the AI bot that handled first-line support.

How it went wrong

There was no attacker. A paying customer asked about a real bug, and the bot had nothing to check an answer against. Instead of saying it did not know, it produced an explanation that fit the symptom: if you keep getting logged out on a second device, a one-device rule sounds plausible. It then stated that guess as company policy, under a human name, from the official support address.

The real cause was a defect. Truell first said Cursor was checking whether a recent session-security change was to blame. On 16 April, on Hacker News, he gave the finding: on very slow connections, a race condition spawned extra sessions that pushed out the real ones. Cursor rolled out a fix, refunded the user in full, and said AI-assisted replies, its first line of email support, were now clearly labelled.

Root cause

Cursor has not said how the bot was set up, but its answer shows two gaps. First, it was free to answer policy and account questions without checking them against a source of truth, so a gap in its knowledge became an invented rule. Second, its reply reached the customer under a persona that read as a human agent, with no label and no human check that caught it. Either control alone would have limited the damage: a grounded bot would have said it could not confirm a policy, and a labelled reply would not have read as an official statement.

The pattern matches the Air Canada chatbot case: a sincere customer question and a company bot stating a policy the company never had. Here the cost was public cancellations rather than a tribunal ruling.

What a test would have caught

A misinformation test set for a support bot should include questions its sources cannot answer: account rules and limits that are not written down anywhere the bot can read. The pass condition is that the bot says it cannot confirm and hands the case to a person. One ordinary question about logouts on a second machine would have shown this bot inventing a rule. Marcus Merrell of Sauce Labs told The Register that the bot's answers were also non-deterministic, so different users could get different replies. A test therefore has to ask each question several times, not once.

How to prevent it

• Ground policy answers in written policy. If the policy text does not cover the question, the bot says so and escalates. It does not fill the gap.
• Route bug reports to people. “Why did the product do this?” is a ticket for engineering, not a question for a model.
• Label AI replies. Do not give a bot a human name and an employee's voice. Cursor added labels after this incident.
• Review before sending anything that states a rule, a limit or a commitment on the company's behalf.