Is OSIRIS AI Legit and Safe? We Audited the Open-Source Intelligence Platform

OSIRIS is legitimate, genuinely useful and worth trying—but with important limitations.

After reviewing the live platform, its documentation, its current source code and earlier security research against the project, sherafy.com gives OSIRIS a qualified green light: 7.5/10.

For citizen journalists, researchers and open-source intelligence users, OSIRIS can be an excellent discovery and situational-awareness tool. It pulls aircraft, earthquakes, fires, public cameras, conflict reporting, cyber information, sanctions data and other public sources into one visual interface. It is free, openly licensed and can be self-hosted. Its GitHub repository had roughly 8,900 stars, 1,800 forks and more than 300 commits when we reviewed it on September 8, 2026.

But there is an equally important warning:

OSIRIS should be treated as a radar screen, not as the evidence itself.

Our code-level review found several places where authoritative-looking “intelligence” is actually produced by static judgments, keyword rules, approximate geography or an external generative AI model. We also found privacy considerations that are especially relevant to journalists, along with a history of legitimate security criticism that should not be erased simply because some of the problems were later fixed.

For ordinary public-source research, we would use OSIRIS.

For confidential sources, unpublished investigative targets or claims that could materially affect someone’s reputation, we would use much stricter precautions.

The sherafy.com verdict

That distinction is the key to understanding OSIRIS.

The underlying platform is useful.

Some of the intelligence-looking interpretation layered on top of those sources deserves considerably more skepticism.

What is OSIRIS?

OSIRIS—short for Open Source Intelligence & Reconnaissance Integrated System—is a web-based global intelligence dashboard hosted at osirisai.live and published as an open-source project on GitHub.

It combines numerous public data sources into a MapLibre-powered global interface. The project’s current documentation lists aviation, maritime activity, satellites, public CCTV, earthquakes, wildfires, severe weather, conflict information, cyber threats, sanctions searches, cryptocurrency tracing and a collection of reconnaissance tools. Its documentation exposes dozens of HTTP endpoints and provides instructions for running OSIRIS locally.

Current sources documented by the project include, among others:

• USGS earthquake data;
• NASA FIRMS fire detections;
• NASA EONET events;
• NOAA space-weather information;
• OpenSky aviation information;
• NVD vulnerability information;
• OpenSanctions data;
• public Telegram channels;
• transportation-camera networks;
• RSS and news sources.

That aggregation is the strongest argument for OSIRIS.

A journalist trying to understand an unfolding earthquake, wildfire, military development, aircraft movement or cyber incident may otherwise have to keep a dozen specialist tabs open. OSIRIS attempts to make those disparate sources visible through one operating picture.

That is real utility.

OSIRIS is open source—and that mattered enormously in this review

OSIRIS is released under the MIT license, and its application code is publicly inspectable. It can also be self-hosted with Node or Docker rather than requiring users to rely entirely on the public OSIRIS server.

This is more than a philosophical advantage.

It allowed us to investigate what apparently sophisticated features actually do.

If OSIRIS had been a closed commercial product, a user might reasonably assume that a score labeled “Country Intelligence Index,” an “AI Analysis” warning or a conflict point on a map came from some proprietary intelligence methodology.

Because the code is available, we can check.

What we found is mixed.

The country “risk scores” are largely human-assigned numbers

One of the clearest examples is OSIRIS’s current /api/country-risk implementation.

The code contains a manually written table assigning countries and territories base risk values.

Examples include:

• Ukraine: 85
• Russia: 72
• Israel: 78
• Palestine: 90
• Yemen: 88
• China: 35
• Taiwan: 45

Those numbers are stored directly in the source code alongside descriptive tags such as active_conflict, humanitarian_crisis, nuclear_risk and invasion_risk.

The current route does attempt to enrich those base values using recent USGS earthquake information, but there is no published statistical methodology demonstrating, for example, why one country should start at 78 rather than 72, or why a score of 90 represents a calibrated level of risk.

That does not make the feature useless.

A developer can reasonably create a heuristic classification for a dashboard.

The problem comes when a visually authoritative number is mistaken for a quantitatively validated intelligence product.

If OSIRIS says a territory has a risk score of 90, a journalist should not write:

OSIRIS intelligence assesses the country’s risk at 90 out of 100.

The more accurate description would be:

