A short post lands in your feed. Five people at U.S. Cyber Command died by suicide in a single month. A four-star general is named. A dollar figure is attached to an unfunded mental-health request. The command, the post says, has linked the deaths together.

It reads like reporting. It has dates, names, numbers. And two of those details are wrong.

The general’s name is misspelled in a way that would send you to an empty search result. And the claim that the command “linked” the deaths misstates the single most important fact in the story: officials have not established that the deaths are connected. That distinction is the difference between a workforce tragedy and a conspiracy.

This is what most disinformation looks like in 2026. Not fabrication, but a real story that loses precision every time it is summarized, translated and reposted. The underlying reporting here is solid. What reaches you is a degraded copy. Learning to verify a defense story against primary sources is not an academic exercise — it is the difference between amplifying journalism and amplifying noise.

What does “suicide cluster” actually mean?

Start with the term itself, because it is doing the heaviest lifting and it is the term most often misread.

A suicide cluster is an administrative and epidemiological designation, not a causal one. It means deaths have occurred closer together in time than statistical expectation, in a defined population, at a rate that triggers a specific institutional response. Declaring a cluster does not assert that the deaths share a cause, that the people knew each other, or that anything links them beyond timing. It is a threshold for intervention.

Bloomberg reported on 6 August 2026 that as many as five people who worked for or closely with U.S. Cyber Command died by suicide between early June and early July, based on internal military communications, public records and officials. The command applied the cluster designation because of the compressed timeframe. Coverage consistently notes that officials have not determined the deaths are connected.

Note the hedge in the original: as many as five. Not “five.” The number in the summary post has hardened into a fact it was never reported as.

How do you trace a claim back to its primary source?

The following process took under an hour and requires nothing but a browser. It works on almost any defense or intelligence story.

1. Identify the originating outlet, not the outlet you read. The post in your feed cites “sources of the broadcaster” or nothing at all. Search a distinctive phrase from it. In this case every downstream version — Japanese, Azerbaijani, Iranian, Russian — traces to one Bloomberg article. Everything else is aggregation. If you cannot find an originating outlet, that is your finding.

2. Correct the proper nouns first. Names are the cheapest thing to check and the most revealing when wrong. The commander of U.S. Cyber Command is General Joshua M. Rudd, confirmed by the Senate on 10 March 2026 by a vote of 71-29, serving simultaneously as Director of the National Security Agency. He is not “Joshua Rad.” A misspelled principal is a reliable signal that the text has passed through several hands, at least one of which was working from audio or a machine translation.

3. Go to the institution’s own publications. Cybercom.mil hosts Rudd’s full posture statement to the Senate Armed Services Committee, dated 28 April 2026. It confirms that the command supports U.S. Central Command and U.S. Special Operations Command “in their campaigns to counter Iranian aggression,” and that it participated in Operation Absolute Resolve in Venezuela. Primary documents also tell you what is absent: the posture statement makes no mention of the suicides or the mental-health funding request, which is consistent with a document written months earlier.

4. Check the congressional record separately from the reporting about it. Senator Roger Wicker’s own site publishes his opening statement from that hearing verbatim. The relevant passage: “Our cyber operators are working overtime, and we are not ready to generate new forces to replace them. I am troubled that this effort is not moving fast enough. Current operations will always be priority number one, but we must ensure this pace is sustainable.” The summary post paraphrased this accurately. That is worth confirming rather than assuming.

5. Separate what you verified from what you could not. The same post attributes a statement about the Iran war to Senator Jack Reed at that hearing. I could not locate a primary source for it. Cyber Command’s involvement in operations against Iran is independently documented — DefenseScoop reported in March 2026 that Rudd took command while Cybercom was supporting Operation Epic Fury — but the specific attribution to Reed remains unconfirmed. Say so, in those words. An honest gap is stronger than a smoothed-over one.

6. Find the institutional record that predates the news. This is the step most people skip, and it is the one that changes the story. U.S. Cyber Command published its own account, through DVIDS, of embedding licensed mental-health providers inside its Fort Meade spaces. The open house was 11 May 2026; clinical care began 12 May. In it, Major CJ McAulay, the command psychologist, drew the comparison to special operations directly: both communities are “always in the fight,” but where SOF personnel rotate between training, deployment and recovery, cyber personnel are “almost never out of the fight.” He named the cost — “the personnel price of persistent engagement is real” — and its shape: disrupted sleep, exercise, nutrition and social interaction.

That statement was published by the command itself, weeks before the deaths, and it is the strongest available evidence for the workload interpretation. It is also the piece the viral summary rendered most vaguely.

Common errors along the way. Treating an aggregator as a source. Trusting a number that arrives without its hedge. Reading “cluster” as “connected.” Accepting a paraphrased quote when the verbatim text is one search away. And the subtler one: stopping once the story is confirmed, instead of continuing until you understand what it means.

Expected result. A version of the story you can defend line by line, with a short, explicit list of what you could not confirm.

Why this matters beyond one story

For newsrooms and independent publishers, the practical takeaway is that the verification cost of a story like this is roughly an hour, and skipping it produces text that is confidently wrong about the only thing that matters.

For anyone tracking defense and intelligence topics, the structural lesson is different. High-demand, low-density military communities — special operations, drone crews, now cyber operators — have produced comparable episodes before. The public record here does not require inference. A committee chairman said the pace was unsustainable in April. The command’s own psychologist described the mechanism in May. The commander placed mental-health sustainment second on his unfunded priorities list, at roughly $11 million, warning of burnout and force degradation without it. The deaths followed.

None of that establishes causation, and no responsible reading claims it does. What it establishes is that the warnings were on the record, in public, in the institution’s own words, before anyone needed them to explain anything.

The practical criterion to carry forward: when a summary tells you an institution has “linked” a set of events, go and read whether it actually said so. That single check catches most of what goes wrong between the original reporting and your feed.

If you or someone you know is struggling, help is available. In the United States, call or text 988, or chat at 988lifeline.org.

Sources: Bloomberg · NSA – Gen. Rudd bio · DefenseScoop · DVIDS – USCYBERCOM/Kimbrough · SASC hearing 28/04/2026 · Breaking Defense

Today, Model Context Protocol (MCP) allows an AI assistant to interact directly with these tools, orchestrating complete investigative workflows instead of simply answering questions.

As highlighted in recent research, the revolution is not about new OSINT tools, but about existing tools becoming autonomous through standardized AI connectors.

What is an MCP Server?

An MCP (Model Context Protocol) server exposes an application or data source through a standardized interface that any LLM can use.

Instead of building custom integrations for every AI model and every OSINT platform:

LLM
 │
 ├── MCP → Shodan
 ├── MCP → VirusTotal
 ├── MCP → Maigret
 ├── MCP → WHOIS
 ├── MCP → Company Registry
 ├── MCP → DNS
 ├── MCP → BrightData
 └── MCP → Internal Database

The AI becomes an orchestrator:

• decides which tool to use

• executes the query

• interprets the result

• determines the next investigative step

• writes the report

This evolution aligns with the broader shift from manual intelligence collection to AI-assisted orchestration described in recent OSINT literature.

Why MCP Matters for OSINT

Traditional workflow:

Investigator
    ↓
Shodan
    ↓
VirusTotal
    ↓
WHOIS
    ↓
DNS
    ↓
LinkedIn
    ↓
Company Registry
    ↓
Excel
    ↓
Report

MCP workflow:

Investigator
      ↓
Prompt

"Investigate ACME Ltd"

      ↓

LLM

      ↓

MCP Servers

      ↓

Automatic Investigation

      ↓

Structured Intelligence Report

The analyst moves from executing searches to validating intelligence.

Best MCP Servers for OSINT

1. Maigret MCP

Purpose:

Username investigation

Capabilities:

• username enumeration

• account discovery

• social profile correlation

• forgotten accounts

• historical usernames

Ideal for:

• SOCMINT

• Threat Hunting

• Insider investigations

Real Case

A ransomware negotiator publishes under the username:

darkphoenix

Prompt:

Find every public account associated with “darkphoenix”.

The AI:

• launches Maigret

• queries thousands of platforms

• discovers:

• GitHub

• Reddit

• Mastodon

• old forum profile

• Steam account

• archived blogs

The AI automatically correlates:

• reused avatar

• reused email

• reused bio

• timezone

instead of forcing the analyst to pivot manually.

2. Shodan MCP

Purpose

Infrastructure Intelligence

Capabilities

• exposed services

• banners

• CVEs

• SSL certificates

• open ports

• technologies

• vulnerabilities

Real Case

Investigating a phishing domain.

Prompt:

Analyze infrastructure related to phishing-example.com

The AI:

• queries Shodan

• discovers

IP
ASN
Hosting
Apache version
Open RDP
VPN
Exposed Jenkins

Then automatically pivots to:

• VirusTotal

• WHOIS

• DNS

• SSL history

3. VirusTotal MCP

Purpose

Threat Intelligence

Capabilities

• URL analysis

• malware reports

• domain reputation

• IP reputation

• passive DNS

• relationships

Real Case

Investigating malware.

Prompt:

Investigate hash XXXXX.

The AI retrieves:

• sandbox execution

• contacted IPs

• associated domains

• malware family

• previous campaigns

Then automatically investigates every discovered IOC.

4. OpenRegistry MCP

Purpose

Corporate Intelligence

Capabilities

• shareholders

• directors

• subsidiaries

• filings

• addresses

The recent MCP ecosystem includes connectors capable of querying company registries across dozens of jurisdictions, making corporate investigations significantly faster.

Real Case

A procurement fraud investigation.

Prompt:

Investigate Alpha Consulting Ltd.

The AI finds:

• directors

• dissolved companies

• beneficial owners

• registered addresses

• linked entities

It automatically pivots into:

• LinkedIn

• leaked documents

• social media

• procurement databases

5. Bright Data MCP

Purpose

Web Collection

Capabilities

• scraping

• structured extraction

• JavaScript rendering

• anti-bot browsing

Real Case

Threat actor marketplace monitoring.

Prompt:

Collect all vendor profiles mentioning “RedLine Stealer”.

The AI extracts:

• usernames

• prices

• Telegram handles

• Bitcoin wallets

• PGP keys

into a structured dataset.

6. DNS Twist MCP

Purpose

Typosquatting Detection

Capabilities

• homoglyph domains

• phishing domains

• certificate monitoring

Real Case

Monitoring Microsoft.

Prompt:

Detect suspicious Microsoft typosquatting domains.

The AI:

• generates thousands of permutations

• checks DNS

• checks SSL

• checks WHOIS

• checks hosting

and ranks suspicious domains automatically.

7. ZoomEye MCP

Purpose

Internet-wide reconnaissance

Ideal for:

• exposed services

• ICS

• IoT

• infrastructure hunting

Useful alternative to Shodan.

8. WHOIS MCP

Purpose

Registration Intelligence

Automatically retrieves:

• registrant

• registrar

• dates

• abuse contacts

• expiration

• ownership history

9. DNS MCP

Capabilities

• A

• AAAA

• MX

• TXT

• NS

• SPF

• DMARC

• DKIM

Useful during phishing investigations.

10. Passive DNS MCP

Allows automatic pivoting across

• historical IPs

• historical domains

• infrastructure reuse

Example Investigation

Suppose a security team discovers:

invoice-update[.]com

Instead of opening fifteen browser tabs, an analyst could prompt:

Investigate invoice-update.com and identify related infrastructure, phishing indicators, historical ownership, malware associations, exposed services, and connected social profiles.

The AI could automatically execute:

WHOIS
↓
DNS
↓
Passive DNS
↓
VirusTotal
↓
Shodan
↓
Certificate Transparency
↓
ASN
↓
GitHub
↓
Maigret
↓
Report generation

The output is a fully structured intelligence report requiring analyst validation rather than manual data collection.

Current Limitations

Despite their capabilities, MCP-powered agents are not replacements for analysts.

Recent research emphasizes an important methodological principle:

The agent must execute real tools and consume their outputs—not invent information. A WHOIS record retrieved from a registry is evidence; a WHOIS value “remembered” by an LLM is not.

Human expertise remains essential for:

• evaluating source reliability

• resolving conflicting evidence

• assessing deception

• applying legal and ethical constraints

• making analytical judgments

This mirrors established OSINT methodologies, where collection, processing, analysis, and reporting remain distinct phases requiring critical thinking rather than blind automation.

The Future of AI-Assisted OSINT

MCP is not replacing the traditional OSINT toolbox described by practitioners such as Michael Bazzell or Rae Baker; rather, it is providing a standardized orchestration layer on top of it. The same foundational resources—search engines, social networks, infrastructure intelligence, corporate records, and threat intelligence—are now accessible through AI-driven workflows instead of isolated manual searches.

The next generation of analysts will likely spend less time copying data between browser tabs and more time validating hypotheses, identifying patterns, and producing high-confidence intelligence. In that sense, MCP servers represent one of the most significant shifts in OSINT since the emergence of automated reconnaissance tools: not because they introduce entirely new sources, but because they enable AI to chain trusted tools together into repeatable investigative workflows while keeping the analyst in control of the final judgment.

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

That ordinariness is the entire mechanism behind one of 2026’s more consequential state-linked campaigns. On July 23, CISA and a group of international partner agencies published a joint advisory describing a phishing operation run by Russian state-supported actors against organizations running Zimbra Collaboration Suite (ZCS), a mail and collaboration platform used by government bodies, universities, and companies across the West. The activity has been tracked since at least July 2025 under several industry names, most prominently LAUNDRY BEAR, and also referenced as Void Blizzard, CL-STA-1114, or TA488, depending on which security vendor is doing the labeling.

The technique is old. The target selection is not.

There is no exotic tradecraft here. The actors send messages that imitate account or system notifications, direct recipients to a spoofed login page, and harvest whatever credentials get typed in. What makes the campaign worth an editorial pause is not the method — it is the contrast between how the intrusion is discussed and how it is actually carried out. Public conversation in 2026 tends to center on autonomous agents and AI-assisted intrusion tooling. This campaign shows a well-resourced state actor still getting results from a fake login form, because a fake login form still works.

