Hello @Yamil Daniel Ali , good question, and the wall you hit is not a Jira limitation, it is an identity-model choice, so let me separate the two sides.
Atlassian's side is per-user by design. The Rovo MCP server authenticates with OAuth 2.1 through an interactive consent flow, and the docs are explicit: tokens are never shared between users, and every action runs with the consenting user's own permissions. So "everyone acts as me" is not something Atlassian is doing; it is what happens when the client holds one consent and reuses it for everybody.
Which means the fix lives on the Copilot Studio side. When you added the MCP server, the connection took your consent (that once-in-the-test-pane step). Check how that connection is configured for end users: agent platforms generally distinguish between a maker's credentials shared with all users and each end user authenticating themselves. If Copilot Studio offers end-user authentication for this MCP connection (verify in the current Copilot Studio docs, this changed recently along with the endpoint), that is your per-user answer: each colleague consents once, and their tickets carry their own name. If it does not for MCP connections yet, then yes, per-user identity is not achievable through that connection today, and you are choosing between the options below.
The honest options if per-user is not available:
- A dedicated service identity, deliberately. Connect as a named service account (Atlassian also allows API-token authentication for MCP if your org admin enables it, meant precisely for non-interactive scenarios), and stop pretending it is a person: tickets show the service account as reporter, and the agent captures the real requester in the summary or a field. Transparent, auditable, and often good enough for internal triage bots.
- Keep the front door where it belongs. For customers raising requests, the JSM portal and email channels already handle identity, request types, SLAs, and notifications correctly. The MCP agent shines as an agent-side tool: summarising queues, drafting responses, searching Confluence, not as the customer intake channel. Most teams that fight for per-user MCP intake end up here.
On use cases, the ones that hold up: agent copilots (queue summaries, similar-ticket lookup, drafting replies grounded in your knowledge base), status questions in Teams ("where is my request" answered read-only from JQL), and internal triage where a service identity is acceptable. The pattern is: read broadly, write narrowly, and never let the agent's identity be a mystery to your audit log.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.