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

[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?

[Shawn Stevens]

@Sami Shaik I can't wait to see what others have to say. I'm just going based on the things I have read, seeing how my company is using AI, and the panic when they realize the cost associated with AI. I've been struggling with this whole concept as you have explained, the articles have explained. 

You are right, we don't have the tooling in place and I'm not 100% sure this is the responsibility of Jira Administrators to build this out. When I looked at the team in the Uber article it was 6 or 7 folks, that I assume worked on this setup. 

Can't wait to hear more and thank you for creating the discussion. 

[Sami Shaik]

@Shawn Stevens  

Do not sell yourself short, "no expert" is doing a lot of work in that sentence 🙂 You brought the one thing nobody else on this thread has: what actually happens inside a company when the AI bill lands. That is field data, and it is worth more here than another architecture opinion.

On responsibility, I think you are right, and I would put it this way. Building agent identity tooling is not a Jira admin's job. Owning the toggle is, because the switch sits in Atlassian Administration and it is our name on the audit trail. So the honest split is that we own the screen and the record, while the decision belongs with whoever owns AI risk and AI spend. Your cost point adds the second half of that sentence, because until now this thread has been treating Allow A2A as a security decision only.

So let me put your angle to the room, since it is the freshest thing here: has the AI cost conversation reached your desk yet as a Jira or org admin? Are you being asked to justify or cap agent spend, or does that still sit with finance and the AI team?