The advisory notes the group is very likely to keep targeting ZCS and other mail systems used by Western organizations, combining known vulnerabilities with social engineering when a technical shortcut is not available. Mail platforms are attractive precisely because compromising one account rarely means compromising just that account. A mailbox holds contact lists, calendars, internal threads, and enough context to write the next phishing message with far more credibility than the first one had.

Why “check the sender” is no longer sufficient advice

Once an account is taken over, the attacker does not need to impersonate anyone. The next message in the chain can be sent from a real, previously trusted address — one the recipient has exchanged messages with for years. This is the detail that breaks the standard advice given to non-technical users. Checking who sent an email tells you nothing when the sender’s account has already been compromised. The email is, technically, legitimate. The judgment has to move from “who sent this” to “how did I get to this login page.”

That shift — from recognizing a suspicious sender to verifying a suspicious path — is the actual operational takeaway of this advisory, and it is something any reader can apply regardless of which mail platform they use.

How to verify a login request instead of a sender

The following sequence works for Zimbra, for any corporate webmail, and for most SaaS login flows. It does not require technical background, only a change in habit.

1. Do not open the login portal through the link in the email. Close the message. This removes the attacker’s ability to control where you land, which is the entire point of the exercise.

2. Reach the service through a bookmark or an address you already know. Type it, or use a saved link created before the email arrived. If the platform is asking you to re-authenticate, it will ask again once you get there through your own route — a genuine prompt does not disappear because you arrived independently.

3. Read the full domain, not just the part that looks familiar. A convincing brand name at the start of a URL means nothing if the actual domain that follows it belongs to someone else. This is the single most common point where verification fails, because attention naturally goes to the first recognizable word rather than the domain as a whole.

4. Use authentication that is resistant to phishing where it is available. The advisory specifically recommends passkey-based authentication through a third-party identity provider for platforms — Zimbra included — that do not support passkeys natively. Passwords and even one-time codes can be relayed by an attacker in real time; a passkey tied to a specific domain cannot be reused on a fake one.

5. Check active sessions and mail forwarding rules periodically, not only after suspicion arises. A forwarding rule quietly added to a compromised mailbox can leak every future message without the account owner noticing anything different in their own inbox.

6. Report anomalous access immediately, even if the outcome turns out to be nothing. The advisory’s own framing — that this group is likely to keep operating against the same category of targets — makes early reporting a defense that helps the next recipient, not just the current one.

The common mistake is stopping at step three and treating a plausible-looking domain as proof of safety. A domain can be plausible and still be wrong; verification means confirming the exact string, not judging whether it feels right.

What this means beyond the security team

For an ordinary employee, the practical change is habit, not tooling: stop clicking into login prompts from email, and start reaching services through known paths. For journalists and communicators who handle sensitive sources, a compromised mailbox is a much bigger loss than a single leaked message — it exposes the full pattern of who they talk to and when. For small organizations without dedicated security staff, the advisory’s emphasis on passkey-capable identity providers is a rare piece of guidance that is both concrete and affordable, since it does not require replacing the underlying mail platform.

There is also a research angle worth naming without turning it into a how-to. A phishing page is, itself, an artifact that can be studied — its domain registration, certificate, hosting provider, favicon, and source code can sometimes connect it to other campaigns run by the same infrastructure. That kind of analysis belongs strictly to passive, documentary observation: looking at what is publicly exposed about a page, never interacting with systems one is not authorized to test.

The one thing worth carrying forward

The lesson from this advisory is not “watch out for Russia” or “update your software,” even though both are true. It is that credential theft still travels through the most familiar gesture in anyone’s workday — logging in — and that the only reliable defense left is verifying the path you took to get there, not the message that suggested you take it. 1

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

That is the scenario now under scrutiny after a Financial Times investigation, reported on by Matthew Petti for Reason, into how Iran may have used commercial advertising data during its recent conflict with the United States to track American military personnel who had been moved out of their bases and into hotels and civilian offices in the region.

The Case

When U.S. forces evacuated several bases during the war, personnel were redistributed into hotels and civilian buildings across the Middle East, including in Iraqi Kurdistan and Bahrain. According to the Financial Times report, investigators suspect that in at least one instance in Iraqi Kurdistan, Iranian-aligned forces used advertising-tracking data to identify which hotels were housing U.S. troops. Iran-backed militias then struck several hotels in the region with drones, and Iranian forces bombed the Crowne Plaza in Bahrain directly, wounding two Pentagon employees. It remains unconfirmed which specific strikes, if any, were guided by ad-data targeting rather than other intelligence methods.

Byron Tau, the journalist whose reporting first exposed U.S. government use of commercial ad data to sidestep Fourth Amendment protections, told Reason in 2024 that any government running a competent cyber-intelligence program participates in this data trade, calling it an extraordinarily valuable source. The mechanism he described — governments buying access to advertising data that was never meant for intelligence use — is the same one now allegedly being turned against the personnel it once helped track.

The ad-tracking angle was not the only intelligence vector identified. The Financial Times report also documented use of Signaling System No. 7 (SS7), the protocol telecom carriers use to locate roaming phones internationally. An Iranian telecom operator reportedly sent a series of SS7 “pings” toward Arab countries, and Senator Ron Wyden told the Times that the Department of Homeland Security was aware Iran was using this method to locate American phones.

The OSINT Workflow: How Ad-Data Targeting Actually Works

The mechanism described in the reporting maps onto a replicable technical chain — the same chain any analyst studying ad-tech exposure would need to trace.

1. App-level data leakage. A phone runs an ordinary app — a fitness tracker, a prayer app, a game — that requests location and device-identifier permissions for advertising purposes. Precision here matters: the app doesn’t need to be built for surveillance, only to be ad-supported.

2. Real-time bidding (RTB) exposure. When the app serves an ad, it broadcasts a bid request onto an RTB exchange — the auction system that lets advertisers compete for that specific ad slot. That request bundles location, device ID, and behavioral attributes into a single package visible to every bidder on the exchange, not just the winner.

3. Demand-side platform (DSP) aggregation. Buyers use DSP software to place automated bids on these requests. Data brokers can sit inside this layer, harvesting the bid stream itself rather than actually buying ads — a use most RTB exchanges explicitly prohibit in their terms of service, but one the FTC’s own enforcement record shows is not reliably policed.

4. Aggregation into a location pattern. A single bid request reveals one moment. Repeated requests, tied to a persistent device identifier, reveal a pattern — which hotel a phone returns to every night, for instance. This is the step that converts ad exhaust into targetable intelligence.

5. Cross-validation against other signals. The Financial Times reporting notes that SS7 telecom pings and, more mundanely, social-media posts and human sources were also in play. In several Middle Eastern countries, which hotels housed U.S. troops was described as widely known locally. This matters methodologically: ad-data targeting, if it occurred, likely functioned as one corroborating layer among several, not a standalone targeting system.

Operational Takeaways

• Ad-supported apps are a location-disclosure risk independent of intent. Strava’s 2017 heat map and the flashcard-app exposure of U.S. nuclear personnel, later mapped by Bellingcat, show this isn’t hypothetical — it has already happened through completely unrelated apps.

• RTB bid streams are a data source, not just an ad mechanism. Anyone conducting OSINT work involving device or location data should treat the ad-bidding layer as its own leak vector, separate from the app’s stated function.

• Broker-level terms-of-service violations are hard to detect from outside. The FTC’s action against Mobilewalla for scraping RTB auctions in violation of exchange rules shows enforcement is reactive, not preventive — and that same settlement carved out an exception for geolocation data collected outside the U.S. for national-security purposes, which is worth flagging in any analysis of this ecosystem.

• User-facing controls are emerging but narrow. Google’s new RTB Control setting, introduced after a user lawsuit, lets individuals limit what reaches ad auctions — a mitigation, not a fix, since it depends on adoption by the same population least likely to know the risk exists.

• Attribution in this case remains unconfirmed. The Financial Times report raises the ad-tracking hypothesis; it does not establish which specific attacks, if any, were guided by it. Any downstream reporting or analysis should preserve that distinction rather than treat suspicion as confirmation.

Further Reading

• Matthew Petti, “Iran Allegedly Used Ad Tracking to Hunt U.S. Soldiers,” Reason

• Financial Times investigation into ad-data use during the Iran conflict (as cited in the Reason report)

• Byron Tau’s reporting on U.S. government use of commercial ad data

• Bellingcat’s 2021 investigation into flashcard-app data and U.S. nuclear-weapons locations

• FTC settlement with Mobilewalla on unauthorized RTB data collection

A Closing Note

The version of this story that should concern analysts isn’t the sophistication of the tradecraft — buying access to an ad exchange is not exotic. It’s that the infrastructure was never built for this, was adopted by militaries anyway, and is now available to whoever else decides to buy in. Anyone tracking similar cases, or with documentation on other ad-data targeting incidents, is welcome to send it in for the next installment of this series.

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

A strike video is not evidence by itself.

It is a claim with images attached.

This distinction matters every time a military video appears on Telegram, X, YouTube, Facebook or a mirrored channel. A camera can show impact. It can show smoke, fire, damage, speed, direction and sometimes a target. But the useful OSINT question is not simply:

Does the video look real?

The better question is:

What can this video prove, what does it only suggest, and what must be verified somewhere else?

The latest example comes from Ukraine’s energy war.

According to Reuters, Russia has been using small FPV drones controlled through fibre-optic cables to damage high-voltage electricity substations in Ukraine’s Sumy region. The footage of the strikes was posted on Russian social media channels, then verified by the Centre for Information Resilience and confirmed by Reuters.

That is the fact pattern worth studying.

Not because the weapon is visually dramatic. Not because every tactical claim around it should be accepted. But because it shows how modern OSINT often works: public video, platform context, infrastructure analysis, battlefield mapping, expert verification and careful limits.

The claim

The reported tactic is simple in concept and difficult in practice.

Ukraine has protected important electrical substations with concrete structures and anti-drone netting. These defences are designed to protect expensive and critical transformer equipment from missiles and larger attack drones.

The Russian workaround, as described in Reuters’ reporting, is to use fibre-optic FPV drones.

Unlike many radio-controlled drones, these systems are guided through a physical fibre-optic cable. That makes them harder to stop with electronic warfare as long as the cable remains intact. Instead of relying on a radio link that can be jammed, the drone follows a physical thread back to the operator.

The reported strike sequence is also important.

In the Reuters account, CIR investigator Joshua Scriven describes a pattern in which a first drone damages or opens the protective netting. A second drone then flies through the new gap and strikes the autotransformer.

This is not just a story about drones.

It is a story about adaptation.

One defence changes the target environment. The attacker studies the defence. The weapon changes. The video becomes a public signal that the tactic is being tested, repeated or advertised.

For an OSINT analyst, the video is only one layer.

The OSINT problem

When a strike video appears on a Russian social channel, there are at least five separate questions.

1. Is the video from the claimed event?

A real video can still be miscaptioned.

It may show a different date, a different location, a different target or a previous strike reposted as new. The first task is not to admire the footage. It is to detach the visual evidence from the caption.

Useful checks include:

- visual landmarks;

- infrastructure layout;

- road and field patterns;

- shadows and weather;

- visible defensive structures;

- upload history;

- earliest findable version;

- repost chains;

- whether the same clip appears with different claims.

The caption is a lead, not a conclusion.

2. Can the target be geolocated?

Energy infrastructure has a recognizable geometry.

Substations often have open yards, transformer bays, access roads, perimeter fencing, gantries and repeated structural patterns. Protective concrete structures and anti-drone netting may create additional visual signatures.

But a recognizable category is not a geolocation.

The analyst still needs to match the video to a specific site. That requires comparing visible features in the footage with satellite imagery, maps, prior imagery, local reporting or other public records.

In this case, Reuters reports that CIR verified multiple strikes, including attacks on large 330 kV substations and smaller 110 kV substations. The locations of the larger strikes were reported to be between 16 and 26 kilometres from the frontline, according to DeepState battlefield mapping cited in the Reuters report.

That distance matters because it helps evaluate a second claim: range.

If verified, the videos do not only show damage. They suggest that small fibre-optic FPV drones are being used at distances that matter operationally.

3. Does the video show the method, or only the result?

This is where many social media interpretations overreach.

A clip of a strike may prove that something hit something. It may not prove the full method.

To support the fibre-optic claim, an investigator has to look for additional indicators:

- visible cable or launch evidence;

- repeated strike behaviour;

- known characteristics of similar drones;

- technical assessment from specialists;

- corroboration from recovered components;

- consistency with battlefield reports;

- credible expert review.

Reuters’ reporting relies on CIR verification and additional confirmation. That gives the public reader a stronger basis than an anonymous Telegram caption.

Still, the method should be described carefully:

Public reporting indicates that fibre-optic FPV drones are being used.

That is stronger than:

This specific video alone proves the entire system.

4. What does the strike change?

OSINT is not only about location.

A verified strike can answer a narrow question: where did this happen?

A better investigation asks what the event means within a system.

In this case, the target is not a random object. A high-voltage substation is part of a regional electrical network. Reuters cites Ukrainian energy expert Oleksandr Kharchenko saying that disabling the autotransformer in a 330 kV substation can bring down the entire transformer unit and that such a component is worth roughly $3.5 million.

The public-interest question becomes:

Is this a tactical strike, or part of an effort to isolate a region from the national grid?

Reuters reports that CIR interprets the strikes as part of a wider strategy to reduce the ability of a region to receive electricity from outside and then degrade local generation.

That is an analytical assessment, not a video fact.

It should be labelled as such.

A practical verification frame

For ProjectOSINT, this case is useful because it gives us a compact workflow for strike videos.

Step 1: Preserve before judging

Save the post, the video, the caption, the account name, the timestamp, the URL and any visible engagement/context.

If the platform is Telegram, preserve the channel post link when possible. If the clip is reposted elsewhere, keep the repost chain but do not treat the loudest post as the earliest source.

The first question is:

What did the public record look like when we found it?

Step 2: Separate claims into units

Do not verify the whole caption at once.

Break it down.

- This is a fibre-optic FPV drone.

- The target is a Ukrainian substation.

- The substation is in Sumy region.

