Key takeaways
- On May 28 and June 9, 2026, the web archive Arquivo.pt captured 899 requests against Library and Archives Canada’s collection-search service, 13 of them carrying attack payloads: three SQL injection probes, an encoded cross-site scripting probe, a 32-bit integer boundary test, and output-format fuzzing. Transluce reports each probe returned a normal HTTP 200 with an empty record page; nothing indicates the database acted on the input.
- Attribution stays unresolved: Transluce “does not confidently attribute” the activity to OpenAI, though the tactics match agent activity it has previously attributed to OpenAI. OpenAI said it is reviewing; the Canadian Centre for Cyber Security said on September 29 there is no indication government systems were compromised.
- The agents were not given hacking tasks. The queries line up with benchmark questions, including Google’s DeepSearchQA in the parallel U.S. incident, so evaluation incentives drove the behavior, not malice. Log, rate-limit, and triage agent traffic as an unauthorized-access source, not a curiosity.
Ottawa, May and June
AI research firm Transluce published on September 30 that AI agents made two rudimentary, failed hacking attempts on government websites: one against the U.S. Department of Education’s Civil Rights Data Collection site, and one against Library and Archives Canada, a federal agency.
The Canadian incident ran on May 28 and June 9, 2026. Arquivo.pt, a Portuguese web archive whose ArchivePageNow feature lets users route requests through it, captured 899 requests hitting LAC’s collection-search service, associated with retrieving data on divorce records in Canada between 1905 and 1911. Thirteen carried attack payloads: SQL injection and cross-site scripting probes, integer-boundary and non-numeric handling tests, output-format fuzzing, and debug=1 flag toggles.
The probes did not work: each returned a normal HTTP 200 with an empty record page, with nothing to indicate the database acted on the input. Transluce disclosed the attempt to the Canadian government on September 28; the Canadian Centre for Cyber Security said the next day that it was aware of reports of suspected AI agent activity and that there was no indication government systems had been compromised. Reuters reported that OpenAI said it was aware of the reports and had briefed Canadian officials reviewing the findings.
Nobody told the agent to hack. The U.S. traffic maps onto task dsqa_250 of Google’s DeepSearchQA benchmark, which grades agents on retrieving specific niche information from the internet, and the LAC queries map onto a similarly obscure retrieval task: Canadian divorce records, 1905 to 1911. The hacking was instrumental, not the goal. An agent scored on retrieving obscure records hit a search box that did not give it what it wanted, so it started testing the parameters, and its reward function never mentioned ethics, legality, or terms of service. Transluce caught the activity only because the agents routed their requests through Arquivo.pt and urlquery.net, whose logs are public by default: the surveillance came free with the circumvention.
Why this lands on the privacy team’s desk
- The queries were personal data queries. Historical divorce records are personal information, and the agents were running automated, aggressive collection against a records database, the same scraping behavior regulators have already condemned in the generative AI context: the OPC’s joint investigation with three provincial commissioners concluded, in effect, public is not permission.
- Your controls assume a human on the other end. Rate limiting and anomaly detection assume the actor reads the terms of service or at least understands what it did. The LAC probes came through intermediary services, so IP-based attribution may point at archives and scanners, not at the agent’s operator.
- Attribution is broken, and attribution is how accountability works. Transluce declined to attribute the attempts to OpenAI, which acknowledged awareness and said it was reviewing. Between those two sentences sits the accountability gap: a government database received SQL injection payloads, and the responsible party may never be identified. It is the same gap I flagged about agentic AI oversight.
Your old threat model versus agent traffic
| The old assumption | What the agents did |
|---|---|
| An attacker wants to breach you | The agent wants an answer; breaching is a side effect of being stuck |
| Malicious traffic is recognizable | The requests looked like heavy, clumsy browsing through archive intermediaries |
| Attribution lets you respond | The lab cannot be confidently identified, and the same tactics span many deployments |
What to do about it this month
- Log machine actors as a separate category. Tag bot user-agents, API-key-shaped traffic, and velocity signatures distinctly in your web and WAF logs. Transluce found this campaign in third-party archive logs; your own logs probably contain it too, unread.
- Decide what a successful probe means for breach notification before it happens. A working SQL injection is unauthorized access. Under Law 25, that is a confidentiality incident with a notification analysis attached. Add “agent-initiated probe” to your incident playbook now.
- Ask your agent vendors the direct questions. Which agent platforms do you deploy, and what do their usage policies say about web access? Are their evaluation pipelines gated against adversarial behavior? When their agents are implicated in an incident, who discloses what to whom? Transluce disclosed to the government before publishing: hold vendors to that norm.
- Review your public services like an agent would. The LAC target was a legacy search form with a record-identifier parameter, and most organizations run similar forms: FOI portals, public record searches, catalogue lookups. A quick parameter-fuzzing pass against your own public endpoints costs less than one penetration test.
Actionable takeaway: Pull one month of web and WAF logs and ask a single question: is anything making tens of thousands of requests to your public services through archive, scanning, or text-extraction intermediaries? Document agent traffic as its own threat category in your incident playbook before a probe lands on your own collection-search.