Home / Articles / What can your agent reach? RiskMandate and the Agent Behaviour Policy, explained for the person who has to decide / Versions / v1.3.0
What can your agent reach? RiskMandate and the Agent Behaviour Policy, explained for the person who has to decide: what changed in v1.3.0
From v1.2.0 (2026-10-18, e9fbb78e9) to v1.3.0 (2026-10-18, a94d326ad), paragraph by paragraph.
9 paragraphs added, 5 removed, 9 changed in place, 39 unchanged. About 1,496 words added and 727 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
6 unchanged paragraphs, under In short {#in-short}
• It already covershas policies for commercial agents. Claude with Gmail and Microsoft 365, ChatGPT, Google Workspace, Claude Code, GitHub Actions and more.
10 unchanged paragraphs, under The pages are hard to read {#pages}, What it is, in one paragraph {#what}
The test behind it is one sentence from abp.sgit.ai: "A control bounds a grant only if it is enforced by something the grant does not include." MostMuch of what organisationsgets callcalled an agent controlscontrol today areis the second row: an instruction in a prompt. AnHow much, in a given deployment, is something to measure, not assume; an honest behaviour policy says so.which row each control is in.
1 unchanged paragraph, under Yes, it reports what an agent can actually do {#inspect}
That is the right reading. And the reason it matters is that almostfew nobodypeople hashave seen the list.list for their own agents. RiskMandate's try-it page is thirteen prompts you paste into the assistant you already have connected to your mail. The first one asks it to list its own tools. In RiskMandate's words, "the list is longer than the tile that sold it." The second asks it to draft what you actually wanted it for, in three lists, wanted, refused, never mentioned; "the correction is almost always downward." The third writes the gap down. It takes about twenty minutes, and nothing is collected.
That is a self-report, and the site says so: the agent describing its own access is "the cheapest evidence there is, and the weakest." The paid levels go further. At the corrected level, the agent that holds the credential runs a published prompt that measures what the credential actually allows, in the fixed vocabulary, and the policy is built from that measurement, with every row marked as measured, documented or inferred. At the reviewed level, a person runs two sessions with your team and signs it. The levels are on the pricing page, from £10 for the pack to £1,500 reviewed. They are offerings, not a track record: the pricing page itself marks the £500 and £1,500 levels "specified, never run", as of 15 September 2026.
1 unchanged paragraph, under Does it work with commercial agents? {#commercial}
Yes, for the ones that matter most to most organisations. The library at riskmandate.ai has behaviour-policy vaults for Claude with the Gmail connector, Claude with the Microsoft 365 connector, Claude in the browser with connectors, Claude Desktop, ChatGPT in the browser, a Google Workspace MCP server, Gmail and Google Drive at read-only scope, a Dropbox MCP server, n8n with an owner API key, Claude Code on a machine and on the web, GitHub Actions, a browser extension and a scheduled job. Each is built from the vendor's own published pages, quoted and dated, or measured on a deployment we are entitled to run; where two vendor pages disagree, the disagreement is published rather than settled. That is a library of policies, not a set of integrations: in RiskMandate's own words, connectors to a customer's systems "are built per engagement", and "No connector is a product yet, and none is claimed as one."
4 unchanged paragraphs, under The enterprise assistant that sees too much {#oversharing}
Atlassian's documented design says it will not grant new access. Its trust page says "Rovo honors all existing permissions within each feature", and its privacy guidelines that users "will be able to see public documents and private documents that they already had access to." Connectors are set up by an administrator with broad rights, and then each user links their own account, so answers are filtered by what that person can see. I take that at face value. The risk is not in that sentence; it is in four places around it.
1. Access that was always too wide becomes easy to find. Atlassian's own connector guide warns that "unrestricted content may appear in search results or be used by Rovo Agents or Rovo Chat", and tells administrators to "verify what data each app indexes". Microsoft says the same about its own assistant: "By default, SharePoint sets sharing settings to the most permissive option," and the first steps of getting ready for Copilot are about oversharing. A Google Drive file shared as "anyone with the link" was safe while nobody knew the link; Atlassian's Drive connector makes it findable by teammates when the link appears somewhere Rovo can read, such as a Confluence page or a Slack message. Nobody's permissions changed. What changed is that everything they already allowed is now one question away. 2. Some paths run as somebody else. When a Rovo agent runs from Jira Automation, it uses the permissions of the automation's connection user, typically whoever created the rule, not the person who triggered it. In Atlassian's own tracker, a customer reported that the agent's Confluence results then include links to pages the triggering user cannot view; Atlassian answered that "this is intended behaviour", and dedicated agent accounts are planned. That is exactly the shape the question was about: output reaching someone who did not have access to the source. 3. Who can build agents is wide by default. By default all users can create Rovo agents, and new agents are open to all users; administrators can narrow it to selected groups, and customers have asked Atlassian to change the default. 4. An agent can be talked into sending data out. In August 2026, a security firm published a prompt injection in which a hidden instruction in an uploaded file makes Rovo send data to an outside address, "even if an organization has disabled web search for Rovo"; I found no statement from Atlassian on a fix. That is not Rovo widening permissions. It is Rovo using a legitimate user's access for someone else's purpose, which is the same risk every assistant with tools carries.
Written as a behaviour policy, a Rovo agent's grant is the union of what the person invoking it can see across Atlassian and every connected app, or the rule creator's access when it runs from an automation, plus what its tools can create and change. Its mandate is what it was built for: answer questions about this project's tickets, say. The delta is everything else it can reach, and for most organisations that is most of the company. And the barrier column sorts the controls honestly. Permission filtering is a boundary, but one the vendor holds and can change in a release. The administrator's allowlists for which drives and sites are indexed, the setting for who may build agents, and the read and write switches on Atlassian's MCP server are boundaries the organisation holds. The agent's instructions are an expectation. Atlassian's own governance tools, classification, redaction of sensitive data and audit logs, sit in the boundary row too, on the plans that include them; agent identities with "explicit, role-scoped access that can be audited and revoked independently" are, in Atlassian's words, coming soon.
For due diligence on a contract, that turns the vague question into five specific ones. Which connectors are on, and with whose rights were they set up? What is indexed, and has anyone reviewed what was already over-shared? Which automations run agents, and as whom? Who may build agents? And which of the controls above are in the plan being bought? Those answers are the behaviour policy for that deployment, and the gap they reveal is what somebody has to accept, by name, for a period, or fix.
Atlassian's documented design says it will not grant new access. Its trust page says "Rovo honors all existing permissions within each feature", and its privacy guidelines that users "will be able to see public documents and private documents that they already had access to." I take that at face value. How a connector is set up, indexed and authenticated depends on the kind of connector: Atlassian distinguishes synced connectors, which "store and index all the content in a workspace using a service or admin account", direct connectors, whose content "is retrieved live through the provider's search APIs", and Smart Link connectors, which need no administrator setup. The risk is not in that sentence; it is in four places around it.
1. Access that was always too wide becomes easy to find. Atlassian's own connector guide warns that "unrestricted content may appear in search results or be used by Rovo Agents or Rovo Chat", and tells administrators to "verify what data each app indexes". Microsoft says the same about its own assistant: "By default, SharePoint sets sharing settings to the most permissive option," and the first steps of getting ready for Copilot are about oversharing. A Google Drive file shared as "anyone with the link" was hard to find while nobody knew the link; Atlassian's Drive connector makes it findable by teammates when the link appears somewhere Rovo can read, such as a Confluence page or a Slack message, while "Google Drive sharing settings still apply." Nobody's permissions changed. What changed is that everything they already allowed is now one question away. 2. Whose permissions apply depends on how the agent is invoked, and as whom. Creating or sharing an agent does not hand its creator's access to everyone who uses it. Atlassian documents an identity setting for each agent with two options. With *User's account*, "the agent adopts the identity of the user who's interacting with, or automating, the agent": in chat, that is the person asking, and a knowledge source still "respects the permissions of the user who prompted it". In an automation, it is the account on the rule's connection: Atlassian says agents there "always use the permissions of the connection user in the automation", which may be whoever set the rule up, another user or a service account, and is not necessarily the agent's creator or the person who triggered it. With *Agent's account*, the agent runs with access granted to its own identity, and Atlassian's safety guidance is plain: "Any spaces or content that are shared with the agent are also shared with any manager, editor or user of the agent." So the risk is a process that reads with one identity and publishes to an audience with less access. In Atlassian's tracker, ROVO-837, a customer reported that an automation posted Rovo's answer into a ticket with a link to a Confluence page the triggering user could not open; opening the link still gave a permission error, setting the rule to run as the triggering user did not change the lookup, and Atlassian answered that "this is intended behaviour". That is a link to a restricted page disclosed, not the page itself, but it is the shape the question was about. 3. Who can build agents, and who can use them, are wide by default, and controlled differently. By default all users can create Rovo agents, and a new agent "becomes available for everyone to see and use". Administrators can limit who creates agents to selected groups; limiting who uses a particular agent is done person by person, because, in Atlassian's words, "Restricting agent access to specific groups or teams is currently not supported." 4. An agent can be talked into sending data out. On 5 August 2026, a security firm published a prompt injection in which a hidden instruction in an uploaded file makes Rovo send data to an outside address, "even if an organization has disabled web search for Rovo". That is a reported attack as of its publication; I found no statement from Atlassian on a fix, and could not verify whether it still works today. That is not Rovo widening permissions. It is Rovo using a legitimate user's access for someone else's purpose, which is the same risk every assistant with tools carries.
Written as a behaviour policy, a Rovo agent's grant is what its executing identity can reach across Atlassian and every connected app: the person asking, in chat; the connection account, in an automation; or the agent's own account, if it has one; plus what its tools can create and change. Its mandate is what it was built for: answer questions about this project's tickets, say. The delta is everything else it can reach. It can be large, and it has to be measured for the particular deployment rather than assumed. And the barrier column sorts the controls honestly. Permission filtering is a boundary, but one the vendor holds and can change in a release. The setting for who may build agents is a boundary the organisation holds. So are the administrator's allowlists for which drives and sites are indexed, though they govern what is indexed, not everything Rovo can fetch at run time through the user's access; and the read, write and search switches on Atlassian's MCP server, which govern what that server can do, not, on Atlassian's page, every Rovo chat or automation. The agent's instructions are an expectation. Atlassian's governance tools do different jobs, on the plans that include them: blocking and redaction of sensitive data can stop it entering or leaving a path, which is a boundary; classification labels mark sensitivity, and bound something only through a policy that acts on them; audit logs record what happened, which is evidence for an investigation, not a barrier that prevents anything. Agents with their own accounts are now documented; on 6 October Atlassian announced that "Soon, we're adding controls around what is visible to AI and what it can access with agent accounts and non-human identity inventory." Which of these a given organisation has is something to check in its own tenant.
For due diligence on a contract, that turns the vague question into five specific ones. Which connectors are on, and with whose rights were they set up? What is indexed, and has anyone reviewed what was already over-shared? Which automations run agents, as which connection account, and which agents run on their own accounts? Who may build agents, and who may use each one? And which of the controls above are in the plan being bought? Those answers are the behaviour policy for that deployment, and the gap they reveal is what somebody has to accept, by name, for a period, or fix.
To check a real deployment rather than read about one: look at each agent's identity setting in Studio; establish how each is invoked, chat, an automation or another integration; read the account on each automation's Rovo connection, separately from the rule's actor and owner; list what that account can read and who can see the output it writes; and test it, with a restricted page holding a unique phrase, asked for in chat and through the automation, to see whether the phrase or the page's link comes back.
2 unchanged paragraphs, under Is it real time? {#realtime}
Real-time enforcement belongs to the things that sit in the path: an identity provider, a gateway, a proxy, a hook, the agent's own runtime. And here the newer work has something to show. In October, Mondweep Chakravorty took an ABP, compiled it into Ruflo's own policy rules, and enforced it in Ruflo's evaluator,it, in real time, on everythe memory operation;operations of an external adapter, using a pinned copy of Ruflo's evaluator; the page documenting it was merged into Ruflo. By its own account, it does not alter Ruflo's running policy configuration and does not restrict other shell or MCP tools; it governs what goes through that adapter. This newsroom's own agent runs under an ABP whose rules are partly enforced by hooks, as it works. The policy is the description; the runtime is the enforcer; the barrier column says which rules have one.
2 unchanged paragraphs, under Beyond what it can reach: who decides {#decisions}
To make it something you can see rather than read, we built the refund as a twin: the Northstar refund twin, thirteen synthetic refund requests through four designs of the controls, every decision played and replayed. TheIt is a scripted simulation: invented orders, scripted mistakes, no model called. In it, the design with a limit and good logs overpays $458 in a day;day, and the design with three policies gets all thirteen right. That illustrates how controls interact; it is not evidence of how often a real agent makes each mistake. Allowed is not right walks through it. It takes five minutes, and it is a quick way to show someone that a control that works can still produce the wrong outcome.
3 unchanged paragraphs, under How does it get into the room? {#room}
1. A contract. Legal and procurement doing due diligence on a vendor's agent need to know what it will reach and do with the organisation's data. The behaviour policy for that deployment is that answer, with every barrier marked as yours or the vendor's.
2. A security questionnaire. A startup's first serious enterprise customer will ask which of its agents touch their data and how they are bounded. A behaviour policy answers in rows, not assurances. RiskMandate has a page for startups and one for founders, who will be diligenced on their agents before long.
3. An insurance renewal. RiskMandate's starting point is that carriers are moving to exclude AI from cover, and that what buys cover back is evidence an underwriter will accept. Make your agents insurable sets out the argument; the CFO and the broker are in that room already.
4. The board's risk appetite. UnderFor companies the UK Corporate Governance Code,Code applies to, boards already have to determine the principal risks the company is willing to take. Every board asks the same question about an agent, in one sentence: who can pull the plug, how fast, what breaks, and what can't be undone. RiskMandate's answer is that a deployed agent's risk cannot be denied, only accepted, by a named owner, for an interval, with an expiry that brings the decision back.
5. Twenty minutes. For the individual, the thirteen prompts. It is the cheapest way to move someone from the second group to the first, because the list of what their own assistant can reach is the surprise.
5 unchanged paragraphs, under What I would like to hear back {#back}, What this does not claim {#limits}
• The injection report is a third party's. We found no statement from Atlassian on its status.
• The injection report is a third party's, and historical. We found no statement from Atlassian on its status, and did not verify whether it works today.
• Rovo's identities are from Atlassian's documentation. Not tested in a tenant; the five checks above are how to test one.
• The Northstar figures are a simulation. Thirteen synthetic cases, scripted, no model called.
• RiskMandate's top two levels have not been run. As its own pricing page says, as of 15 September 2026.
5 unchanged paragraphs, under Where this comes from {#sources}
riskmandate.ai, version 1.38.8, and abp.sgit.ai, version 0.12.1, both read on 18 October 2026: in particular the barrier model, the try-it page, the pricing and the library of behaviour-policy vaults, the grant-gap, licence to operate, plug and insurance pages, and how it works. The Rovo section is from the vendors' own pages and one third-party report, read on 18 October 2026 by a research agent: Atlassian's Rovo data privacy guidelines, trust page, connector admin guide, Google Drive connector, agent permissions and governance, the tracker entry ROVO-837 on automation identity, configuring an agent's identity, knowledge sources for agents, best practices to automate agents safely, connector types, MCP server permissions, the 6 October 2026 announcement, and the blog post Don't build AI governance from scratch, 14 August 2026; Microsoft's SharePoint Advanced Management guidance for Copilot; and PromptArmor, Atlassian Rovo exfiltrates data, 5 August 2026, a third party's report. A review by ChatGPT, run by Dinis on 18 October 2026 and checked against these pages, corrected the Rovo section in v0.12.122; it is on the record below. Related on this site: three policies for an agent, allowed is not right, our first PR in Ruflo, hope or enforcement. Written up and checked by this site's agent; the editorial responsibility is mine.