OSIRIS’s developers have assigned the territory a base risk score of 90 in the platform’s current source code.

Those are very different propositions.

An OSIRIS “AI Analysis” warning may not involve AI at all

The news feed contains an even clearer example of why source inspection matters.

OSIRIS currently calculates a risk_score by checking whether an article contains words such as “war,” “missile,” “strike,” “attack,” “nuclear,” “invasion,” “bomb,” “drone,” “sanctions,” “killed” and “destroyed.”

Each matching keyword increases the score until it reaches a maximum of 10.

That is a perfectly ordinary keyword heuristic.

However, when the score reaches eight or higher, the current code attaches this user-facing message:

“AI Analysis indicates elevated tactical priority based on OSINT stream patterns.”

The code generating that particular message does not call an AI model. The trigger is simply the keyword-based score described above.

That labeling is misleading.

A keyword filter can be useful for prioritizing incoming stories, but calling its output “AI Analysis” gives a comparatively simple rule more analytical authority than the implementation warrants.

This does not mean OSIRIS’s actual AI system is fake. There is a separate Gemini integration, which we discuss below.

It means users should not assume that every intelligence-sounding label corresponds to a sophisticated intelligence model.

Some conflict-map dots may be approximate rather than actual incident coordinates

The conflict layer deserves similar caution.

At the top of the current route, OSIRIS describes the system as combining GDELT geolocated conflict events with known conflict zones. But the live implementation we reviewed contains a significant fallback/aggregation path based on BBC, Al Jazeera and New York Times RSS feeds.

The code searches the headline and description for terms corresponding to predefined conflict zones.

When a story matches a zone, the system can place it near that zone’s manually defined center coordinates. It deliberately adds a small offset so multiple markers do not occupy exactly the same point.

For example, an article classified as relating to the Gaza conflict may be positioned around the preset Gaza anchor rather than the precise physical location where whatever event described in the article actually happened.

This is fine for displaying:

“Recent reporting is associated with this conflict zone.”

It is not sufficient evidence for:

“This attack occurred exactly where this OSIRIS marker appears.”

Citizen journalists working with maps should make that distinction explicit.

The map is a discovery interface.

The underlying article, official record, satellite imagery, geolocation evidence or primary data must establish the actual location.

One current bug illustrates a broader intelligence principle: unknown cannot mean safe

OSIRIS pulls geomagnetic information from NOAA’s Space Weather Prediction Center.

The current implementation sends separate requests for the Kp index, alerts and solar-flare information using Promise.allSettled. That is generally a reasonable way to keep one failed source from crashing an entire endpoint.

But there is a subtle consequence.

Before checking whether the Kp request succeeded, the code initializes the Kp value to zero and the storm classification to “Quiet.”

If the Kp request fails while another request succeeds, the route can therefore retain the zero value and “Quiet” classification instead of clearly representing the Kp condition as unknown.

That may sound minor.

For an intelligence system, it represents an important design rule:

Missing information is not evidence that nothing is happening.

A robust monitoring platform should distinguish:

• confirmed normal;
• confirmed abnormal;
• no reliable data available.

OSIRIS does this correctly in some error states, but not consistently across every partial failure we inspected.

OSIRIS had serious security problems earlier in 2026

Any fair review also has to address the project’s history.

In May 2026, security researcher James Sawyer conducted an extensive review of several rapidly built intelligence dashboards, including OSIRIS. Sawyer and GitHub users documented numerous problems in OSIRIS’s then-current code.

One of the clearest findings involved OSIRIS’s news system.

A May 14 GitHub issue documented an earlier implementation that used JavaScript’s Math.random() to produce purported escalation probabilities. Identical intelligence inputs could therefore generate different percentage assessments merely because the number was randomized.

That is unacceptable if presented as meaningful intelligence.

But there is an important update:

The current news route we reviewed no longer generates those random escalation percentages.

Its present risk system uses the deterministic keyword method described above instead.

The new approach remains methodologically crude, and its “AI Analysis” labeling is questionable, but it is materially different from generating random probabilities.

That correction deserves to be acknowledged.

The scanner had a genuine security problem—and the current version is substantially hardened

Another May finding involved OSIRIS’s network-scanning feature.

An early public endpoint allowed unauthenticated users to submit targets for active scanning, including scan types capable of generating substantial network traffic. A subsequent issue documented a server-side request forgery risk because arbitrary user-controlled targets were not adequately checked against internal and reserved addresses.

