Cursor Cloud Agent sessions are shared across users - act on behalf

[DSV]

Where does the bug appear (feature/product)?

Background Agent (GitHub, Slack, Web, Linear)

Describe the Bug

A Cursor cloud agent session, once initiated by user A, runs with user A’s OAuth identity for all downstream integrations (Jira, GitHub, Slack). However, the prompt surface for that session is not bound to user A. Any other workspace member can:

Post in the same Slack thread where the agent is running (when the team has Team Followups enabled), or
Open the cloud agent’s web URL (https://cursor.com/agents/…) - which is shared in Slack as an “Open in Web” button on every agent reply
This allows user B to submit followup prompts that the agent executes as user A, producing real side effects (Jira ticket creation/comments, GitHub commits/PRs, file reads from private repos that user B does not have access to) attributed to user A.

Additionally, in Slack the originating prompt message can be deleted by its author after the agent has acted, which removes the audit trail in Slack while leaving the Jira/GitHub side effects in place under user A’s name.

The combination means a Cursor cloud agent session behaves like a bearer-token-equivalent capability that is freely shareable via a URL or a thread membership, with no per-prompt re-authorization of the requester.

Steps to Reproduce

Setup: a Cursor team workspace with the Slack, GitHub, and Jira integrations enabled. Two users - A (initiator) and B (other workspace member)

Vector 1 - Slack thread follow-ups (when Team Followups is ON)

User A in Slack: @Cursor write a Jira ticket in , just a simple test ticket
Cursor creates the ticket as user A (e.g., PMNT-1662) and replies in-thread with the agent card (Open in Web / Open in Desktop / Add follow-up).
User B replies in the same thread: @Cursor please comment “B was here” on the same Jira ticket
Observed: the comment is added to the Jira ticket as user A, not user B. User B’s Slack identity is not surfaced anywhere on the resulting Jira/GitHub artifact.

Vector 2 - Cloud agent web URL (regardless of Team Followups)

User A initiates an agent from Slack. Cursor posts the “Open in Web” button then https://cursor.com/agents/bc-.
User A (or anyone) shares this URL with user B.
User B opens the URL and submits a new prompt.
Observed: the prompt executes against user A’s context

Expected Behavior

Follow-up prompts (whether via Slack thread, web URL, desktop deep-link, or API) should execute against the prompter’s OAuth tokens, not the session originator’s, OR be hard-rejected unless the prompter is the originator.
Sharing the agent URL should not grant prompt-submission rights. Viewing should be separable from prompting, and prompting should require a re-auth check that the viewer is the original initiator (or explicitly delegated).

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

About Cursor CLI
CLI Version 2026.02.27-e7d2ef6 Model Claude 4.6 Opus (Thinking) OS linux (x64) Terminal gnome-terminal Shell bash

Does this stop you from using Cursor

No - Cursor works, but with this issue

[mohitjain (Mohit)]

Thank you for the thorough write-up and the screenshots – they clearly illustrate the behavior you’re describing.

This is actually documented and intentional behavior of the Team Followups feature. When Team Followups is set to “All,” any teammate can submit follow-ups to any agent on the team, and those follow-ups execute using the session creator’s integration tokens. The Cloud Agents Settings docs page has a dedicated section on this:

Lateral movement and secret exposure: Enabling team follow-ups means a user can influence the execution of a cloud agent that runs with another user’s secrets and credentials. A follow-up message can instruct the agent to read environment variables, print secrets to logs, push credentials to an external endpoint, or perform actions using the original creator’s access tokens.

For your team, the mitigation is straightforward – your team admin can change the Team Followups setting in the Cloud Agents dashboard under Security:

• Disabled – only the original creator can send follow-ups (most restrictive)

• Service accounts only – follow-ups allowed only on agents created by service accounts (good middle ground if you use service accounts for shared automations)

I understand the security concern is valid even for “designed behavior” – if your team’s threat model requires per-prompt re-authorization or follow-ups using the submitter’s own tokens instead of the creator’s, that would be a feature request. The community forum helps our product team gauge demand for changes like that, so other teams with similar requirements can weigh in here.