- The strike happened recently.

- The drone bypassed protective netting.

- The target was an autotransformer.

- The tactic is being used repeatedly.

- The attacks are part of a regional blackout strategy.

Each claim needs a different kind of evidence.

Some may be visible in the video. Some may require maps. Some may require expert analysis. Some may remain hypotheses.

Step 3: Geolocate the target, not the explosion

Explosions are visually noisy.

Infrastructure is usually more useful.

Look for the stable features around the strike:

- transformer yard layout;

- access roads;

- fence lines;

- nearby tree lines;

- pylons and power lines;

- concrete protective structures;

- netting frames;

- rail or road access;

- building shadows;

- distinctive roof or ground patterns.

The goal is not to identify a general type of place. It is to connect the footage to a specific physical site.

Step 4: Confirm timing with external context

A video can be geolocated and still be old.

Chronolocation may use:

- first upload time;

- weather;

- vegetation;

- shadow direction;

- visible damage before and after;

- local outage reports;

- official statements;

- satellite imagery;

- other videos from the same incident.

If the timing cannot be confirmed, say so.

Step 5: Explain the limit

Every strong OSINT piece should contain a limit statement.

For this case:

- A public video may support the fact of a strike.

- Geolocation may support the target location.

- Repeated verified videos may support a pattern.

- Expert analysis may support the fibre-optic method.

- But strategic intent requires more caution.

The sentence should be boring and useful:

The available public evidence supports the existence of a repeated strike pattern against substations, but it does not by itself prove the full command intent behind the campaign.

That kind of sentence protects the investigation from becoming propaganda.

Why this case matters

The visible story is about drones.

The OSINT story is about evidence discipline.

Fibre-optic FPV drones are important because they show how quickly battlefield methods adapt to defensive measures. Concrete protection, anti-drone nets and electronic warfare do not end the problem. They change the attack surface.

But the public information environment adapts too.

Military actors publish videos because videos persuade. They compress a complex event into a few seconds of apparent certainty. The viewer sees a drone approach, a gap, a target, an impact. The brain wants to complete the story.

OSINT has to slow that process down.

Not because the footage is useless.

Because the footage is only the beginning.

The method is:

preserve, separate, geolocate, corroborate, classify, limit.

If a strike video survives that process, it becomes evidence.

If it does not, it remains a claim with images attached.

That difference is the work.

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

A husband and wife working as Russian intelligence assets in two different countries, never once connected through their cover identities. The unknown locations of Ukrainian children transported to Russia, anticipated before official confirmation. A corporate structure untangled, a money-laundering chain traced. None of this came from a commercial intelligence platform. It came from Obsidian — a free note-taking application that Claudia Tietze, founder of the boutique OSINT shop Farallon, LLC, deliberately broke and rebuilt into a semantic analysis engine. She documents the method in her Medium piece, “Uncommon OSINT: Obsidian, Semantic Meaning and NLP” (April 2024).

The Gap the Method Fills

Most OSINT tooling is built for one job: collection. Scrapers, aggregators, people-search engines. What happens after collection — organizing fragments into relationships, testing whether two data points are actually connected, communicating the result — is left to spreadsheets, corkboards, or memory. Tietze’s argument is that a tool built for something else entirely, a digital garden for linked notes, already contains the primitives an analyst needs: bidirectional links, a graph view, and a plugin ecosystem that can pull in external ontologies. The question her workflow answers is whether note-taking software can be pushed to reveal relationships that were never typed in directly.

System Map: What Lives Where

The setup rests on four layers. The vault is the case file — a self-contained folder of notes, one vault per investigation. Each note carries a body of free text plus YAML front matter, a metadata block that functions like a note’s ID card. Wikidata, a free structured database with more than 100 million entries across 300-plus languages, supplies the semantic layer: imported into the YAML, it tags a concept with relationships such as “subclass of,” “used by,” or “field of work.” The graph view then renders every note as a node and every YAML relationship or in-text mention as an edge, native to the app and extendable through community plugins.

Operational Method

1. Create a dedicated vault per case. Reason: isolates one investigation’s links from another’s, and lets a vault be locked down or shared independently. What to look for: whether restricted mode needs to stay on while sensitive files are added.

2. Import a term through the Wikidata Importer plugin (by Sam Rose). Action: search the term, review the list of candidate senses — a search for “spy” returns the profession alongside a 2015 film, a Belgian village, and a Team Fortress 2 class — and select the one matching the case. What it proves: only that the correct Wikidata entity was chosen, not that the imported relationships are complete; Wikidata is a generalist source, so intelligence-specific facets sometimes need to be added by hand.

3. Add a Wikipedia extract to the note body via the Wikipedia plugin (by Jonathan Miller). This pulls the article’s first section into the note, giving later NLP and link-detection steps actual prose to work against instead of bare YAML fields.

4. Review unlinked mentions before confirming links. Obsidian surfaces two categories: linked mentions (already-confirmed connections) and unlinked mentions (terms that appear in a note’s text or YAML but haven’t been formally linked yet). Each unlinked mention requires a human decision — link it with double brackets, or leave it. This step is where analyst judgment, not the plugin, does the verification work.

5. Run the Graph Analysis algorithms (SkepticMystic and Emile) once the NLP plugin has indexed the vault. HITS scores which notes function as hubs versus authorities; Jaccard scores how much two specific notes have in common. What each result can prove: HITS flags structurally central concepts, useful for prioritizing which notes deserve deeper review; Jaccard flags candidate overlaps between two named entities. What it cannot prove: causation or intent — a high Jaccard score between two companies indicates shared vocabulary in the vault, not confirmed common ownership. It is a lead to check against source documents, not a finding on its own.

6. Visualize with Graph Link Types (natefrisch01) and Juggl (Emile van Krieken). These add labeled, color-coded edges and interactive re-centering on a selected node — useful for tracing a specific relationship pathway (e.g., spy → intelligence agency → counterintelligence) rather than reading raw YAML.

7. Build a working canvas with Link Exploder (Ben Hughes) and Semantic Canvas (Aaron Gillespie). Link Exploder auto-populates a canvas with a note’s incoming and outgoing links as cards; Semantic Canvas renders the underlying triples and shows empty cards for entities referenced in YAML but not yet created as notes — a direct prompt for what still needs collecting.

Intelligence Playground Vault Wikidata Importer plugin interface. This allows you to see and select the concept that you want to import. If you don’t see a good option, you can alter your search term or import the definition closest to your subject matter and fine-tune it with your own YAML pruning and cultivation.

Critical Issues

The method depends on custom YAML the analyst designs, which means the schema for one case (say, tracking espionage cells by arrest location, handler, and cover legend) has to be built by hand each time — there’s no default template for intelligence work. Obsidian also rejects certain characters in note titles, so any Wikidata entry containing a colon fails to import silently, and that gap needs a separate workaround. On the security side, several plugins call third-party services, meaning vault data can leave the machine; Tietze’s own advice is to populate Wikidata terms first, then lock the vault before adding sensitive case files. Finally, algorithmic outputs like HITS or Jaccard scores can be skewed simply because some notes have Wikipedia text added and others don’t — an artifact of uneven enrichment, not of the underlying relationships.

Analytical Layer

The structural pattern worth flagging is the deliberate separation between linked and unlinked mentions. Most graph tools show only confirmed edges; Obsidian’s unlinked-mentions pane keeps candidate connections visible without forcing a premature decision, which is closer to how an analyst actually works through ambiguous evidence. A second pattern: pairing a generalist ontology (Wikidata) with a bespoke, case-specific YAML schema lets one vault serve dual purposes — it inherits broad semantic coverage while still answering the narrow question a specific investigation needs answered, such as who shares a handler or a cover business across an espionage network.

Closing

The tools that matter most in an investigation aren’t always the ones built for it. Obsidian was never designed for espionage tracking or corporate structure mapping — the fact that it can be repurposed for both, using nothing more than free plugins and a well-designed YAML schema, is the actual takeaway: an analyst’s leverage often comes from bending general-purpose software into a shape the vendor never intended, not from waiting for a purpose-built product.

Further reading: Claudia Tietze, “Uncommon OSINT: Obsidian, Semantic Meaning and NLP,” Medium, April 12, 2024 — first article in her Uncommon OSINT series. Tools referenced: Obsidian, Wikidata Importer (Sam Rose), Wikipedia plugin (Jonathan Miller), NLP and Graph Analysis (SkepticMystic, Emile van Krieken), Graph Link Types (natefrisch01), Juggl (Emile van Krieken), Link Exploder (Ben Hughes), Semantic Canvas (Aaron Gillespie), Charts View (Caronchen).

Have you repurposed a mainstream tool for OSINT work? ProjectOsint wants to hear about it — reply with your case.

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

The first version of a source is often the one you need most.

It is also the easiest one to lose.

A post can be deleted. A company page can be edited. A profile can be renamed. A file can be replaced at the same URL. A search result can disappear. An AI answer can cite a page that later changes, moves, or no longer says what it seemed to say.

For OSINT work, the problem is practical:

That does not mean every edit is suspicious.

Web pages change. Platforms moderate content. Accounts evolve. Organizations update their sites. Mistakes get corrected.

But if you cannot reconstruct what you saw, where you saw it, when you saw it, and what part of the claim it supported, the evidence chain becomes weaker.

Preservation should happen before interpretation.

A source is not automatically proof

This is the mistake worth avoiding.

Someone captures a screenshot, saves an archive link, or copies a quote, and then treats the source as if it proves the whole claim.

It usually does not.

A source may show that a name appeared on a page.

It may not prove why the name appeared there.

An archive may show that text was visible at a URL on a certain date.

It may not prove that the text was accurate.

A screenshot may preserve a post.

It may not prove that the event described in the post happened as claimed.

Good OSINT keeps the claim narrow.

The question is not:

The better question is:

The five-minute preservation habit

When a source may matter, capture enough context before it changes:

The limitation is not a minor note.

It is what prevents one captured source from becoming a false conclusion.

For example:

That kind of narrow statement is less dramatic.

It is also more useful.

Context matters more than a cropped capture

A screenshot of one sentence is weak.

A contextual screenshot is stronger.

It should preserve the surrounding evidence: page title, visible source name, URL when possible, timestamp or publication date if visible, the relevant claim, and enough page structure to identify the source later.

For a social post, capture the post in context.

For a website, capture the section that contains the claim and enough header or page structure to identify the page.

For a document, capture the title, date, page number if available, and the specific passage.

The screenshot should answer:

Deletion is a signal, not a conclusion

A disappearing source may matter.

But disappearance alone does not prove intent.

A page can change for ordinary reasons. A post can be removed because it was wrong, because it was sensitive, because it violated platform rules, because it attracted attention, or because the author changed strategy.

The job is not to turn disappearance into a story too quickly.

The job is to preserve the earlier state, document the change, and separate what is known from what is inferred.

That is the discipline behind source-chain work.

Preserve first.

Interpret later.

I wrote the full ProjectOSINT workflow here:

https://projectosint.com/source-disappearing-preserve-osint-evidence/

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

The easiest way to look for AI coding agents in open source is to search for the bot account.

That is also the first mistake.

A visible bot is useful. It gives you a name, a timestamp, a pull request, a public identity. It feels like clean evidence.

But AI coding agents do not always work that way.

Sometimes they open pull requests under an automated account.

Sometimes they leave traces in commit messages.

Sometimes they appear through configuration files.

Sometimes they generate code locally and a human commits the final change.

Sometimes the only public clue is a pattern across repository files, pull request metadata, commit history and timeline.

So the better OSINT question is not:

Was this written by AI?

The better question is:

Which public signals support agent involvement, and how strong is each one?

That change matters because AI coding agents are no longer just private developer tools. They are entering the open-source supply chain: writing code, modifying tests, touching configuration files, preparing pull requests, updating dependencies and sometimes operating close to credentials, local context and release workflows.

If we want to understand that ecosystem, we need better evidence discipline.

One Signal Is Not Enough

A recent paper by Arsham Khosravani and Audris Mockus looked at AI coding agent traces across more than 180 million Git repositories.

The most useful finding, for OSINT work, is not only the scale.

It is the method.

The authors did not rely on one signal. They combined configuration-file scanning, commit-message analysis, author-identity matching and bot-signature lookup.

That matters because bot-account lookup alone misses too much.

In one snapshot, their multi-method approach identified 850,157 Claude Code commits. Bot-account lookup recovered only 28,154 of them.

The exact numbers will change.

The lesson is more stable:

If you only count the obvious bots, you are not measuring agent activity.
You are measuring the part of agent activity that chose to identify itself.

For open-source OSINT, this is the key shift.

The repository has to be read as a system.

Adoption, Assistance and Authorship Are Different Claims

This is where weak analysis can become misleading.

A repository can show signs of AI-agent adoption without proving that a specific commit was generated by an agent.

A commit can be agent-assisted without being fully agent-authored.

A pull request can be opened by an agent and then rewritten by a human.

A human can use an agent privately and leave no bot identity in the public record.

Those are different findings.

They need different language.

Useful labels are:

Agent-capable workflow
Agent-assisted contribution
Agent-attributed contribution

An agent configuration file may support the first label.

A commit message or co-author line may support the second.

A bot account or direct tool attribution may support the third.

Collapsing them into one sentence is how a clue becomes an overclaim.

What to Look For

A practical repository review should start with four layers:

• identity signals;

• commit-message and co-author patterns;

• configuration files and tool artifacts;

• pull request behavior.

None of these is perfect.

A bot account can miss local agent use.

A commit message can be edited.

A configuration file can show capability, not authorship.

A pull request can show automation without proving that every line survived without human review.

The useful work is not finding one impressive trace.

It is asking whether the traces converge.

identity + metadata + configuration + timeline + code change + review trail + limits

That is the evidence chain.

Why This Is a Supply-Chain Question

Agent adoption is not automatically a security problem.

But it changes the attack surface.

A coding agent can read instructions, follow documentation, run setup commands, edit files, generate tests, call package managers or prepare code for review. If it works inside a developer environment, it may be close to secrets, private repositories, browser sessions or deployment tools.

This does not mean every AI-assisted repository is unsafe.

