nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

AI agents found a fourth door into your org: each other. Allow A2A?

Sami Shaik

Two weeks ago this community mapped three doors AI agents use to enter Jira: workflows, automation, and assignment. That thread collected governance patterns I still quote. But while we were watching those doors, a fourth one opened, and it is not for agents entering your org.

It is for agents talking to each other.

This is shipping, not roadmap. In Atlassian Administration, the Rovo MCP server page now carries an A2A tab (Beta) with a single Allow A2A toggle, off by default: enable it and, per the product's own words, "external agents can discover Rovo's capabilities and collaborate on tasks across Atlassian apps." Rovo publishes a public AgentCard for exactly this discovery. Gemini Enterprise can already connect to Rovo through a Google Cloud Marketplace listing. And the door swings both ways: a Forge module in EAP lets remote agents (GitHub Copilot, Cursor, Box AI) live inside Jira as assignable, mentionable colleagues, speaking the same A2A protocol. Atlassian is a founding partner of that protocol. This is a direction, not an experiment.

Now, credit where due: the documentation answers the first governance question well. An A2A connection acts with the authorizing user's own permissions, Rovo cannot do anything that user cannot, and org AI policies still apply. Good. But the three-doors thread taught me that "technically bounded" and "governable" are different things, and here is where I stop knowing the answers:

A user's permissions, exercised at machine speed by a chain of agents, are not the same risk as that user clicking. When Gemini asks Rovo which asks a Forge-connected agent, every hop is "authorized", and the blast radius is still nothing your review processes have ever seen. Is per-user permission scoping enough, or does agent delegation need its own ceiling?
What does audit mean for a delegation chain? "Who did this" now has answers like: your PM's Gemini asked Rovo. What does your compliance team write in that finding?
Would you turn Allow A2A on today? If not, what is the concrete thing that would change your answer: scoped capabilities, chain-level logging, an approval step per connection, something else?
And underneath it all: when agents discover and delegate to each other, is the unit you govern still the agent, or is it the conversation?

My toggle stays off while I think. Where is yours, and more importantly, why?

Comments

Shawn Stevens

Not specific to A2A but AI, Atlassian MCP and user versus ai access. there was another community post that spoke to some of this,

https://community.atlassian.com/forums/App-Central-articles/Your-Users-Can-See-100-Jira-Projects-Should-Claude-See-All-100/ba-p/3270805

This was a fascinating article from Uber.

https://www.uber.com/us/en/blog/solving-the-agent-identity-crisis/?_pec=no&referrer=https%3A%2F%2Fteams.public.onecdn.static.microsoft%2F&_csid=PrtOw1a7wJOodi3XwTDwNw&state=Ed4WRKAmWEjKvdIAqyCUyc2ZyymJ0Tpqd4r1VjF804o%3D&effect=&sm_flow_id=sXRabbaL

I believe this speaks to some of the questions, at least I think it does. ;-)

Sami Shaik

@Shawn Stevens

Thank you, both links land right on the nerve of question 1, and the Uber title alone names the problem better than I did: an identity crisis. The user-permission model gives an agent a borrowed identity, and the App Central piece asks the exact follow-up: should the borrowing agent see everything the lender can? Once you have two agents in a chain, the borrowing gets recursive, and "whose access is this, really" stops having a clean answer.

So let me sharpen question 1 with what your links suggest: if agents need their own identities (with their own scoped ceilings) rather than borrowed ones, then A2A governance is not really a toggle problem, it is an identity-and-scoping problem that the current per-user model postpones rather than solves. Would you turn on Allow A2A once agent-scoped access existed, or does the delegation chain still worry you even then? Genuinely curious where the "enough" line sits for you 🙏.

Shawn Stevens

@Sami Shaik I still feel like the delegation chain worries me but if we had better control and agent-scooped access that would help, but that just becomes another thing Atlassian Admins have to manage (possibly) and it is just adding more work on top of current work. I thought the Uber article really highlighted the concern well and how they tackled it.

I would definitely be interested in hear what others have to say, because I am definitely no expert on this topic.

Sami Shaik

@Shawn Stevens

Thank you, and you just named the cost side that nobody had said out loud yet 🙏

Agent-scoped identities would answer the "whose access is this" question. But every scoped identity is a new object an admin has to create, review, rotate and one day decommission. Multiply that by the number of agents a team plugs in and it stops being a security feature and starts being an inventory 📋

So the honest trade-off on the table is: borrowed identity (simple to run, hard to audit) versus native agent identity (auditable, but a new admin estate to maintain). Uber's write-up leans that way. Most Jira admin teams do not have that tooling yet.

Which is exactly why the toggle question is not just security. It is capacity 🧭

Opening it up to the room, especially anyone running Guard at Enterprise scale: if Allow A2A came with agent identities you had to manage, would you have the headcount to run it well? Or is "off until the tooling exists" the pragmatic answer for now?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

agent

rovo-atlassian-intelligence

rovo

organization-administration

agents

atlassian-administration