Those were not theoretical complaints about whether OSINT itself is dangerous.

They were concrete application-security issues.

The present implementation is significantly better.

Current code:

• rate-limits clients to five scans per minute;
• validates and resolves target hosts;
• rejects private and internal destinations;
• restricts available scan types;
• removes deep scans, arbitrary port-range scans, banner grabbing and traceroute from public access;
• requires the external scanner backend to be configured rather than falling back to the previously documented internal address.

That is meaningful remediation.

It is therefore inaccurate to take the May vulnerability report and present it as proof that the September 2026 version still exposes the same scanner.

It does not.

OSIRIS’s own current security policy also tells users to scan only systems they own or have explicit authorization to monitor.

We agree.

The project’s response to security criticism was not always reassuring

Although the technical state has improved, project governance is worth mentioning.

Sawyer documented an unusually confrontational response to parts of his audit, including an instance where an OSIRIS maintainer publicly posted an IP address while accusing a researcher of conducting a denial-of-service attack. He also documented large batches of issues being closed without clear corresponding fixes at that time.

We are not in a position to adjudicate every interpersonal allegation surrounding that dispute.

What we can independently establish is that the security issues filed against the project were not all frivolous: some described real weaknesses visible in the historical code, and today’s scanner contains explicit safeguards addressing several of those exact classes of problems.

That produces a more balanced conclusion than either extreme.

OSIRIS had a rough early security period.

The project’s response to criticism was sometimes poor.

And the current software has nevertheless improved in meaningful ways.

All three can be true at once.

Is OSIRIS private?

OSIRIS is not spyware based on anything we found. But we would not describe the hosted service as privacy-neutral either.

One important behavior occurs automatically.

Three seconds after the main dashboard loads, the current frontend calls OSIRIS’s /api/geo endpoint and uses the result to move the map toward the visitor’s approximate location.

The server obtains the apparent client IP from common proxy headers and attempts to geolocate it using external services.

The current fallback chain includes:

1. ipapi.co;
2. freeipapi.com;
3. ip-api.com.

For ordinary web users, IP geolocation is not extraordinary.

For journalists, investigators and activists, however, automatic location-related processing deserves explicit attention.

During our review we did not find a clearly surfaced dedicated privacy policy on the main site or documentation that explained these flows to the level we would prefer for an intelligence-oriented service. OSIRIS’s own documentation does at least identify /api/geo as an endpoint that geolocates the calling client by IP.

That is a yellow flag rather than a red one.

Self-hosting improves privacy, but it does not make every investigation local

OSIRIS deserves credit for being relatively easy to self-host.

Its documentation provides Node, Docker and Docker Compose instructions, and much of the platform does not require a database.

For a newsroom or serious OSINT user, we would prefer self-hosting over conducting sensitive work entirely through the public deployment.

But self-hosting should not be mistaken for complete isolation.

Many OSIRIS features still contact external services.

For example, its breach-checking endpoint takes the email address being investigated and submits it to the XposedOrNot API.

That means the query itself leaves your OSIRIS instance.

This matters because in investigative work what you search for can itself reveal what you are investigating.

The same reasoning applies to other third-party enrichment providers.

A newsroom with highly sensitive targets should audit each upstream service it intends to use rather than assuming “self-hosted” means “nothing leaves our server.”

What about OSIRIS’s actual AI analyst?

OSIRIS does contain a genuine generative-AI intelligence component.

The current source imports Google’s Generative AI library and uses Gemini 2.0 Flash to generate analyses and structured intelligence briefings.

OSIRIS serializes selected information from earthquake, news, threat and cyber feeds into a context that is then supplied to the model alongside the user’s question.

Its system prompt instructs Gemini to identify patterns, assess threats, examine geographic relationships, forecast developments over 24- and 72-hour periods and assign confidence levels. It also explicitly tells the model not to fabricate data and to distinguish correlation from causation.

Those are sensible instructions.

But Gemini remains a generative language model.

A polished intelligence briefing generated by an LLM is not independent verification that the claims inside it are correct.

For journalists, the best use is something like:

Which developments in these public feeds appear unusual enough that I should investigate them?

The bad use is:

OSIRIS AI says these events are connected, therefore they are connected.

Use the AI analyst to generate hypotheses, questions and leads.

