Team'26 Recap Serie - DAY #4: Guarding the Gates with Rovo Security & Governance

[#1]

Hi Community! 👋

Did you catch the sessions and keynotes at Team ’26 in Anaheim? If you missed it or just want a refresher, I'me breaking down the biggest announcements over the next few days.

This is the second entry of a day-by-day serie of forum posts about key agenda topics and announcements from Team'26.

Previous article: Team'26 Recap Serie - DAY #3: Developer Announcements for Teamwork Graph & Rovo 

---

Hey community! As we deploy more AI agents across our teams, security is top-of-mind for every admin. Today we are looking at how Atlassian is addressing Rovo Security & Governance.

With great automated power comes a greater need for visibility and compliance. Atlassian highlighted three core areas of control:

🛡️ 1. Data Access & Protection

• Prompt & Chat Controls: Prevent sensitive corporate data leakage.
• Connector Protection: External data sources strictly respect original system permissions.
• Atlassian-Hosted LLMs: Your data stays secure within Atlassian’s trusted boundaries.

🤖 2. Agent Governance

• Agent Permissions: Define exactly what an agent can and cannot see.
• Agent Skill Controls: Limit the active actions an agent can execute.
• Agent Accounts: Treat AI agents with distinct identity profiles for transparent auditing.

👁️ 3. End-to-End Visibility

• Comprehensive Audit Logs for agent actions.
• Granular Agent Insights and Rovo Usage analytics to monitor adoption and performance safely.

References:

• ROVO FAQs 
• Rovo Data Residency 
• Atlassian hosted-LLM 
• How LLMs are used 

💬 Community Discussion: For the admins out there—does having distinct "Agent Accounts" and explicit skill controls give you the peace of mind needed to roll out Rovo more widely? Let's discuss!

[Matteo Vecchiato]

Entry #5: Team'26 Recap Serie - DAY #5: Elevating Dev Teams with Code intelligence in Rovo, Bitbucket & DX AI 

[Josh]

@Matteo Vecchiato  "Agent Accounts" are a critical piece to full-scale production deployments for us. The concept of passing on all user permissions for something that could be running autonomously may be fine in certain environments but has lots of risks for large / complex environments. The blast radius of a human account is so much smaller than a machine account.

There are many valid reasons why companies provide carefully scoped API tokens connected to service accounts when running integrations (which are usually more deterministic and have undergone more testing). A similar approach to service account-backed and scoped API tokens would be extremely useful when deploying agents.