It means agent activity should become part of the repository risk model.

When did agent traces first appear?

Were security-sensitive files touched?

Did the review process change?

Were dependency, CI or release workflows affected?

Is the evidence about adoption, assistance or attribution?

Those questions are less dramatic than saying “AI wrote the code.”

They are also more useful.

The Full Workflow

I published the full ProjectOSINT workflow here:

https://projectosint.com/detect-ai-coding-agents-open-source-repositories/

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

The most useful way to investigate an AI agent is not to ask whether it is intelligent.

Ask what it can touch.

An agent that writes a document is one kind of system. An agent that can edit files, call APIs, query internal data, open tickets, deploy code, change permissions, send messages or trigger workflows is another.

The risk changes when the model stops being only a generator and becomes an actor inside a system.

That is why Google DeepMind’s recent AI Control Roadmap is worth reading as an OSINT and security document, not only as an AI safety document. The company describes a framework for securing internal systems against increasingly capable AI agents and explicitly borrows from cybersecurity. Its core planning assumption is simple and uncomfortable: treat powerful internal agents as if they could be imperfectly aligned and capable of unexpected behavior.

In cybersecurity terms, the agent starts to look less like a tool and more like a potential insider.

Not because today’s agents are all malicious. Not because every automation is dangerous. But because a system with access, goals, tools and partial autonomy creates an evidence problem.

If something goes wrong, you need to know what happened.

And you need to know before the damage is irreversible.

The OSINT Question Is About Access

Public discussion about AI agents often focuses on capability.

Can the agent code?
Can it browse?
Can it reason?
Can it complete a task?
Can it use tools?

Those questions matter. But for investigative and defensive work, the first question is more operational:

What permissions does the agent have?

An AI agent with no external access can still produce bad information. That is a quality and verification problem.

An AI agent with external access can create a security problem:

• it can read information it should not use;

• it can combine data from separate contexts;

• it can trigger actions faster than a human reviewer can follow;

• it can misunderstand an instruction and over-execute;

• it can delete, overwrite, expose or transmit data;

• it can be influenced by malicious inputs from the environment;

• it can make an action look intentional even when it came from a flawed task interpretation.

This is why the unit of analysis should not be “the model” alone.

The unit of analysis is the agentic system:

model + tools + permissions + memory + instructions + environment + logs + human oversight

If one of these elements is missing from your notes, your picture is incomplete.

Why DeepMind Uses an Insider-Threat Lens

Google DeepMind says its roadmap treats untrusted AI agents as potential insider threats, similar to a rogue employee who already has access inside an organization.

That comparison is useful because it moves the conversation away from vague fear.

An insider-threat model does not start with the assumption that every insider is hostile. It starts with the fact that insiders have privileges. They can already reach systems, documents, credentials, channels, databases or workflows that outsiders cannot reach.

An AI agent with internal tool access creates a similar planning problem.

The question is not only:

Will the model refuse harmful requests?

The better questions are:

Which actions can it take?
Which systems can it reach?
Which actions require approval?
Which actions are logged?
Which actions can be reversed?
Which actions are blocked in real time?
Which actions are only reviewed after the fact?

This is the OSINT value of the roadmap: it gives analysts a way to translate AI safety language into observable system behavior.

Detection Is Not the Same as Control

One of the most important distinctions in the DeepMind post is between detection, prevention and response.

Detection means the system can notice a concerning action, plan or pattern.

Prevention means it can block the action before it happens.

Response means it can contain, reverse, investigate or escalate after something has happened.

These should not be collapsed.

A company saying “we monitor agents” is not the same as saying “we can stop high-risk actions in real time.”

For OSINT work, this distinction gives you a simple claim-checking method.

When an organization describes agent safeguards, break the claim into three columns:

The point is not to demand perfect control. That does not exist.

The point is to avoid treating a monitoring claim as if it were a containment claim.

The Evidence Log for an AI Agent

If an AI agent is involved in a mistake, leak, unexpected action or security incident, the investigation needs an evidence log.

Not a transcript dump.

A structured log.

Use this template.

Agent:
Name, version, provider, deployment context.

Task:
What was the agent asked to do?

User instruction:
Original instruction, relevant constraints, approval requirements.

System instruction:
Known policy, guardrails, tool-use rules, role boundaries.

Tools:
Which tools were available?

Permissions:
Read, write, execute, send, delete, deploy, invite, export, query.

Data access:
Which files, systems, channels, repositories or records could the agent access?

Action sequence:
What did the agent do, in order?

Human checkpoints:
Where did a human approve, reject, edit or miss an action?

External inputs:
Which web pages, documents, emails, tickets, prompts or data sources influenced the agent?

Observed failure:
Misinterpretation, over-execution, policy bypass, data exposure, deletion, unauthorized action, hallucinated evidence.

Evidence level:
Direct log, screenshot, audit event, vendor statement, third-party report, user claim.

Reversibility:
Can the action be undone? How quickly?

Open questions:
What cannot be verified from the available evidence?

This template is deliberately boring.

That is the point.

Agent incidents will be difficult to analyze if every discussion begins with abstract terms: autonomy, alignment, intelligence, safety, trust.

A good evidence log forces the investigation back to observable events.

Watch the Difference Between Error and Adversarial Behavior

DeepMind notes that many flagged events in its analysis did not appear to come from adversarial intent. They often came from agent misinterpretation or over-eagerness to achieve a user’s goal.

This distinction matters.

If an agent deletes data because it misunderstood a task, that is different from an agent trying to hide a harmful action.

But the operational impact can still be serious.

For investigators and defenders, intent should not be guessed too early. Start with behavior.

Ask:

• What instruction did the agent receive?

• What goal did it appear to optimize?

• Which constraints did it ignore?

• Did it ask for confirmation?

• Did it operate inside its expected scope?

• Did it use a tool in a way the user could reasonably anticipate?

• Did the system warn, block or log the action?

Only after that should you move toward interpretation.

The mistake is to turn every failure into a drama about rogue AI, or every failure into a harmless bug. Both shortcuts hide the evidence.

A Practical Risk Matrix

For a quick assessment, map agent actions across two dimensions:

Impact if wrong
Reversibility after execution

Low impact and reversible:

• drafting text;

• summarizing public material;

• creating a local note;

• suggesting a query;

• preparing a non-sent message.

Medium impact or partially reversible:

• editing shared documents;

• moving files;

• opening tickets;

• updating metadata;

• querying internal knowledge bases;

• drafting messages in a live workspace.

High impact or hard to reverse:

• deleting data;

• changing permissions;

• sending messages externally;

• deploying code;

• modifying production systems;

• exporting sensitive information;

• connecting new integrations;

• approving transactions or access requests.

This matrix should shape the control level.

Low-risk actions can be reviewed asynchronously.

High-risk actions need real-time approval, sandboxing, or hard blocks.

If an agent can perform high-impact, hard-to-reverse actions with only delayed review, the problem is not the agent’s personality. The problem is system design.

What to Check Before Trusting an Agentic Workflow

Before relying on an AI agent in a research, journalism, OSINT or security workflow, ask these questions:

1. Scope
   What is the agent allowed to do?

2. Tool access
   Which tools can it call without asking?

3. Data boundaries
   Can it access private, sensitive, unpublished or cross-client data?

4. Action boundaries
   Can it write, delete, send, publish, deploy or invite?

5. Approval
   Which actions require human confirmation?

6. Logging
   Can you reconstruct the full action sequence?

7. External influence
   Can web pages, emails, documents or tickets inject instructions into the workflow?

8. Rollback
   What can be undone, and how fast?

9. Monitoring
   Are you looking only at outputs, or also at actions and tool calls?

10. Evidence retention
    How long are logs, transcripts and tool events preserved?

This is not only an enterprise checklist.

It applies to smaller workflows too: a research assistant connected to documents, a coding agent inside a repository, a browser agent that can submit forms, or a content agent that can publish drafts.

The moment an AI system can act, the evidence trail becomes part of the safety model.

The Takeaway

AI agents make verification harder because they sit between instruction and action.

They can read, decide, call tools, interpret context and produce outputs that look coherent even when the path was flawed.

For OSINT, that means we need to stop treating agent output as the only artifact worth checking.

The important artifacts are:

• the instruction;

• the available tools;

• the permissions;

• the data accessed;

• the action sequence;

• the human checkpoints;

• the logs;

• the blocked actions;

• the failed actions;

• the rollback path.

An AI agent should not be trusted because it sounds reliable.

It should be trusted only to the degree that its actions are bounded, logged, reviewable and reversible.

That is the real investigative shift.

The question is no longer only:

What did the AI say?

It is:

What did the AI do, what could it have done, and how do we know?

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

For OSINT work, that is the part worth studying.

Not because every reader needs to follow the model release cycle. Not because the public post answers every question. But because it shows what investigators, journalists, researchers, and security teams should ask when a powerful AI system is paused and then returned to service.

The question is not only:

Is the model available again?

The better question is:

What changed between restriction and redeployment?

The Timeline Matters

According to Anthropic, Fable 5 and Mythos 5 were released on June 9, 2026.

On June 12, the U.S. government applied export controls to both models. Anthropic says the order required it to restrict access to foreign nationals, whether inside or outside the United States. Because the company said it could not verify nationality in real time, it suspended access to both models for all users.

On June 30, Anthropic said those export controls had been lifted. Fable 5 would become available globally on July 1 across the Claude Platform, Claude.ai, Claude Code, and Claude Cowork, with cloud partner access to follow as quickly as possible.

That timeline gives us the first OSINT lesson: do not treat “model removed” and “model restored” as isolated events.

Write the sequence.

June 9: model release
June 12: export controls and access suspension
June 26: partial government approval for Mythos 5 access
June 30: announcement that export controls were lifted
July 1: Fable 5 availability expected to resume

Once the sequence is visible, the investigation becomes clearer. You can separate access decisions, safety claims, government action, technical mitigation, and business availability.

Without a timeline, everything becomes noise.

Fable 5 and Mythos 5 Are Not the Same Operational Object

Anthropic says Fable 5 and Mythos 5 share the same underlying model, but were released under different access and safeguard conditions.

Fable 5 was released for general use with strong safeguards. Mythos 5, according to Anthropic, has fewer safeguards and was released only to a small number of trusted Project Glasswing partners for defensive cybersecurity work.

That distinction matters.

When a public discussion says “the model was restricted” or “the model is back,” it can hide important differences:

• which model is being discussed;

• who can access it;

• what safeguards are attached;

• what use case is allowed;

• what partner program is involved;

• whether access is public, commercial, cloud-based, domestic, international, or restricted.

In OSINT, naming is not a cosmetic detail. It is part of the evidence chain.

If two systems share an underlying model but differ in safeguards and access conditions, they should not be collapsed into one object in your notes.

The Reported Issue Was About a Bypass, Not a Public Exploit Chain

Anthropic says the June 12 directive followed a report in which Amazon researchers found a method of bypassing Fable 5’s safeguards. The company describes the reported behavior as involving identification of software vulnerabilities and, in one case, code demonstrating how a relevant vulnerability could be exploited.

That sentence needs careful handling.

For a security reader, it is tempting to jump straight to the operational question: what was the bypass?

For responsible OSINT, the better question is different:

What is the claim, and what level of detail is publicly supported?

From the public post, we can say:

• Anthropic says Amazon researchers reported a safeguard bypass.

• Anthropic says it reviewed the report with government and industry partners.

• Anthropic says the issue did not expose unique Mythos-level cyber capabilities.

• Anthropic says the behavior reflected a borderline case for Fable 5 safeguards.

• Anthropic says it trained an improved safety classifier to block the behavior described in the report.

What we cannot responsibly do from this public post is reconstruct the bypass technique, infer the exact vulnerability, or describe how the exploit demonstration worked.

That is the second OSINT lesson: when the public evidence is high-level, keep your own conclusion high-level.

Do not fill the gap with technical imagination.

The New Safeguard Is a Classifier Update

Anthropic says it trained an improved safety classifier targeting the behavior described in the Amazon report. If a Fable 5 request is blocked, the request is routed to Opus 4.8 instead.

The company also says the new classifier blocks the specific technique described in the Amazon report in more than 99% of cases. It acknowledges a tradeoff: the classifier may flag benign requests more often during routine coding and debugging.

This is a useful detail because it shows the shape of the mitigation.

It was not described as:

• a complete redesign of the model;

• a guarantee that all jailbreaks are impossible;

• proof that no cyber risk remains;

• a universal solution for misuse.

It was described as a targeted classifier improvement, inside a broader “defense in depth” approach.

That distinction matters for anyone tracking AI safety claims. A mitigation can be meaningful without being absolute. A classifier can reduce a specific behavior while increasing false positives. A model can be safer than before without being immune to future jailbreaks.

The right question is not “is it fixed?”

The better question is:

Which behavior was mitigated, how was it mitigated, and what tradeoff did the mitigation introduce?

The Most Important Part Is the Severity Framework

The most interesting section of Anthropic’s post is not the redeployment announcement.

It is the proposed framework for assessing AI jailbreak severity.

Anthropic argues that the industry lacks a common way to describe the severity of a jailbreak. That creates uncertainty for model developers, governments, researchers, and users. A minor bypass, a narrow harmful jailbreak, and a broad universal jailbreak should not be treated as the same kind of event.

The company proposes four criteria:

1. Capability gain
   How much capability does the jailbreak provide beyond existing tools?

2. Breadth of capability gain
   Does the jailbreak unlock one narrow behavior, or many offensive tasks?

3. Ease of weaponization
   How much effort is needed to turn the jailbreak into a real attack?

4. Discoverability
   How easy is it for others to obtain or reproduce the technique?

For OSINT, this is a strong analytical template.

It helps move the discussion away from vague labels like “dangerous,” “safe,” “broken,” or “jailbroken,” and toward structured questions.

If a jailbreak only unlocks a low-risk behavior that existing tools can already perform, its severity is different from a prompt that reliably enables a broad class of harmful tasks on the first try.

The word “jailbreak” is not enough.

You need the severity profile.

A Practical OSINT Note Template

When a model safety incident appears in public, use a simple note structure.