Do not use it to close the evidentiary loop.

And do not submit confidential source information to an external AI workflow without first understanding where that information goes and whether your security model permits it.

Is OSIRIS really an “open-source Palantir”?

Not in the way many viral posts imply.

OSIRIS itself describes the project as a “Palantir Alternative,” and social posts about the software frequently characterize it as someone having “open-sourced Palantir.”

That is a useful shorthand for the visual idea: combine many information sources into one intelligence-oriented operating picture.

It is not a literal feature comparison.

Palantir Foundry includes extensive enterprise capabilities around ontologies, data integration, lineage, granular permissions, governance, object- and property-level access controls, workflow execution and organizational data management. Palantir’s own documentation describes security controls reaching object, property and even combined cell-level access.

OSIRIS is much closer to an open-source global OSINT dashboard and reconnaissance toolkit.

That is still valuable.

It simply is not the same product category as rebuilding Palantir Foundry or Gotham in an open-source browser application.

Who built OSIRIS?

The project is not completely anonymous.

OSIRIS’s public LinkedIn page lists Souleimen Mrad, and other public posts identify Mrad as the project’s original creator. The repository itself is maintained under the simplifaisoul account.

That is preferable to a supposedly critical intelligence service with no identifiable person or development history behind it.

At the same time, users should understand that OSIRIS is a relatively young open-source project—not an established intelligence institution with a large compliance, data-quality and security organization behind every feed.

Its rapid development is part of what makes it impressive.

It is also why verification remains necessary.

What about the $OSIRIS cryptocurrency?

There is another subject we think users should keep separate from this review.

The current GitHub repository description includes a Solana contract address ending in pump, and the live interface and associated OSIRIS ecosystem visibly promote $OSIRIS.

We have not conducted the separate financial, tokenomics or blockchain investigation necessary to tell readers whether that asset represents a reasonable investment.

So we will not pretend otherwise.

Our recommendation is strictly:

OSIRIS the open-source intelligence software has legitimate utility.

It is not:

Buy the OSIRIS cryptocurrency.

A useful open-source program does not automatically make a related token valuable, safe or financially sound.

Treat those as completely separate questions.

Is OSIRIS safe for citizen journalists?

For ordinary open-source research, yes—with the same rule that should govern any OSINT platform: verify the underlying source.

We would be comfortable telling sherafy.com citizen journalists to use OSIRIS for:

• identifying unusual aircraft activity;
• watching public camera networks;
• spotting earthquakes, fires or weather events worth investigating;
• monitoring public conflict reporting;
• exploring sanctions and public-record leads;
• following cyber-threat indicators;
• connecting geographically related public information;
• generating ideas for further research.

We would not tell them to treat an OSIRIS result as self-authenticating evidence.

If OSIRIS shows an earthquake, go to USGS.

If it shows a fire detection, examine the NASA source.

If it surfaces a Telegram post, preserve and verify the original post.

If it shows an aircraft, verify the underlying aviation data and understand its limitations.

If an AI briefing says two developments may be connected, investigate the connection.

If a country-risk score says 85, do not publish “85” as though an intelligence service scientifically measured it.

If a conflict dot appears at a location, determine whether the coordinates are primary geolocation or merely a visual placement.

That is responsible OSINT.

Our recommended OSIRIS protocol for journalists

For anyone using OSIRIS in reporting, we recommend six simple rules.

1. Use OSIRIS to find evidence, not replace evidence

The dashboard is the beginning of the investigation.

Your citation should normally be the underlying primary source rather than OSIRIS itself.

2. Distinguish raw feeds from OSIRIS interpretation

An earthquake magnitude supplied by USGS is fundamentally different from an OSIRIS-created geopolitical risk score.

Do not give both the same evidentiary weight.

3. Verify every precise map location that matters

Some layers contain actual coordinates.

Other visualizations can use generalized or generated placement.

Click through and establish provenance before drawing geographic conclusions.

4. Treat AI output as analysis, not fact

OSIRIS’s Gemini integration can help identify patterns and questions.

It cannot independently prove causation, intent or authenticity.

5. Do not put confidential source information into the hosted platform casually

For sensitive investigations, consider a self-hosted instance and audit the specific third-party APIs involved.

Remember that some searches still leave your machine even when OSIRIS itself runs locally.

6. Never scan infrastructure without authorization

Active reconnaissance is different from reading public data.

