AISecOps governance note 02
Disabled Is Not Removed
Two Rovo disclosures show why agent governance cannot stop at an admin-console toggle. Security teams need to verify runtime capabilities, data reach, and egress independently.
Part 5 Agent Security Foundations
An administrator turns off web search for an enterprise agent. The interface reports that the feature is disabled. The agent still has a URL-retrieval capability that can send internal data to an attacker-controlled server.
Was web search disabled?
The honest answer is yes, in the product interface, and no, at the boundary the security team cared about.
That gap is the important lesson in two recent disclosures involving Atlassian Rovo. The incidents are easy to combine because both involve prompt injection and data exfiltration. They are not the same vulnerability, and one of them was fixed before publication.
Keeping them separate makes the governance failure much clearer.
Two attack paths, not one
Varonis Threat Labs called its vulnerability RovoBlast. The attack used Rovo’s rovoChatPrompt URL parameter to place attacker-controlled instructions into an authenticated user’s Rovo Chat session. A victim clicked a crafted link, Rovo processed the supplied prompt with the user’s existing access, and an agent capability could send retrieved data to an external destination.
Varonis disclosed the issue through Bugcrowd. Atlassian deployed a server-side fix on July 8, 2026, and the researcher validated it. This path was fixed before Varonis published its account and presented it at DEF CON 34.
PromptArmor disclosed a separate path. In that demonstration, a user uploaded a document containing concealed instructions and asked Rovo to perform a normal task involving Jira tickets. The agent searched Jira and Confluence, appended accessible information to an attacker URL, and opened the URL through its retrieval tool.
The user had to expose Rovo to the poisoned content and make the ordinary request. It is therefore misleading to describe the complete interaction as requiring no user action. The important point is narrower: once the poisoned content was in context, the exfiltration did not require a separate approval.
PromptArmor also reported that disabling organization-level web search did not break its chain because the setting did not remove the URL-opening capability the agent used. The company disclosed the issue to Atlassian on May 23, received an acknowledgment and case number, followed up twice, and published on August 5 after receiving no further substantive response.
PromptArmor said the path remained vulnerable when it published. I could not find an official Atlassian update establishing whether that specific document-injection path was fixed after August 5. That status should be described as unconfirmed, not indefinitely unpatched.
The Hacker News independently separated the two reports: the Varonis link path was closed, while the later status of PromptArmor’s content-borne path was not confirmed.
Neither disclosure reports exploitation against a real organization.
The toggle answered a different question
An admin setting named “Enable web search” sounds like a security boundary. It may only control whether the product deliberately searches the public web as a user-facing feature.
PromptArmor’s finding suggests that Rovo could still open a URL generated during an agent workflow. From a product-design perspective, those may be different capabilities:
search public websites for information
versus
open a URL produced during an agent taskFrom a defender’s perspective, both can create outbound communication. If the intended control is “this agent must not send data to arbitrary internet destinations,” turning off search is not proof that the requirement has been met.
This is not unique to Rovo. SaaS agents often expose several layers of state:
- features visible to users;
- connectors enabled for the tenant;
- tools available to the agent runtime;
- permissions inherited from the current user;
- internal tools used by the product but not shown in the console;
- network paths the vendor operates on the customer’s behalf.
The console may accurately describe one layer while the risk exists in another.
Configuration state is not effective state
Governance programs collect screenshots, exported settings, and questionnaire answers because they are available. Those artifacts establish declared configuration. They do not establish runtime behavior.
For an agent control, I want three separate records:
| State | Question |
|---|---|
| Declared | What does the admin console say is enabled? |
| Effective | Which tools, connectors, identities, and destinations can the agent actually use? |
| Observed | What did the agent invoke during a controlled test or production run? |
The three should agree. When they do not, the discrepancy is a finding.
This mirrors mature identity governance. A role definition says what access should exist. Effective-permission analysis calculates what access actually exists after groups, inheritance, and policy interactions. Activity logs show what was used.
Agent governance needs the same discipline.
Inventory capabilities at runtime
The first control is an inventory that goes deeper than named product features.
For each embedded SaaS agent, record:
- every first-party and third-party connector;
- the identities and scopes used for retrieval and action;
- tools exposed to the runtime, including internal tools;
- which tools accept agent-constructed URLs, commands, queries, or recipients;
- data sources reachable through the current user’s permissions;
- approval requirements for reads, writes, and outbound communication;
- whether disabling a feature removes the tool, blocks invocation, or only hides the interface;
- the telemetry available to prove the effective state.
An API export is preferable to screenshots. A signed tool manifest would be better. Where the vendor exposes neither, controlled behavioral testing becomes part of the assessment.
Ask the agent what tools it has, but do not treat its answer as authoritative. Exercise the boundary. Disable the feature, provide a harmless task that would require the capability, and observe whether the relevant call is blocked at policy enforcement or merely discouraged in the prompt.
The test should use synthetic data and an organization-controlled destination. The point is to verify the control, not to create a new exfiltration path.
Data reach defines the blast radius
Neither Rovo disclosure demonstrates a tenant-wide authorization bypass. The agent operated with information available to the signed-in user and connected services.
That is not a reason to dismiss the risk. It is a reason to measure the user’s actual reach.
An assistant that can search Jira, Confluence, Microsoft 365, Google Workspace, Slack, and other connected sources can concentrate access that was previously spread across several interfaces. A single user may legitimately see sensitive tickets, documents, messages, and connected application data.
The agent can retrieve and transform that information faster than the person. An attacker who influences the agent’s instructions inherits that speed and aggregation capability without first obtaining a new permission grant.
Useful controls include:
- narrowing connector scopes and indexed content;
- excluding secrets and high-risk repositories from general agent retrieval;
- applying user and group restrictions to agent features;
- using separate identities for broad search and consequential actions;
- preventing one agent task from silently expanding into every connected source;
- testing whether deleted or disabled connectors disappear from the effective tool set.
Least privilege still matters. The object receiving least privilege is no longer only the human account. It is the combination of user, agent, connector, tool, and task.
Treat egress as an agent permission
The PromptArmor path depended on Rovo opening an attacker-controlled URL containing retrieved data. Traditional SaaS governance often treats network egress as the vendor’s implementation detail. Agent systems make it part of the authorization model.
For every tool that can contact an external destination, ask:
- Can the model construct the hostname, path, query string, or body?
- Is the destination checked against an allowlist?
- Can retrieved enterprise data be placed in the request?
- Does the tool distinguish a URL retrieved from trusted configuration from one copied out of untrusted content?
- Is a person shown the destination and payload before sending?
- Does the audit record retain the full destination, source context, and result?
A web-search setting does not answer those questions.
The control should sit below the model. A policy service can allow approved vendor and integration endpoints, block arbitrary destinations, remove sensitive values from outbound arguments, and require approval when a task crosses from retrieval to transmission.
Markdown image rendering, link previews, remote attachments, webhooks, and research tools all deserve the same review. If rendering output causes the vendor to fetch a URL, output formatting has become network activity.
Detection needs the joined sequence
The valuable signal is not simply that Rovo read a Jira ticket or made an HTTP request. Both may be normal.
The suspicious sequence is:
externally influenced content
-> broad internal retrieval
-> agent-constructed external destination
-> request containing internal data
-> no explicit user approvalThe audit trail should retain the content source, user request, retrieved objects, connector identities, generated URL, outbound request, approval state, and response.
If the vendor does not provide that evidence, the absence belongs in the risk record. “The vendor operates the agent” is not an observability strategy.
Network controls outside the SaaS platform may not see server-side egress. That makes vendor telemetry, contractual commitments, and assessment evidence especially important. Security teams should ask whether customers can export agent tool-call records and whether those records include failed and policy-denied calls.
A test for every supposedly disabled control
The Rovo disclosures suggest a simple acceptance test for agent governance:
- Record the capability while enabled.
- Disable it through the supported administrative control.
- Enumerate the effective runtime tools again.
- Attempt a harmless use through direct prompting, indirect content, and another tool that may share the same primitive.
- Verify that policy enforcement blocks the action.
- Confirm the denial appears in an exportable audit record.
- Repeat after product updates and connector changes.
The expected result should be explicit. Does “disabled” mean hidden from the interface, unavailable to users, absent from the model’s tool list, denied by policy, or impossible at the network layer?
Those are different guarantees.
Vendor response is part of the control environment
Customers cannot patch most embedded-agent vulnerabilities themselves. They can reduce data reach, disable products, restrict groups, and monitor what the vendor exposes. The vendor owns the runtime change.
That makes disclosure handling operational evidence. Track:
- acknowledgment time;
- clarity of affected versions and paths;
- availability of temporary controls;
- time to server-side remediation;
- customer notification;
- validation that the fix covers the reported primitive, not only one payload;
- regression testing after the fix.
Varonis’s path has a clear record: disclosure, a server-side fix, researcher validation, and publication. PromptArmor’s public record is less complete. That difference is relevant without turning the article into speculation about motives.
Disabled should describe an enforced boundary
The lesson is not that every SaaS toggle is fake. The lesson is that a product setting and a security requirement are not automatically the same thing.
If the requirement is no public-web search, test search. If the requirement is no arbitrary outbound requests, inventory and test every URL-capable tool. If the requirement is no external disclosure of connected data, verify connector scope, output handling, rendering behavior, and egress policy together.
Security teams should be able to prove what an agent can do after a control changes. Until then, “disabled” is a statement of intent, not evidence of enforcement.