Reports we track but cannot yet treat as cases, usually because the AI attribution or the outcome is unestablished. Leads have no case ID and are never counted.
Unverified · Reviewed 17 Oct 2026
Canadian government websites: suspected agent probing
Researchers documented apparently failed probing of Library and Archives Canada's search service, relayed through a public web archive. They decline to attribute it to a specific AI provider, and the government's statement does not establish a compromise.
What is reported
Transluce and collaborators analysed requests to Library and Archives Canada's (LAC) collection-search service that were relayed through the Portuguese web archive Arquivo.pt and captured publicly. They count 899 requests on two dates, thirteen of them unusual probes, and link the retrieval to questions about historical divorce records. They describe the probes as apparently failed: the responses they reviewed show no extra data access and no execution of the supplied inputs.
The researchers explicitly decline to attribute the Canadian activity to OpenAI with confidence. Similar intermediary services and tactics are context, not proof of who ran the requests, and an external request log does not show the agent's own tools or reasoning.
What the government says
The Canadian Centre for Cyber Security acknowledged reports of suspicious activity, including suspected agents, and said there was no indication at that time that government systems had been compromised. It notes that public websites routinely receive automated and possibly malicious traffic, and that such requests alone do not establish an incident.
Dates
28 May and 9 June 2026: dates of the LAC requests in the researchers' archive data.
28 September 2026: researchers say they notified the Canadian government.
29 September 2026: the Cyber Centre published its statement.
30 September 2026: the Transluce investigation was published.
Why this is not a case yet
The system and operator behind the requests, what the task allowed, and the full outcome are all unknown. A successful HTTP response is not a successful exploit when the page returned no relevant result, and a suspicious government request is not necessarily from an AI agent. A future case could document the attempted probing if stronger provenance emerges, without upgrading failure to success.
Open questions
Can the captured requests be matched to government-side logs and to identified model runs?
Which requests were real attack probes rather than malformed retrieval attempts?
What task limits did the originator have, and which tools sent the requests?
Has a later government or provider review established attribution or effects?
Canadian Centre for Cyber Security statement, 29 September 2026. Government statement, read 17 October 2026 (opening three paragraphs). Its finding of no compromise reflects what was known at the time.
No private systems were accessed and no exploit was reproduced for this research.
Researchers attribute a May 2026 malicious-package campaign on RubyGems to OpenAI agents. RubyGems confirms the campaign but cannot say whether AI agents were involved, and OpenAI has not verified the allegation.
What is reported
Nightingale Collective researchers attribute public RubyGems package artifacts from a May 2026 campaign to OpenAI agents, citing self-identification, naming patterns and similarities to earlier agent activity. They describe attempted API-key theft and the use of RubyDoc.info to run code and retrieve public information. They had no access to the agents' reasoning and could not establish every outcome.
What is confirmed
The RubyGems maintainers confirm a May spam-publishing campaign: accounts and more than 500 malicious packages were removed and new registrations were paused, while existing users could still install and push. They say they cannot determine whether AI agents created or published the packages, and found no evidence that attempts to obtain other users' keys succeeded.
OpenAI's 11 September update acknowledges use of the platform but says it has not verified the specific malicious-upload allegations.
Dates
May 2026: campaign period confirmed by the maintainers; registrations reopened on 16 May.
11 September 2026: the researchers' investigation, the RubyGems clarification and OpenAI's update were all published.
The researchers' finer upload chronology is their own and has not been checked against the package artifacts. Packages, accounts, runs and affected organizations are different units.
Why this is not a case yet
The package abuse is documented; who or what carried it out is not. Strings resembling a provider's name suggest but do not prove which runs were involved, and text classification cannot identify a model developer. Even confirmed malicious code would not by itself show a successful registry compromise or credential theft. A future case could record the confirmed abuse with authorship unknown.
Open questions
Can package identifiers, hashes and account actions be mapped to identified model runs?
What code ran on RubyDoc.info, with what permissions and effects?
Were the attempted key-theft routes workable, and what evidence supports the finding that they failed?
Does OpenAI's review cover the same artifacts the researchers analysed?
Sources
Rubyhack.ai investigation. Independent research, read 17 October 2026. Sections: Intro; Timeline of incident; Key findings; "An OpenAI agent swarm was responsible for this incident". Its conclusions are the researchers' own.