Event:
What happened?

Timeline:
When was the model released, restricted, updated, restored?

Actors:
Which company, government body, researchers, cloud partners, or programs are named?

Model distinction:
Which model? Which version? Which safeguard level? Which access tier?

Reported issue:
What behavior is publicly described?

Evidence level:
Official statement, researcher report, government statement, third-party reporting, rumor?

Mitigation:
Classifier update, access restriction, policy change, monitoring, red-team program, other?

Severity questions:
Capability gain?
Breadth?
Weaponization effort?
Discoverability?

Limits:
What is not publicly known?

This template prevents a common mistake: treating every model safety story as either a public relations statement or a technical exploit story.

It may be neither.

It may be a governance event, an access-control event, a safety-classifier event, a cloud-availability event, or all of those at once.

What This Means for Cyber Defenders

For defenders, the Fable 5 redeployment story points to a future where model access, cyber capability, jailbreak reporting, government review, and cloud availability are all connected.

This creates practical problems.

Security teams may need to know:

• which models are available to their organization;

• whether access differs across consumer, platform, enterprise, and cloud channels;

• what happens when a request is blocked;

• whether blocked requests are rerouted to another model;

• what logging and audit trails exist;

• how model updates affect coding, debugging, vulnerability research, and defensive workflows;

• whether a safety change increases false positives in legitimate work.

For OSINT researchers, the public question is broader:

Can we track frontier model changes with the same discipline we use for software vulnerabilities?

That means version names, release dates, access conditions, mitigation notes, public claims, partner statements, and unresolved gaps.

The Key Takeaway

Fable 5 being redeployed is news.

But the deeper signal is that frontier AI incidents now need structured public analysis.

A model may be restricted for policy reasons. Access may depend on nationality, partner status, cloud provider, subscription tier, or government approval. A safeguard bypass may be minor, narrow, harmful, or broad. A mitigation may block a specific behavior while creating false positives elsewhere.

If we collapse all of that into “the model was banned” or “the model is safe again,” we lose the useful part.

The useful part is the chain:

release -> report -> restriction -> review -> mitigation -> redeployment -> monitoring

That chain is now part of AI OSINT.

Sources

• Anthropic, “Redeploying Fable 5,” June 30, 2026, https://www.anthropic.com/news/redeploying-fable-5

  ---

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

Upload the image. Look for earlier appearances. Find the old context. Check whether the current caption is false.

That habit still matters.

But it is no longer enough.

An image can have no useful reverse search results for many reasons. It may be new. It may be cropped. It may be synthetic. It may have been edited. It may have circulated first in a closed channel. It may not be indexed yet. It may be a screenshot of another image. It may be real and still attached to the wrong claim.

So the better question is not only:

Where else does this image appear?

The better question is:

What chain of evidence supports the image, the source, the location, the time and the claim?

That is the shift.

Visual verification is moving from single-tool confidence to evidence-chain discipline.

The image is not the claim

This is the mistake I see most often.

Someone verifies that an image exists, or that it has not appeared before, and then treats the caption as if it has been verified too.

But an image and its caption are different evidence objects.

The image may be real. The location may be correct. The date may still be wrong. The actor may be unconfirmed. The consequence may be exaggerated. The visible scene may support part of the claim, but not all of it.

Good OSINT does not ask an image to prove more than it can prove.

A lighter workflow

Before using a visual claim, run a short chain check:

1. What exact claim does the image support?
2. What is the earliest source you can find?
3. Did reverse search find older uses or variants?
4. Are there provenance signals or labels?
5. What visual clues support the location?
6. What evidence supports the time?
7. Who confirmed the event independently?
8. What remains unverified?

The last question is not a formality.

It is often the most important part of the analysis.

Provenance helps, but it does not replace verification

Content Credentials, C2PA data, platform labels and tools like Google’s “About this image” can help.

They can provide useful context about origin, edits, earlier indexing or appearances elsewhere online.

But they do not automatically prove that the current claim is true.

Metadata can be missing. Labels can be incomplete. Context tools can show where an image appeared without proving why it appeared there. A file can carry useful provenance and still be attached to a misleading caption.

Treat provenance as one signal in the chain.

Not the chain itself.

The takeaway

Reverse image search is still useful.

It is just not the whole workflow anymore.

Visual verification now needs a wider frame:

• preserve the original post;

• isolate the claim;

• search for earlier appearances;

• check provenance signals;

• geolocate visible features;

• test the timeline;

• map the source chain;

• state the conclusion narrowly.

The important question is no longer whether one tool gives an answer.

It is whether each part of the claim survives being checked separately.

I wrote the full ProjectOSINT workflow here:

https://projectosint.com/visual-verification-reverse-image-search-not-enough

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

A weak OSINT workflow often starts with movement.

Someone sees a claim, opens a search engine, checks a social platform, runs a reverse image search, asks an AI tool for suggestions, opens a map, saves a few links, and starts building a conclusion before the actual object of verification has been defined.

The problem is not curiosity.

The problem is speed without structure.

Before you search, break the claim.

Take a sentence like this:

This video shows police using tear gas during a protest in Madrid on 10 June 2026.

It looks like one claim. It is not.

It contains several smaller claims:

• the content is a video;

• the actor is police;

• the action is the use of tear gas;

• the event is a protest;

• the location is Madrid;

• the date is 10 June 2026;

• the video is connected to that specific event.

Each part needs a different kind of evidence.

A timestamp can help with publication time. It may not prove recording time.

A street sign can support location. It does not prove the date.

A local news report can confirm that a protest happened. It may not prove that this specific video shows that protest.

A uniform can be a useful visual indicator. It is not, by itself, a complete actor verification.

This is where many investigations become fragile. One part of the claim starts to look plausible, and the whole sentence quietly inherits that plausibility.

Location looks right, so the date feels right.

The event happened, so the video feels connected.

The account looks relevant, so the source feels original.

That is not verification. That is momentum.

The First Question Is Not “Is This True?”

The first question should be:

What is this claim made of?

Only after that can you ask:

• Which part can be checked first?

• Which part requires a primary source?

• Which part needs visual verification?

• Which part depends on timing?

• Which part is only context?

• Which part may remain unknown?

This matters because the search path changes depending on the component.

If you are checking location, you may need maps, street-level imagery, signage, architecture, transport routes, local landmarks, satellite imagery, or posts from the same area.

If you are checking time, you may need upload timestamps, archive timestamps, weather records, light, shadows, event schedules, livestreams, or earlier versions of the same media.

If you are checking source origin, you may need platform search, repost chains, archives, unique captions, usernames, watermarks, or metadata if it is available and reliable.

If you are checking identity, you need to move much more carefully. A username match, a profile photo, or a repeated phrase may create a lead. It does not automatically prove that two accounts belong to the same person.

Breaking the claim first protects the investigation from using the wrong source for the wrong question.

AI Can Help Here, But Only in One Role

AI can be useful before the search begins.

Not as a source.

Not as a judge.

Not as the thing that tells you whether the claim is true.

Its useful role is to slow the claim down.

You can ask:

Break this claim into separate verifiable components.
For each component, identify the type of evidence that would support it, what would not be enough, and what source types should be checked first.

Claim:
[paste claim]

The output is not evidence. It is a planning layer.

You still have to edit it. AI may miss local sources, misunderstand context, suggest weak categories, or treat one component as more checkable than it really is.

But as a first pass, it can help expose the hidden structure of the claim.

That is useful because many false conclusions are not caused by a lack of tools. They are caused by unclear questions.

Look for the Evidence Gap

Once the claim is broken apart, the most important part of the workflow is not the evidence you already have.

It is the gap.

For each component, ask:

• What would support this?

• What would weaken this?

• What would not be enough?

• What have I not checked yet?

• What alternative explanation remains possible?

The evidence gap is where cautious language comes from.

If the location is supported but the date is not, the conclusion should say that.

If the event is confirmed but the media origin is unknown, the conclusion should say that.

If two usernames look connected but there is no independent source linking them, the conclusion should not turn that into identity.

Good OSINT protects the distance between evidence and conclusion.

That distance is not a stylistic detail. It is the method.

The Evidence Log

After you break the claim, the next step is to log the evidence.

Not in a long report. Not necessarily in a complex database.

A simple table is enough if it keeps the reasoning visible.

Use columns like:

• claim component;

• verification question;

• source checked;

• what the source shows;

• limitation;

• confidence;

• next step.

This structure forces a useful discipline.

You cannot simply write “confirmed” because a source looked convincing. You have to write what the source actually shows.

You cannot hide uncertainty inside a polished paragraph. You have to name the limitation.

You cannot move from a weak indicator to a strong conclusion without leaving a trace.

The evidence log makes the investigation harder to overstate.

A Better Conclusion

A careful conclusion may sound less dramatic than a confident one.

It may say:

The available evidence supports the location claim with medium confidence and confirms that a related protest occurred in Madrid on the stated date. However, the current sources do not establish the original uploader or prove that the footage was recorded during that specific event. The claim should be treated as partially supported, not fully verified.

That is not a weak conclusion.

It is a more accurate one.

It tells the reader what is supported, what is still open, and where the boundary is.

This is especially important when AI is part of the workflow. A model can make weak evidence sound clean. It can turn messy notes into a fluent paragraph. It can make uncertainty disappear simply because fluent writing has no visible gaps.

The evidence log does the opposite.

It keeps the gaps visible.

The Full Template

I published a practical ProjectOSINT guide with a copyable evidence log template for claim verification.

It includes:

• a basic evidence log table;

• a more detailed template for sensitive claims;

• examples of source limitations;

• confidence levels;

• common mistakes;

• prompts for using AI without treating it as a source.

Read it here:

Evidence Log Template for Claim Verification

The core idea is simple:

Break the claim before you search.

Log the source before you conclude.

Name the limitation before you assign confidence.

That is where verification becomes visible.

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

A scam message used to be easy to distrust.

The spelling was strange. The layout was wrong. The link looked suspicious. The fake delivery notice felt slightly off. The bank warning had the wrong tone. The website copied a brand, but not quite well enough.

That margin is shrinking.

Generative AI has given scammers a new production layer: better text, faster variations, more convincing templates, translated messages, cloned branding, realistic fake websites and the ability to test many versions of the same deception at scale.

Google is now trying to fight back.

But the difficult question is not whether Google is doing something.

The question is whether the response can ever be fast enough once AI-assisted scams become industrial infrastructure.

The Outsider case

According to Google’s lawsuit and reporting by The Wall Street Journal and other outlets, the company has sued a China-linked cybercrime network known as Outsider.

Google says the group used Gemini and other AI tools to support large-scale SMS phishing campaigns. The operation allegedly relied on fake websites impersonating telecom companies, government services and commercial brands. Victims received familiar messages: package alerts, urgent account warnings, reward notices, bank-related panic messages or other prompts designed to push them toward a fraudulent link.

From there, the workflow was simple.

The message created urgency. The website created trust. The form collected payment card details, credentials or personal information.

The numbers reported are significant. Google and law enforcement-linked reporting describe thousands of fake websites, millions of scam messages and large numbers of affected users. The Wall Street Journal reported that Outsider used more than 8,000 phishing websites and that the broader operation was connected to millions of stolen credit card numbers and very large estimated losses. Other reports cite more than 9,000 fake websites and millions of fraudulent URLs or messages.

The exact figures vary by source and by how the operation is defined.

The pattern is clearer than the number:

AI did not create phishing.
AI helped phishing scale better.

That distinction matters.

Phishing is old. SMS scams are old. Fake delivery alerts are old. Fake bank warnings are old. What changes with AI is the speed, volume and adaptability of the operation.

Scammers no longer need one perfect message. They can generate thousands of decent ones.

Why this is an OSINT problem

At first glance, this may look like a cybersecurity story.

It is also an OSINT story.

Every phishing campaign leaves public traces:

• domains;

• URLs;

• landing pages;

• logos;

• brand impersonation patterns;

• phone numbers;

• text-message templates;

• hosting infrastructure;

• certificates;

• payment flows;

• reused wording;

• archived pages;

• screenshots shared by victims;

• reports from telecom providers, platforms and security teams.

The problem is that AI changes how those traces behave.

A traditional scam campaign may reuse the same text, same layout, same domain pattern or same translation mistakes. Those repetitions help investigators connect cases.

AI-generated campaigns can mutate more easily.

The message can change. The landing page can change. The brand copy can become more natural. The fake website can be rebuilt quickly. A scammer can ask a model to adapt the same lure to another carrier, another bank, another country or another language.

This does not make the campaign invisible.

It makes the evidence more distributed.

Instead of looking only for identical text, investigators need to look for systems:

• repeated infrastructure;

• domain registration patterns;

• shared hosting;

• common form behavior;

• similar data collection flows;

• reused templates behind different surface designs;

• timing of campaigns;

• overlap between SMS lures and landing pages;

• payment card collection logic;

• brand impersonation clusters.

The surface becomes more flexible.

The workflow remains traceable.

Google’s response is serious

Google is not treating this as a small abuse case.

The company is using litigation, platform monitoring, user reports, partnerships with telecom providers and cooperation with law enforcement. It is also supporting legislation aimed at reducing scam harm, including measures focused on seniors and public education around AI-enabled fraud.

This matters.

Legal action can help disrupt infrastructure. Telecom partnerships can block messages before they reach users. Android protections can reduce exposure. Public reporting can help users recognize patterns. Lawsuits can reveal how scam ecosystems operate and put pressure on repeat actors.

Google has also rolled out fake call detection in the Phone by Google app, designed to warn users when a call appears to be impersonating one of their contacts. That responds to another AI-enabled risk: voice impersonation and spoofed calls.

These are not cosmetic steps.

They show that scam defense is moving from individual user advice toward platform-level intervention.

But they also reveal the timing problem.

The response arrives after the scale is already visible.

The timing problem

AI abuse is often detected after harm has already happened.

That is not unique to Google. It is a structural problem in AI safety and platform security.

Platforms usually see abuse through signals:

• user reports;

• unusual traffic;

• repeated prompt patterns;

• suspicious account behavior;

• takedown requests;

• law enforcement referrals;

