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:

1. 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?
2. 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?
3. 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?
4. 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?

[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 🙏.