AI Moves Deeper Into Cybersecurity, Policing and Personal Devices

GOLD EAGLE Coordinates Cyber Flaws

Finding a software vulnerability is only the beginning. The harder problem is getting the right organisations to verify it, share enough information and fix it before somebody exploits it.

On 14 July, the White House launched GOLD EAGLE, a clearinghouse intended to coordinate that process across the US government, critical-infrastructure operators and open-source software communities. Treasury and the Department of Homeland Security, including CISA, are among the participating agencies.

The plan is to receive vulnerability reports, verify and prioritise them, then coordinate remediation. The White House also says frontier AI will be incorporated into that work. The announcement doesn’t spell out exactly where AI will sit in the pipeline, but plausible uses include sorting large numbers of reports, correlating related flaws and helping analysts decide which vulnerabilities deserve attention first. Those are possible applications, though, not demonstrated results from GOLD EAGLE.

What’s notable here is the shift from AI-and-cybersecurity policy to an operational coordination mechanism. Vulnerability handling often crosses awkward institutional boundaries. A flaw might be found by an independent researcher, live inside an open-source dependency, affect several infrastructure operators and require action from vendors that don’t share the same incentives or disclosure rules.

A clearinghouse could reduce some of that friction. Its value will be measured in fairly practical terms: how quickly reports are validated, whether maintainers receive useful help, and how long fixes take to reach deployed systems.

There are also unresolved questions. Private participants will want to know what information they’re expected to share and who can access it. Open-source maintainers may need engineering resources rather than another stream of alerts. And using AI in prioritisation creates its own need for oversight, particularly if an automated system underrates an unusual but serious flaw.

For now, this is a launch announcement. There’s no operational performance data yet, so the structure is consequential, but its effectiveness remains unproven.

AI Enters Criminal Evidence Review

The next development moves AI into an even more sensitive decision chain. The UK Home Office has accepted recommendations supporting legislation that would allow police to use AI to review and summarise evidentiary material.

The reforms announced on 14 July also propose centralised technology procurement and a national governance forum. The wider PoliceAI programme has £75 million in government funding.

This doesn’t mean AI-written evidence summaries are already deployed throughout UK policing, or that courts have accepted them as evidence. It’s a policy commitment and legislative reform process. That distinction matters because the safeguards will determine whether the technology saves time without weakening defendants’ rights.

Criminal investigations can involve enormous collections of messages, documents, video, audio and other digital material. Software that helps investigators find relevant items could reduce delays. Summarisation might also make large case files easier to navigate. But a fluent summary can conceal what it omitted, and an error in this setting isn’t merely inconvenient. It could affect disclosure, defence preparation or a person’s ability to challenge the case against them.

Human verification therefore can’t be treated as a ceremonial final click. Reviewers need access to the underlying material and a clear record of what the system processed, what it selected and how its output changed. Defence teams also need a workable way to inspect and challenge that process. If only police and prosecutors can interrogate the tool’s handling of evidence, the information imbalance becomes part of the legal problem.

Central procurement could produce more consistent technical and security standards than a patchwork of local purchases. It could also concentrate dependence on a small number of systems. The coming legislation and governance arrangements will need to define audit trails, responsibility for mistakes and the status of AI-generated summaries. Those details will tell us far more than the size of the funding commitment.

AWS Maps the AI Attack Surface

Over in cloud security, AWS is starting to treat models, agents and inference activity as assets that need their own monitoring layer.

GuardDuty AI Protection, announced on 14 July, monitors activity in Amazon Bedrock and SageMaker. AWS says it can flag anomalous model invocations, attempts to exploit somebody else’s account to run up inference costs, and prompt-injection findings supplied through Bedrock Guardrails.

That inference-cost scenario is worth noticing. Stolen cloud access has long been used for cryptocurrency mining and other compute-heavy abuse. Generative AI creates another valuable workload for an attacker: run expensive model requests through a compromised account and leave the account owner with the bill.

Prompt injection is a different problem. It involves crafted instructions that try to make a model or agent ignore its intended rules, reveal information or take an unsafe action. GuardDuty isn’t independently discovering every such attack from scratch here. The announced capability can consume findings generated by Bedrock Guardrails and bring them into a broader security view.

AWS also expanded Security Hub so organisations can inventory AI resources across Bedrock, AgentCore and SageMaker. According to AWS, it can identify some self-hosted frameworks, including Ollama, vLLM and Hugging Face TGI, using software inventories from Inspector. It can also infer the use of external AI APIs from DNS telemetry collected by GuardDuty.

That inventory function addresses a growing organisational headache. A security team can’t assess an AI service it doesn’t know exists, and experimental deployments have a habit of becoming unofficial production infrastructure. Finding an old endpoint or an unapproved external API connection may be as useful as detecting an active attack.

Still, these are AWS’s capability claims, with no independent detection-rate testing in the briefing. Visibility depends on the AWS services and telemetry an organisation has enabled. Inferences drawn from DNS activity may reveal that an external service is being contacted without explaining what data was sent or whether the use was legitimate. The tools could provide a valuable map, but security teams will still have to interpret it.