• infrastructure overlap;

• brand impersonation complaints;

• payment fraud indicators.

But by the time those signals become strong enough to justify action, the campaign may already be large.

This is the central weakness of reactive defense.

It can reduce ongoing harm. It can remove domains. It can block messages. It can sue operators. It can warn users.

But it often cannot prevent the first wave.

AI makes this worse because it lowers the cost of producing the first wave. A bad actor does not need to build every fake page by hand. They can generate code, copy, translations and variations. Even if filters block some requests, ordinary-looking prompts can still support abuse when placed inside a larger criminal workflow.

That is the hard part.

A request to generate website code is not automatically malicious.

A request to rewrite a message is not automatically malicious.

A request to translate text is not automatically malicious.

The abuse emerges from the context, the scale, the destination and the operational chain.

Current AI systems are still much better at detecting isolated dangerous content than at understanding how many harmless-looking steps become a fraud machine.

The Pandora’s box question

This is where the uncomfortable question appears.

Should models with this kind of production power be available so widely, so easily and with so little friction?

There is no simple answer.

If access is too restricted, legitimate researchers, journalists, small businesses, developers and civil society groups lose useful tools. AI can help defenders too: writing detection rules, translating scam reports, clustering phishing patterns, summarizing victim complaints, analyzing suspicious domains and explaining threats to non-technical users.

If access is too open, attackers get the same productivity boost.

The issue is not that AI “causes” scams.

The issue is that AI changes the economics of scams.

It makes low-quality deception cheaper to improve. It makes internationalization easier. It makes brand imitation faster. It lets criminals test more lures, more languages and more page designs. It helps small teams behave like larger operations.

That is why legal action after the fact may never be enough.

The industry needs stronger abuse modeling before deployment, not only better takedowns afterward.

What proactive defense would look like

Proactive defense does not mean banning every risky capability.

It means treating scam production as a system, not as a single prompt.

For AI companies, that could include:

• stronger monitoring for repeated generation of phishing-like templates;

• risk scoring based on account behavior over time;

• friction for bulk generation of brand-impersonation material;

• better detection of multi-step scam workflows;

• partnerships with telecom providers, browsers, registrars and payment processors;

• faster sharing of abuse indicators with trusted security teams;

• red-team testing focused on fraud operations, not only prohibited content;

• transparency reports on AI-assisted abuse categories.

For investigators, it means adapting the workflow.

Do not only ask:

Was this message generated by AI?

Ask:

What system produced, distributed and monetized this scam?

That system includes the message, the phone number, the URL, the domain, the landing page, the form, the payment flow, the hosting, the copied brand assets, the delivery channel and the resale or use of stolen data.

AI is one layer of that system.

Not the whole story.

The defender’s dilemma

The same models that help scammers also help defenders.

An analyst can use AI to cluster scam reports, summarize victim messages, identify repeated wording, translate foreign-language lures, generate regex patterns, draft user warnings or compare suspicious pages.

A telecom provider can use machine learning to block spam before delivery.

A browser can warn users before they submit data to a known malicious page.

A phone app can detect impersonation signals.

But this creates a strange race.

Attackers use AI to generate more variants.

Defenders use AI to detect more variants.

Attackers adapt.

Defenders update.

The user still receives the message.

That is why public education remains necessary, even when platforms improve. Not because users should carry the whole burden, but because the last step of many scams is still psychological: urgency, fear, reward, authority, scarcity, panic.

AI improves the surface.

The old emotional triggers remain.

The warning from the AI safety debate

The broader AI safety debate often sounds abstract: frontier models, dangerous capabilities, alignment, export controls, catastrophic misuse.

Scams make the problem concrete.

You do not need a science-fiction scenario to see how AI changes risk. A fake carrier website, a convincing SMS, a cloned voice, a realistic brand page and a payment form are enough.

Companies such as Anthropic have warned that powerful AI systems can create new categories of misuse if deployment moves faster than safeguards. Whether one agrees with every warning or not, the Google case shows the practical version of the same concern:

once a capability is widely available, abuse may scale before the control layer is mature.

The question is no longer whether criminals will use AI.

They already are.

The question is whether AI companies can detect system-level abuse before it reaches millions of people.

What to watch next

For OSINT researchers and digital safety teams, the Google case is worth following for several reasons.

First, the lawsuit may reveal how AI-generated scam infrastructure is organized: templates, domains, delivery channels, brand impersonation, accounts and monetization.

Second, telecom partnerships may show whether SMS fraud can be blocked earlier in the chain or only after large-scale reporting.

Third, user-facing defenses such as fake call detection may show how much protection can be moved onto the device.

Fourth, legislation may expand the responsibilities of platforms, carriers and AI providers.

Finally, the case may become a test of accountability. If an AI model is used to produce part of a scam workflow, what responsibility does the model provider have? What responsibility belongs to telecom carriers? What belongs to registrars, hosting providers, payment processors and app platforms?

No single actor owns the whole chain.

That is exactly why the chain matters.

The practical takeaway

For users, the basic rule remains simple:

do not trust urgency delivered by a message.

If a package, bank, carrier, government office or platform account appears to require immediate action, do not use the link in the message. Go through the official app or website. Check the domain. Slow down the decision.

For investigators, the rule is different:

do not focus only on whether AI wrote the text.

Map the operation.

Look for repeated infrastructure, domain clusters, brand impersonation patterns, landing page behavior, data collection flows, telecom signals and payment paths.

AI-generated scams are not magic.

They are systems.

Google’s lawsuit may disrupt one of them.

But the larger lesson is harder: if AI turns scam production into an industrial process, then takedowns after the fact will always feel late.

The next phase of AI safety will not only be about preventing spectacular misuse.

It will be about stopping ordinary fraud from becoming faster, cheaper and more convincing than our defenses.

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

Someone sees a claim, opens a search engine, checks a social platform, runs a reverse image search, asks an AI tool for help, and begins collecting fragments before the real question has been defined.

That is how noise enters the investigation.

The first step should be slower.

Before asking whether a claim is true, ask what the claim is made of.

Take a sentence like this:

This video shows police using tear gas during a protest in Madrid on 10 June 2026.

It looks like one claim. It is not.

It contains several smaller claims:

• the content is a video;

• the actor is police;

• the action is the use of tear gas;

• the event is a protest;

• the place is Madrid;

• the date is 10 June 2026.

Each part needs a different kind of evidence.

A timestamp may help with publication timing, but not necessarily with recording time. A street sign may help with location, but not with the date. A local news report may confirm that a protest happened, but not that this specific video shows that protest.

This is where AI can be useful in OSINT.

Not as a truth machine. Not as a source. Not as a shortcut around verification.

AI is useful when it helps you slow down the claim.

You can ask it to separate entities, actions, time, and place. You can ask it to turn each part into verification questions. You can ask it to suggest source types: maps, archives, official pages, local media, social platforms, weather records, earlier uploads, or public documents.

Then the actual work begins.

You still have to search manually. You still have to check primary sources. You still have to decide whether a screenshot is enough, whether a report supports the specific claim, whether two sources are independent, and whether your conclusion deserves high confidence or only cautious wording.

The useful role of AI is not to close the investigation.

It is to expose the gaps before you pretend they are closed.

A simple prompt to use before you start

Break this claim into separate verifiable components. For each component, explain what type of evidence would support it, what would not be enough, and what source types should be checked first.

Claim: [paste the claim]

Then edit the result.

Remove weak suggestions. Add local sources. Add language variations. Add the source types that AI may have missed. Treat the output as a planning layer, not as evidence.

The difference matters.

An AI-generated investigation plan can help you ask better questions. It cannot tell you what happened.

The language of uncertainty

A good OSINT conclusion does not force certainty where the evidence does not support it.

Useful wording includes:

• verified;

• likely;

• consistent with;

• unverified;

• false or misleading.

Those are not stylistic choices. They are analytical boundaries.

If a video matches a location but the date is still unclear, the finding is not fully verified. If a username appears across two platforms, that may be an indicator, not an identity confirmation. If a source has not been found, that does not automatically make the claim false.

Good OSINT protects the distance between evidence and conclusion.

AI can help maintain that distance if you use it as a reviewer:

Review this evidence log. Identify weak assumptions, missing source types, possible false positives, and claims that are not yet supported. Do not decide whether the original claim is true.

That last sentence matters.

Do not let the tool become the judge.

The full workflow

I published a practical guide on ProjectOSINT that turns this idea into a step-by-step workflow:

1. write the claim as one sentence;

2. separate entities, actions, time, and place;

3. turn each part into verification questions;

4. build a source map;

5. generate search queries;

6. test them manually;

7. keep an evidence log;

8. use AI to identify gaps;

9. assign confidence levels;

10. write the conclusion with limits.

Read the full guide here:

How to Turn a News Claim Into an OSINT Workflow With AI

The main point is simple: AI should not make OSINT faster at the cost of evidence.

It should make the workflow more explicit.

Break the claim. Map the sources. Log the evidence. Name the uncertainty.

That is where verification starts.

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

A victim sends you three screenshots, a dead project website, and a long Ethereum address that starts with 0x.

They say they lost money in an NFT collection. The Discord server is gone. The social accounts have disappeared. The project page no longer loads. The only thing that still exists is the blockchain trace.

That is usually enough to start.

NFT fraud can look technical from the outside, but many investigations do not begin with code. They begin with a simple evidence problem: what existed, who controlled it, where the money moved, and which parts can be documented before they disappear.

The mistake is to treat “crypto” as the investigation.

The better approach is to treat the NFT case as a normal OSINT workflow with a few specific objects: wallets, contracts, transactions, marketplaces, archived pages, social profiles, and public scam reports.

The blockchain gives you part of the trail. It does not give you the whole story.

What an NFT Scam Investigation Is Really About

An NFT is often described as a unique digital certificate linked to an asset: an image, collectible, audio file, video, or other digital object. In many scams, the fraud is not in the image itself. It is in the promise connected to it: future value, community access, exclusive benefits, a roadmap, a game, a token, a metaverse, a limited collection, or the credibility of the team.

For investigation purposes, the key point is simpler:

An NFT project creates public traces before, during, and after the sale.

Those traces can include:

• the project website;

• the smart contract;

• the creator wallet;

• the wallet receiving payments;

• marketplace activity;

• Discord announcements;

• social media posts;

• usernames used by the team;

• transaction flows after the sale;

• previous scam reports involving the same wallet, domain, or username.

An NFT scam case is rarely solved by one screenshot or one transaction. It is built by connecting those traces carefully, without turning every clue into an accusation.

The System Map: Where the Evidence Lives

The first layer is the web layer.

This includes the project site, roadmap, team page, mint page, whitepaper, social accounts, Discord announcements, and promotional material. This layer often disappears quickly after a rug pull or fraudulent launch.

The second layer is the blockchain layer.

This includes the contract address, creator wallet, payment wallet, transaction history, transfers, secondary wallets, exchange deposits, and possible use of mixers. This layer is harder to erase because the transaction history remains public.

The third layer is the social layer.

This includes usernames, avatars, developer handles, reused bios, interviews, GitHub accounts, Reddit posts, Telegram handles, LinkedIn profiles, and any public identity signals connected to the project team.

The fourth layer is the reporting layer.

This includes public scam databases, wallet abuse reports, victim complaints, marketplace warnings, and previous cases involving the same infrastructure.

Each layer answers a different question. The web layer shows what was promised. The blockchain layer shows where funds moved. The social layer may show who was publicly associated with the project. The reporting layer shows whether the same traces appear in other complaints.

Do not collapse these layers into one conclusion.

A Defensive Workflow for Investigating an NFT Scam

1. Preserve the web evidence before it disappears

Start with preservation, not analysis.

If the project is fraudulent, the website, social posts, Discord channels, roadmap, team page, and mint page may vanish quickly. Screenshots can help you remember what you saw, but they are weak if they are not documented properly.

What to collect:

• live project pages;

• team descriptions;

• roadmap claims;

• Discord announcements;

• social media posts;

• marketplace pages;

• whitepaper or project files;

• terms, disclaimers, and promotional claims.

What to record:

• URL;

• date and time;

• platform;

• account name;

• screenshot or archive link;

• what specific claim the page supports.

What it can prove:

• that a public claim existed at a specific time;

• that a project presented itself in a certain way;

• that specific usernames, wallets, domains, or promises were publicly connected.

What it cannot prove:

• who personally controlled the project;

• whether a promise was knowingly fraudulent;

• whether a screenshot alone is suitable for legal use.

For serious cases, preservation needs a stronger chain of custody than casual screenshots. The operational rule is simple: if the evidence may be used in a legal context, capture it in a way that can be defended later.

2. Identify the contract and the project wallets

The contract address is often the best starting point.

It may appear in the marketplace listing, the victim’s wallet history, the mint page, or the transaction receipt. Once you have the contract address, a block explorer can show the contract page, creator address, token activity, and related transactions.

Look for two addresses:

Creator wallet:
Payment wallet:

Sometimes they are the same. Sometimes one wallet created the contract and another received the funds. That difference matters because it may show how the project separated technical deployment from revenue collection.

What to look for:

• when the creator wallet was created;

• whether it was newly created before the launch;

• which wallet received mint payments;

• whether funds accumulated through many small payments;

• whether the wallet later moved most funds in one transaction.

What it can prove:

• which public addresses were involved in deployment or payment flow;

• how funds moved from buyers to project-controlled wallets;

• whether the wallet behavior matches known scam patterns.

What it cannot prove:

• the real-world identity of the person controlling the wallet;

• intent;

• full responsibility for the fraud.

On-chain attribution is not personal attribution. Keep that distinction visible.

3. Follow the money, but document each hop separately

In many rug pull cases, the pattern is not subtle.

A project wallet receives many small payments during the sale. Later, the funds move to another wallet. That wallet may split the amount into several smaller wallets. Some of those wallets may send funds to a centralized exchange. Others may send funds to a mixer or another obscuring service.

Do not write “the scammer sent the money to X” too early.

Write what the chain shows:

Wallet A received buyer payments.
Wallet A sent most of the balance to Wallet B.
Wallet B split the funds across six wallets.
Four wallets later sent funds to centralized exchanges.
Two wallets sent funds toward mixing infrastructure.