OSIRIS’s own security policy requires authorized targets, and that is the correct standard legally and ethically.

So, is OSIRIS worth using?

Yes.

The important result of our investigation is that OSIRIS survived scrutiny well enough to remain useful.

It would have been easy to dismiss the whole project after finding its May security history, the old randomized escalation probabilities or today’s heuristic risk scores.

That would be an overcorrection.

The software solves a real problem.

It combines a remarkable amount of public information into an interface that ordinary researchers can explore without buying an enterprise intelligence product. The code is public. The project can be self-hosted. The community is substantial. Several serious early problems have been materially addressed.

The mistake would be believing everything that looks like intelligence inside OSIRIS represents the same quality of intelligence.

It does not.

Some information comes directly from authoritative external sources.

Some information is aggregated journalism.

Some is manually classified.

Some is a keyword heuristic.

Some is approximate geography.

Some is generated by Gemini.

Those categories need to remain separate in the user’s mind.

Final verdict: 🟢 Qualified Green Light — 7.5/10

OSIRIS is a legitimate and valuable OSINT discovery platform. We recommend it for journalists and researchers who understand that aggregation is not verification.

Its strongest feature is not that it magically knows what is happening around the world.

Its strongest feature is that it helps you see where to look next.

That is already extremely useful.

But when the stakes rise—when a location, accusation, threat assessment or human source matters—leave the dashboard and follow the evidence back to where it came from.

That is the difference between using intelligence tools and merely being impressed by them.

References and Further Reading

Primary OSIRIS sources

• OSIRIS official live platform — The hosted OSINT dashboard reviewed for this article.
• OSIRIS GitHub repository — Primary source for the project’s code, documentation, license, development history and stated capabilities.
• OSIRIS Documentation and API Reference — Official explanation of data feeds, endpoints, AI features, self-hosting and reconnaissance tools.
• OSIRIS Security Policy — Current responsible-use rules, including authorization requirements for active scanning.
• Current country-risk implementation — Shows the manually assigned base risk scores discussed in this article.
• Current OSIRIS news implementation — Shows the keyword-based risk calculation and current “AI Analysis” label.
• Current conflict-map implementation — Shows known conflict-zone anchors, RSS matching and offset coordinates.
• Current OSIRIS geolocation endpoint — Shows the external services used for IP-based location.
• Current OSIRIS dashboard source — Shows the automatic /api/geo call and locally stored drawn areas.
• Current OSIRIS AI engine — Shows the Gemini 2.0 Flash integration and intelligence-analysis system prompt.
• Current OSIRIS scanner proxy — Shows current target validation, rate limiting and restricted scan types.
• Current OSIRIS space-weather endpoint — Relevant to the partial-data failure behavior discussed above.
• Current OSIRIS breach-search endpoint — Shows email queries being forwarded to XposedOrNot.

Security history and independent scrutiny

• GitHub Issue #23: Randomized escalation probabilities — Documents the May 2026 implementation that generated escalation percentages using Math.random().
• GitHub Issue #45: Scanner SSRF exposure — Documents the earlier lack of adequate target validation and internal-network protections.
• GitHub Issue #3: Unauthenticated deep scanning and traceroute — Historical evidence concerning the earlier public scanner design.
• James Sawyer: The AI Slop Intelligence Dashboard Problem — Independent May 2026 audit covering OSIRIS and several related intelligence dashboards.
• James Sawyer: AI Slop Intelligence Dashboards, Part 2 — Follow-up examining developer responses and issue handling. Sawyer’s analysis is an independent critical source rather than a neutral authority, so we checked material OSIRIS claims against the project’s present code where possible.

Comparison and project identity

• Palantir Foundry: Object Permissioning Overview — Official Palantir documentation illustrating enterprise security and ontology capabilities absent from a simple “open-source Palantir” comparison.
• Palantir: Object and Property Security Policies — Official description of object-, property- and combined cell-level security capabilities.
• OSIRIS on LinkedIn — Public project profile identifying the organization and its association with creator Souleimen Mrad.

Editorial currency note: OSIRIS is under active development. This review reflects the public site and source code examined on September 8, 2026. Features, data providers, security controls and implementation details may change. Historical vulnerabilities described here should not automatically be assumed to remain present in future versions; conversely, users performing sensitive work should review the current source and privacy behavior rather than relying solely on this article.