OpenTitan Plans for Memory and Quantum Threats

At the hardware layer, OpenTitan has outlined the direction for Earl Grey 2, the next generation of its open-source silicon root of trust.

A root of trust is the protected foundation a device relies on for jobs such as secure boot, key storage and checking that firmware hasn’t been tampered with. If that foundation fails, protections higher up the software stack can become irrelevant.

The roadmap published on 14 July brings together two important security ideas. The first is CHERI-based memory protection. CHERI uses hardware capabilities to restrict how software can access memory, aiming to prevent whole classes of bugs involving invalid or overly broad memory access.

The second is hardware support for ML-KEM and ML-DSA, the post-quantum standards designed for key establishment and digital signatures. These algorithms are intended to resist attacks from future cryptographically relevant quantum computers. Earl Grey 2 is also planned to include RRAM and further security hardening.

Combining memory protection and post-quantum cryptography inside a root of trust is an ambitious design direction. It could give future devices stronger protection against common implementation flaws while preparing their cryptographic foundations for a longer-term threat.

But this remains a roadmap. The supplied material doesn’t establish a release date, production availability or completed validation. Silicon security also depends on implementation, verification and integration, not merely support for the right standards. The announcement shows where OpenTitan wants to go; it doesn’t yet provide a finished chip that manufacturers can deploy.

Pixel Gets an Offline Multimodal Model

Meanwhile, Google is pushing more multimodal AI work off the cloud and onto the phone itself.

On 13 July, Google introduced Gemma 4 E2B for TPU, a lightweight model designed to run on Pixel Tensor hardware. Google also opened a beta-access process for its Tensor SDK and demonstrated offline capabilities including multimodal chat, transcription, image recognition and device actions.

Multimodal simply means the model can work across more than one kind of input, such as text, images and audio. Running that model locally can reduce the need to send every prompt or recording to a remote server. It can also keep some features working without a network connection and avoid cloud-inference delays.

For agent-style software, local execution opens up interesting possibilities. A phone could interpret an image, transcribe speech and carry out a supported device action without making a round trip to a data centre. Keeping processing on the device may also improve privacy, provided the surrounding application handles stored inputs and outputs carefully.

The present release is narrow, though. Google says TPU support is limited to the Pixel 10, Pixel 10 Pro, Pixel 10 Pro XL and Pixel 10 Pro Fold. The SDK workflow is in beta, so this is an early developer opportunity rather than general Android availability.

There’s no independent assessment in the briefing of model quality, battery consumption, thermal impact or the reliability of device actions. Those practical constraints can determine whether an on-device demonstration becomes a feature people actually trust. Even so, putting multimodal inference and actions together on consumer hardware is a meaningful step towards useful offline agents—initially for a small slice of Pixel owners and developers.

Bot Detection Watches the Whole Session

As agents get better at using websites, Cloudflare is changing where it looks for signs of automation.

Precursor, announced as generally available on 13 July, analyses browser-interaction patterns across an entire session. That differs from a one-time CAPTCHA, which asks for proof at a single point and then usually lets the session continue.

Cloudflare says Precursor examines aggregate timing and cadence signals rather than recording the actual keys somebody presses. It can be enabled through script injection without changing application code. The intended targets include automated scraping, account abuse and checkout fraud from bots capable of navigating modern browser interfaces and passing conventional challenges.

Continuous analysis makes sense against automation that behaves convincingly for a few seconds but reveals patterns over a longer visit. It may also let a site respond to suspicious behaviour after a session begins rather than forcing every visitor through the same challenge upfront.

There are important qualifications. The privacy description and effectiveness claims come from Cloudflare, and the briefing contains no independent evaluation. Eligibility and pricing weren’t specified. Behavioural systems can also face a difficult trade-off between catching sophisticated bots and misclassifying people whose interaction patterns fall outside the expected range.

Coverage is another boundary. This protection concerns browser sessions routed through Cloudflare; the announcement doesn’t claim equivalent detection for direct API traffic. Site operators still need separate controls for exposed APIs, stolen credentials and automation that bypasses the browser entirely.

What Changes for You

One smaller change may immediately save some people a surprising amount of digging. On 14 July, OpenAI added unified ChatGPT search across previous chats, projects, uploaded documents and images, with filters for different content types.

OpenAI says the feature is available globally on every ChatGPT plan through the web, iOS and Android versions. If you use ChatGPT for ongoing research or development work, you no longer have to remember which particular conversation contains a file, generated image or useful troubleshooting exchange. Projects and archived chats can function more like a searchable working record.

The scope is strictly material stored inside ChatGPT. OpenAI’s announcement doesn’t say this search reaches connected applications, cloud drives or other external sources, and desktop applications aren’t listed. It also doesn’t change the privacy decision involved in storing work there. Search makes retained material easier to recover; it doesn’t make sensitive documents more appropriate to upload.

So the practical change is straightforward: web and mobile users on any plan can search across more of their existing ChatGPT workspace from one place. The main constraint is still deciding which conversations and documents should become part of that stored record in the first place.