This wording matters.

It keeps the evidence factual and avoids unsupported personal attribution.

What to look for:

• concentration of funds after the sale;

• large outbound transfers after the project stops communicating;

• splitting into multiple new wallets;

• deposits to centralized exchanges;

• interaction with mixers;

• repeated patterns across other projects.

What it can prove:

• movement of funds;

• timing;

• destination categories;

• possible legal points of inquiry if centralized exchanges are involved.

What it cannot prove:

• who controlled the destination account;

• whether exchange KYC identifies a suspect without legal process;

• whether a mixer breaks all investigative value.

If funds reach a centralized exchange, the investigator does not “identify” the user directly. That requires legal authority. The OSINT task is to document the route clearly enough that the next legal step is possible.

4. Check whether the wallet, domain, or username appears in public scam reports

Before going deeper, check whether the same wallet, domain, marketplace account, or username appears in public abuse reports.

This can help in two ways.

First, it may show that the case is not isolated. A wallet involved in one NFT project may also appear in previous complaints. A domain may be connected to multiple phishing pages. A username may have been reported by other victims.

Second, public reports may contain leads you would not find from the victim’s material alone: alternative usernames, related domains, transaction hashes, project names, or victim timelines.

What to look for:

• wallet address reports;

• domain reports;

• repeated usernames;

• similar project names;

• transaction hashes;

• descriptions of the same pattern.

What it can prove:

• that other people publicly reported similar activity;

• that the same technical traces appear across complaints;

• that a pattern may be broader than one victim.

What it cannot prove:

• that every report is accurate;

• that all reported cases involve the same operator;

• that public reporting alone is enough for legal attribution.

Treat public reports as leads, not final proof.

5. Investigate the public social layer of the project team

The blockchain shows transactions. The social layer may show how the project was presented and who publicly associated themselves with it.

NFT projects often have team handles, developer names, artist names, founder personas, Discord moderators, Twitter accounts, or promotional interviews. Some are real. Some are pseudonymous. Some are borrowed. Some are generated. Some are reused across platforms.

The OSINT task is not to dox private people. It is to document public associations relevant to the case.

What to look for:

• reused usernames across platforms;

• public GitHub accounts connected to project code or websites;

• interviews, podcasts, or launch announcements;

• profile images that appear elsewhere;

• domain registration traces, when available;

• old archived pages that listed team details before deletion.

What it can prove:

• that a public account was associated with the project;

• that the same username appears across platforms;

• that an avatar or profile may be copied, synthetic, or misleading;

• that project claims about the team may be inconsistent.

What it cannot prove:

• real identity without stronger corroboration;

• criminal responsibility;

• ownership of a wallet unless additional evidence connects the account to the address.

This step is where many investigations become risky. Do not publish a real person’s identity simply because a username appears connected. Preserve the finding, assess confidence, and route sensitive attribution through legal or organizational channels.

Red Flags Before the Scam Happens

Many NFT scams show warning signs before victims buy.

No single signal is enough. Several together should change the risk assessment.

Useful warning signs include:

• anonymous team with no verifiable history;

• unrealistic roadmap promising a game, token, marketplace, community benefits, and future utility in a short period;

• large community numbers with little real conversation;

• sudden sales volume from newly created wallets;

• paid promotion presented as personal recommendation;

• unverified contract;

• creator-controlled minting functions that may allow excessive token creation;

• copied artwork or near-duplicate collection names;

• domain and social accounts created shortly before launch.

The analytical value of these signs is not that they “prove” fraud. They help decide where to look next.

If the team is anonymous, focus on social OSINT and archived pages. If the sales volume looks artificial, examine wallet relationships. If the contract is unverified, document that limitation. If the art appears copied, use reverse image search and marketplace history.

Red flags guide the workflow. They do not replace it.

A Fictional Mini-Case

Assume a victim lost 9 ETH in a collection called “Lunar Orchard Pass.”

The website is offline. The social account is deleted. The victim still has the NFT contract address and one screenshot from the mint page.

The investigator starts with the contract.

The contract page shows that Wallet A created the collection two weeks before launch. Wallet B received the mint payments. Over 36 hours, Wallet B received many small buyer transactions. Four days later, almost the entire balance moved to Wallet C.

Wallet C split the funds across five new addresses.

Three of those addresses later sent funds to centralized exchanges. Two interacted with a mixing service.

At this point, the investigator has not identified a person. But the case is no longer vague. There is a transaction path, a timeline, and several points that legal authorities may be able to query.

The investigator then checks public reports. Wallet B appears in two previous complaints involving smaller NFT drops with similar disappearance patterns.

The social layer adds context. An archived version of the project page lists three team handles. One handle appears on a public code repository connected to an older crypto project. Another profile image appears to be reused from an unrelated account. A third handle appears only in the deleted project environment.

The result is not a public accusation.

The result is a structured dossier:

• archived project claims;

• contract and wallet map;

• transaction path;

• public report matches;

• social OSINT leads;

• confidence levels;

• open questions;

• legal handoff points.

That is the difference between “someone scammed my client” and an evidence chain.

Critical Mistakes

The first mistake is starting with identity.

Start with traces. Identity may come later, and often only through legal process.

The second mistake is treating the blockchain as complete truth.

The blockchain can show transactions. It cannot explain intent, ownership, coercion, authorization, or whether a wallet was controlled by one person or a group.

The third mistake is failing to preserve disappearing material.

If the project page, Discord messages, and team claims vanish before capture, the investigation becomes weaker even if the blockchain remains intact.

The fourth mistake is overvaluing public reports.

Reports are useful leads. They need corroboration.

The fifth mistake is publishing personal attribution too early.

OSINT can support a case. It should not become harassment, doxxing, or trial by thread.

The Transferable Method

NFT scams are not special because they are mysterious.

They are special because they combine unstable web evidence with durable transaction evidence.

The web layer disappears. The blockchain layer remains. The social layer fragments. The legal layer decides what can be turned into formal identification.

The investigator’s job is to keep those layers separate long enough to build a defensible chain:

Preserve what existed.
Identify the contract and wallets.
Trace the funds.
Check public abuse reports.
Map the social layer.
Mark what is proven, inferred, and still unknown.

You do not need to be a crypto specialist to start this kind of investigation.

You need to avoid the two traps: being intimidated by the blockchain, and being overconfident because the blockchain is public.

The useful question is not “Who is behind this wallet?”.

The useful first question is:

What can this wallet, this contract, this page, and this username each prove on their own?

Once you answer that, the case becomes less about crypto.

It becomes OSINT again.

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

The dangerous part of an AI support system is not the chatbot interface.

It is what the chatbot is allowed to do.

An account support bot that can answer questions is one thing. An account support bot that can change account details, trigger recovery flows, connect a new email address, or act inside a platform’s identity system is something else. At that point, the bot is no longer only a communication layer. It becomes an operator.

That distinction matters for OSINT, account security, platform investigations, and digital risk analysis.

If a human support agent makes a mistake, the error may still be serious. But there are familiar controls around human support: training, escalation, logs, supervision, internal policy, and sometimes personal accountability. With AI support, the weak point can move. The question is no longer only whether the system gives a correct answer. The question is whether it has been connected to functions that can change reality.

In account security, “reality” can mean a recovery email, a password reset path, a login credential, a verification step, or access to a private profile.

That is where the problem begins.

The case is not only about Instagram

The reported incident involved attackers persuading an AI support system to help with account access. The public material around the case describes screenshots and videos shared in researcher and hacking communities, with the AI system apparently accepting requests that should have required stronger identity verification.

The specific platform matters, but the larger lesson is not platform-specific.

This is a pattern.

Companies are moving AI systems closer to operational workflows: support, moderation, account recovery, customer service, business tools, internal assistance, content review, and eventually agentic actions. These systems are not just reading text. They are being placed near buttons, permissions, databases, and workflows that can produce real effects.

For an investigator, this creates a new kind of object to examine: not just the account, not just the platform, not just the attacker, but the automated decision layer between a user request and a privileged action.

That layer can fail in ways that look different from traditional security failures.

There may be no stolen password. No malware. No phishing page. No exposed database. The weak point may be an automated assistant that accepts a request, interprets it as legitimate, and routes it into an account-change process.

System map: where the evidence lives

To investigate this kind of incident, do not start with the chatbot as a personality. Start with the system around it.

The information is usually distributed across several layers:

• public reports describing the incident;

• platform statements or posts confirming whether a fix was applied;

• screenshots or videos showing the claimed flow;

• support documentation explaining legitimate account recovery;

• user reports from affected accounts;

• researcher discussion in public or semi-public communities;

• platform policy on account changes, recovery, verification, and support automation.

Each layer has a different evidentiary value.

A screenshot can show what someone claims happened, but it may not prove the full sequence. A video can show a flow, but it may not prove how broadly the flow worked. A company statement can confirm that an issue was addressed, but it may not explain the technical cause. A researcher discussion can point to a pattern, but it may also include exaggeration, incomplete testing, or copied claims.

The OSINT task is not to treat one layer as enough. It is to reconstruct what each layer can support.

A defensive workflow for investigating AI support failures

1. Separate the claim from the mechanism

Start by writing the claim in one sentence.

Example:

An AI support system was reportedly persuaded to assist with account access changes.

Then separate it from the possible mechanism:

Possible mechanism: the AI system accepted a request related to account recovery or account detail changes without sufficient verification.

This prevents the first common mistake: turning a reported outcome into a confirmed technical explanation. The outcome may be visible. The mechanism may still be uncertain.

What to look for:

• wording that describes what happened;

• wording that describes how it supposedly happened;

• whether the two are supported by the same evidence.

What it can prove:

• the scope of the allegation;

• the distinction between observed behavior and inferred cause.

What it cannot prove:

• whether the exploit worked for all accounts;

• whether the same pathway is still available;

• whether the system failed because of the model, the workflow, permissions, or surrounding controls.

2. Map the AI system’s authority

The central question is not “Was the bot smart enough?”.

The central question is:

What was the bot allowed to do?

In a support environment, an AI assistant may have several possible roles. It may answer questions. It may collect information. It may summarize a case for a human agent. It may initiate a support ticket. It may trigger an account flow. It may call internal tools.

These roles should not be treated as the same.

What to look for:

• whether the bot only responded with information;

• whether it initiated or requested account changes;

• whether it accessed account-specific data;

• whether a human review step appeared to exist;

• whether verification happened before any sensitive action.

What it can prove:

• the level of operational privilege exposed to the AI layer.

What it cannot prove:

• the exact internal architecture unless internal documentation, logs, or verified technical analysis are available.

3. Build an evidence chain from public material

For public investigation, create a simple evidence table.

Use four columns:

Source type:
Claim supported:
Confidence:
Open question:

For example, a public article may support the fact that the incident was reported and that the company said it had fixed the issue. A screenshot may support that a certain interaction was shown. A company post may support that the issue was acknowledged or addressed. None of these alone necessarily proves the full exploitability of the system.

This is where OSINT discipline matters.

Do not collapse all evidence into one conclusion. Keep the chain visible.

4. Identify the missing controls

In account access incidents, useful analysis often comes from asking which control should have stopped the flow.

Possible controls include:

• identity verification before account changes;

• limits on what an AI assistant can modify;

• mandatory human approval for sensitive actions;

• rate limits on repeated attempts;

• anomaly detection for unusual recovery requests;

• separation between conversational output and account operations;

• audit logs that show who or what initiated the change.

The goal is not to guess the internal failure. The goal is to define the control questions.

For OSINT readers, this is useful because it moves the discussion away from vague “AI failed” language and toward a concrete audit frame.

5. Preserve what remains uncertain

An AI support incident can be easy to overstate.

Public material may not show:

• how many accounts were affected;

• whether the same method worked consistently;

• whether the weakness was in the model, the support workflow, the permissions layer, or the account recovery policy;

• whether attackers needed prior information about the target;

• whether all steps were fully automated;

• whether a patch fixed the root cause or only blocked one path.

These gaps are not a weakness in your analysis. They are part of the analysis.

Good OSINT does not fill unknowns with confidence. It marks them.

Critical issues and false positives

There are three common mistakes in this type of investigation.

The first is treating the AI as the attacker. The attacker is still the human operator. The AI system is the manipulated interface or the vulnerable operational layer.

The second is treating every chatbot as equally dangerous. A chatbot that only answers general questions is not the same as an agent connected to account tools. Risk depends on authority.

The third is assuming that a company statement closes the investigation. A fix may close one pathway, but it does not automatically answer broader questions about design, privilege boundaries, escalation, auditability, and future agentic workflows.

For platform investigators, the real question is not whether this single path has been closed.

The real question is how many similar paths are being created as AI systems are given more operational power.

The analytical layer: AI support as an access surface

Traditional account security focuses on credentials, recovery emails, SIM swaps, phishing pages, malware, leaked databases, and social engineering against human support.

AI support introduces a hybrid surface.

It can be conversational like social engineering, automated like a workflow, and privileged like internal support. That combination is what makes it important.

An attacker does not always need to break encryption, steal a password, or compromise a device if a support system can be convinced to modify the account path. The practical risk is not “AI is insecure” as a slogan. The practical risk is that AI can become a trusted intermediary between an untrusted request and a sensitive action.

That is the pattern investigators should watch.

Not every AI support feature is dangerous. Not every incident proves systemic failure. But any AI system connected to identity, account recovery, permissions, payments, personal data, moderation, or platform enforcement should be treated as a high-risk operational layer.

The question for researchers is simple:

Where does the AI stop talking and start acting?

That boundary is now part of the evidence.

Operational takeaway

When investigating AI support incidents, do not focus only on the prompt, the chatbot, or the screenshot.

Map the authority.

Ask what the system could access, what it could change, what verification was required, what logs might exist, what human review was bypassed or preserved, and what remains unknown from public material.

The future of account security will not only depend on stronger passwords or better recovery flows. It will also depend on whether platforms can prevent AI agents from becoming shortcuts around their own controls.

For OSINT, this creates a new habit: every time an AI system is placed inside a support workflow, investigate it as both an interface and a permission boundary.

That is where the next class of platform failures may become visible first.

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

Now, increasingly, it begins with an answer.

That shift looks convenient on the surface. Google AI Mode and AI Overviews are designed to compress the web into a conversational response: a user asks, the system reads across pages, summarizes what it finds, and offers a few links for context. For everyday browsing, this may feel faster. For OSINT, journalism, and digital investigation, it changes something more fundamental.

It changes the analyst’s first contact with evidence.

The problem is not only that AI-generated answers can be wrong. The deeper issue is that they can make the original source chain harder to see. A claim may arrive already cleaned, compressed, paraphrased, and detached from the messy context that gives it meaning: who published it, when it appeared, what wording was used, what other sources contradicted it, and whether the page has changed since.

For OSINT work, that context is not decoration. It is the work.

An AI answer can be useful as a lead. It can surface entities, suggest possible angles, and help map a topic quickly. But a lead is not a source. A generated paragraph is not an evidence trail. And a link attached to an AI summary is not automatically proof that the claim is supported by that page.

This is where AI-mediated search becomes risky: it can make weak evidence look tidy.

One of the key shifts is interface behavior. Traditional search pushed the investigator outward: open a result, compare pages, inspect timestamps, save URLs, look for primary material. AI Mode can keep the user inside the conversation. Follow-up questions become easier than source checking. The answer improves in fluency, but the research path may become less reproducible.

That matters especially in investigations involving breaking news, cyber incidents, disinformation, corporate ownership, conflict footage, public records, sanctions, online identities, or any topic where timing and provenance affect interpretation.

A generated answer may merge three very different source types into one smooth paragraph: an official statement, a media report, and a social media claim. To a casual reader, the result may look coherent. To an investigator, that coherence can be a warning sign.

The missing question is: what exactly supports what?

This is the discipline OSINT needs to preserve. AI Mode should not be treated as the end point of research, but as a starting layer that must be reopened. The analyst has to separate the AI answer from the linked sources, then separate the linked sources from independently verified evidence.

That means recording the query, capturing the generated answer, opening every visible source, checking whether each source actually supports the claim, and searching outside the AI interface. It also means preserving dates, URLs, screenshots, archive links, and the conditions under which the result appeared.

The workflow is not complicated, but it is easy to skip because the interface is built to reduce friction.

OSINT often requires putting friction back.

There is also a personalization problem. AI search can vary based on account state, location, language, subscriptions, previous activity, and interface changes. Two analysts may not see the same answer or the same source set. That does not make AI search unusable. It makes documentation more important.

The central rule is simple: never cite the answer when you can cite the evidence.

The full piece breaks down the practical workflow for reopening the source chain behind AI-generated search results, including what to capture, what to verify, and how to avoid treating summaries as findings.

Read the full analysis on Project OSINT:

https://projectosint.com/google-ai-mode-osint-disappearing-source

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

On May 18, during a podcast recorded in Berlin, former German Chancellor Angela Merkel said: “In ten years, we hope the war in Ukraine will be over.” The sentence circulated widely, interpreted by some as a slip, by others as a deliberate signal. Neither reading engages with the more verifiable question: what does the institutional timeline around that statement actually look like?

Merkel is not a serving official. She holds no formal position in the EU or the German government. Her statements carry no operational authority. What they do carry is context — and that context is documented.

The Minsk Baseline

Any reading of Merkel’s current statements requires anchoring to a previous one. On December 7, 2022, in an interview with Die Zeit, Merkel stated that the Minsk agreements signed in 2014 and 2015 had functioned, in her assessment, as time for Ukraine to build military capacity. Her precise framing: the agreements gave Ukraine “valuable time” to develop its defenses.

That interview is publicly available and has been widely reported. It generated significant diplomatic friction at the time, particularly from Russian officials who cited it as retroactive admission of bad faith in the negotiations. The German government did not issue a formal correction.

This is the evidentiary baseline: a documented statement by a former head of government, on record, regarding the functional use of a diplomatic process. Whether that represents candor, revisionism, or something else is a question the record leaves open. What the record does not leave open is that the statement was made.

The German Military Doctrine: April 2025

In April 2025, the German government published a new military doctrine — the Bundeswehrplanung 2025 — outlining a structural expansion of the armed forces across three defined phases:

• By 2029: Rapid rearmament. Active personnel increases from approximately 185,000 to 260,000. Combat-ready strength, including reserves, reaches 460,000.

• By 2035: Full-spectrum expansion across all branches.

• By 2039: Technology-led superiority as the doctrinal objective.

The doctrine also revises the conscription framework, introducing a mechanism that allows mandatory service if voluntary recruitment falls short of targets. Russia is formally designated as the primary threat to European security.

These figures come from the published doctrine itself, not from interpretive sources. The 2039 endpoint is the document’s own language.

The EU Defense Union Proposal

In the same month, European Commissioner for Defence Andrius Kubilius publicly presented a proposal for a formal European Defence Union. The core elements of the proposal, as presented:

• A new treaty structure integrating the EU, the United Kingdom, Norway, and Ukraine under a shared security framework.

• A permanent EU Security Council.

• A standing EU rapid-reaction force of 100,000 personnel with centralized command.

• EU-level weapons stockpiling.

The proposal is framed as an extension of European Commission President Ursula von der Leyen’s €930 billion defense and armaments program, which targets 2030 as its primary delivery horizon. Von der Leyen’s program focuses on expanding European weapons production capacity and military readiness across member states.

The Kubilius proposal is a Commission-level document. It has not been adopted as binding policy. Its timeline, budget architecture, and institutional form remain subject to member state negotiation.

What the Timelines Show

Laid side by side, three timelines emerge from the source material:

Document Origin Key Horizon Von der Leyen defense program European Commission 2030 German military doctrine (Bundeswehrplanung 2025) German Federal Government 2029 / 2035 / 2039 Kubilius EU Defence Union proposal European Commission 2030+ Merkel podcast statement Personal, non-official “ten years” (~2035)

The German doctrine’s full-spectrum expansion target is 2035. Merkel’s informal horizon is “ten years” from May 2025 — which lands at approximately 2035. That alignment is a documented fact. What it means — coordination, coincidence, or shared institutional understanding — is not established by the documents alone.

Verification Methodology

For a reader who wants to verify this material independently, the chain is accessible:

Step 1 — Merkel podcast (May 18, 2025). Search German-language media archives using the terms “Merkel Podcast Berlin Mai 2025” and “zehn Jahre Ukraine.” Multiple outlets covered the appearance; transcripts or clips are available through ARD, ZDF, and Der Spiegel archives.

Step 2 — Die Zeit interview (December 7, 2022). The interview is indexed in Die Zeit‘s public archive. Search “Merkel Minsk Zeit Interview Dezember 2022.” The original German text is the primary source; translated summaries in English-language outlets vary in precision.

Step 3 — German military doctrine. The Bundeswehrplanung and associated documents are published by the Federal Ministry of Defence (Bundesministerium der Verteidigung). The April 2025 version is accessible via the ministry’s official portal. Personnel figures, phase timelines, and conscription provisions are directly verifiable in the original.

Step 4 — Kubilius proposal. European Commission communications are published in the Official Journal and the Commission’s newsroom. Search “Kubilius European Defence Union proposal 2025” in the Commission’s document database. Cross-reference with von der Leyen’s €930 billion figure in her State of the Union address archives.

Step 5 — Cross-reference and gap analysis. Note what the documents do not say: none of them reference Ukraine’s conflict in terms of a fixed endpoint. The German doctrine’s threat designation is categorical, not duration-dependent. Merkel’s “ten years” is a hope expressed in a non-official setting, not a planning document.

What Remains Unverified

The source material establishes the documents and statements listed above. It does not establish:

• Any coordination between Merkel’s statement and current German or EU planning cycles.

• That the Minsk admission reflects the official position of the German government, then or now.

• That the timelines in military doctrine and the Kubilius proposal are linked to a single strategic intent.

• That any of the above constitutes a policy to prolong the conflict rather than prepare for post-conflict security architecture.

These are analytical questions that the documents raise without answering. A rigorous reading distinguishes between what is documented, what is plausible given the documents, and what requires additional sourcing.

The Structural Pattern

What the documents collectively show is a European institutional architecture that is building toward mid-2030s military capacity as a planning horizon — regardless of how the Ukraine conflict resolves. The German doctrine explicitly extends to 2039. The EU defence proposal is framed around permanent structural integration, not crisis response.

Whether Merkel’s informal remark reflects awareness of that institutional timeline, or simply a realistic read of conflict dynamics, the documents do not decide. What they do show is that the timeline she named is not arbitrary relative to the planning documents that exist in the public record.

Readers who want to assess alignment between political statements and institutional timelines have the primary sources to do it. The gap between a politician’s words and a government’s documents is often where the most verifiable — and most consequential — information lives.

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

The alleged OnlyFans mega leak quickly became another giant number in the breach economy: hundreds of millions of records, leaked accounts, exposed identities.

But the operational problem starts elsewhere.

Not with passwords.
Not with direct platform compromise.
With correlation.

Researchers reviewing the reported sample noted something that changes the entire investigative angle: parts of the dataset may have originated from older leaks, public sources, and unrelated breach collections rather than one fresh intrusion.

That distinction matters more than most headlines suggest.

Because modern identity exposure rarely comes from a single dataset anymore. It comes from accumulation.

An email reused across:

• streaming accounts,

• newsletters,

• creator platforms,

• ecommerce profiles,

• gaming services,

• archived breaches

can quietly bridge identities that users assumed were separated.

A pseudonymous profile stops being pseudonymous once one repeated identifier connects the dots.

That is where OSINT becomes relevant.

The article breaks down how analysts actually evaluate breach claims:

• why samples matter more than headlines;

• how investigators separate public data from breach-exclusive data;

• why old datasets still create operational risk;

• how attackers inflate credibility by merging recycled leaks together;

• why phishing campaigns increasingly rely on emotional pressure instead of technical sophistication.

One section is particularly revealing: investigators often spend less time asking “Was the platform hacked?” and more time asking:

• Which identifiers overlap?

• Which timestamps do not match?

• Which records look recycled?

• Which accounts remain active?

• Which identities can realistically be correlated?

That verification layer is usually missing from public discussions.

The deeper issue extends far beyond one platform.

Dating apps, creator ecosystems, forums, gaming communities, subscription services, and pseudonymous online spaces all rely on the same fragile assumption: that fragmented identities remain disconnected.

Data correlation breaks that assumption surprisingly fast.

The full breakdown analyzes:

• the OSINT workflow used to validate breach claims;

• the difference between aggregation and intrusion;

• common mistakes analysts make when evaluating leaked datasets;

• how identity reconstruction happens through overlap rather than direct exposure.

Read the full article here:

👉 https://projectosint.com/onlyfans-mega-leak-osint-risk/

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup

That is the first trap in blockchain OSINT. A Bitcoin address, an Ethereum address, a transaction hash: they look precise, technical, almost definitive. You paste them into an explorer and the trail appears — timestamps, amounts, fees, counterparties, confirmations, token movements. The data is there. The mistake is believing the person is there too.

The full guide on Project OSINT starts from a realistic investigative entry point: a lawyer sends two wallet addresses and asks where the money went. One Ethereum. One Bitcoin. No names. No background. No case file. Just two strings and a question that sounds simple until the first methodological decision appears. Which explorer do you open? Which tab matters? Which output is the recipient, and which one is only change returning to the sender?

That decision matters because blockchain explorers are not interchangeable. Ethereum and Bitcoin are separate infrastructures. A wallet beginning with 0x belongs in an Ethereum explorer such as Etherscan. A Bitcoin address beginning with 1, 3, or bc1 belongs in a Bitcoin explorer such as Blockchain.com or mempool.space. Use the wrong interface and the investigation starts with noise, not evidence.

The useful part of a blockchain explorer is not that it “finds the criminal.” It does not. Its value is narrower, and that is exactly why it is powerful.

It can show whether funds moved.
It can show when they moved.
It can show whether the destination was a normal address, a smart contract, a token transfer, or possibly a centralized exchange.
It can show patterns: consolidation, dispersal, urgency, failed attempts, stablecoin conversion, repeated counterparties.

What it cannot show, by itself, is who controls the address. The guide is very clear on this point: blockchain addresses are pseudonymous. The explorer records the address, not the person. Attribution requires external convergence — legal process, exchange records, open-source correlation, court material, leaks, or behavioral links that can be independently checked.

That gap is where weak crypto investigations collapse.

One common error is treating a wallet label as proof. On Etherscan, labels can point to exchanges, protocols, mixers, or flagged addresses. But labels are not verdicts. They are leads. A tag can help structure the next question; it cannot close the case.

Another error is more technical but equally damaging: misreading Bitcoin outputs. Bitcoin does not behave like a simple bank transfer. A transaction may have multiple inputs and multiple outputs, and one of those outputs may be the sender’s own change address. Follow the wrong output, and the report sends the reader down a false path. The guide flags this as one of the most predictable mistakes in Bitcoin tracing.

The full piece also shows why Ethereum needs a different reading habit. The visible transfer is only the surface. Internal transactions, ERC-20 token movements, smart contract interactions, transaction fees, failed transactions, and decoded input data can all change the interpretation of what happened. A direct transfer, a token swap, and a contract interaction are not the same investigative event.

The real value of the method is not drama. It is discipline.

You do not start by naming a suspect.
You start by identifying the chain.
Then the explorer.
Then the wallet summary.
Then outgoing flows.
Then transaction-level fields.
Then the limits of what the data can prove.

The missing layer — and the reason the full guide is worth reading — is the workflow: how to move from a raw address to a structured analytical trail without overstating attribution, misreading outputs, or confusing public ledger data with identity evidence.

Read the full guide here:
👉 How to Read a Blockchain Explorer: OSINT Guide to Tracing Crypto Transactions

If this is useful, share it.

This is the weekly selection. But it’s not the only one.

If you’d like to read more: → full articles on the website

👉 https://projectosint.com

If you’d like to get the latest updates first: → Telegram

👉 https://t.me/osintprojectgroup