biosecurity-agent builds local dossiers on named targets, and says it is not for pathogen work

The target list has no default, and the privacy section sets the limits

Start with the scope, because it is the part that decides whether this belongs in your workflow.

The README asks you to describe, in ordinary language, people, animals, plants, products, places, organisations, or several connected targets. Files, private context, public URLs, and custom sources can add detail. There is no default target list, no starter world, and no stated limit on how many targets or watchers a single world holds.

What it does with a target is the part worth reading carefully. It tracks official and scientific sources, news and the open web, public open-source intelligence, sensors and surveillance, and connected data. It then builds a target-centred world, links evidence across places and time, and keeps that world updated in the background. A world persists locally across restarts, along with processing events, watchers, and target relationships.

That is a persistent, queryable record about a named person or animal that refreshes itself. Nobody should adopt it without deciding, in writing, who is allowed to see that record.

The project draws its own boundary in the privacy and safety section. It runs locally, and targets, files, and secrets are not uploaded to the vendor by default. External content is treated as untrusted, actions require explicit permissions, and it states plainly that it is designed for defensive biosecurity, not pathogen engineering or clinical diagnosis. That last clause is the one to hold the project to.

Observed, inferred, and simulated claims are kept apart

One design decision in this project is worth more than the feature list, and it is stated as a single sentence.

Observed, inferred, and simulated claims always remain distinct. That is the whole guarantee, and for a tool that assembles a picture of a target from many weak sources and then projects that picture forward in time, it is the guarantee that matters.

The forward projection is the risky part. The agent is described as simulating from the current live state and recommending defensive actions backed by inspectable evidence, and the terminal excerpt in the README shows a simulation block with a forward horizon expressed in days, a small number of future paths, a protection recommendation, and links back to the evidence the paths were built from.

Two things in that excerpt deserve reading. The protection count is lower than the path count, which is the honest shape of the output: several plausible futures, fewer actionable responses. And the evidence links are counted, which means a path is supposed to be traceable to what produced it rather than asserted.

The excerpt is drawn from a persisted run, and a full terminal replay is shipped as a log file inside the published package. That is a reasonable thing to publish and an unusual one, because it means you can inspect exactly what the interface showed rather than trusting a description of it.

The counts in the excerpt also invite arithmetic. Five official sources, four news sources, three social sources, four sensor sources, and two custom sources make eighteen, and the world synthesis line reports eighteen entities. That may be coincidence, or it may mean the synthesis is close to one entity per source, which would be a much weaker world model than the interface implies.

Offline is set to true and a search engine ships alongside it

The container configuration contradicts itself in a way that matters, and the contradiction is the kind that only shows up when you read all three files.

The compose file sets three environment variables for the agent: a data directory, a flag that says it is running under Docker, and a flag named for offline mode, set to true.

environment:
  BIOSECURITY_DATA_DIR: /data
  BIOSECURITY_DOCKER_BIND: "true"
  BIOSECURITY_OFFLINE: "true"

The Dockerfile sets the same three as image-level environment variables.

The same compose file also defines a second service. It is a self-hosted metasearch instance, on a pinned dated image tag, with its own settings file mounted read-only, and it is placed behind a profile rather than started by default. The ports for both services are bound to the loopback address only, so nothing is exposed off the host by default, and the agent service carries a health check that resolves its own container address by name rather than using localhost.

And the environment example, which is what you copy to start locally, lists nine model provider keys, two keys belonging to the project itself, a data directory, a network flag set to false, and a URL pointing at a local search service on port 8080.

So offline here means do not call the vendor, not do not use the network. A deployment that sets the network flag to false and still ships a search endpoint is telling you the agent expects to do lookups, just not through anyone else's account. Anyone reading the flag alone will get that wrong.

The read-only mount on the search settings and the loopback-only port bindings are the two details here that are genuinely careful.

Three version statements and a committed tarball

The version picture in this repository does not line up, and it is visible without running anything.

The README's own heading calls the project version 0.1. The package manifest says 0.1.2. And at the repository root there is a committed package archive named for release 0.1.0.

So the tree contains a built tarball from two patch versions before the current manifest, checked into version control next to the source. That file will be what someone finds first if they are browsing the repository rather than installing from the registry, and it is not the build the manifest describes.

There is a checksum manifest at the root as well, which is the right instinct for an artifact that gets shipped, and a demo directory with a fixtures subdirectory that the root manifest exposes through a demo script.

The published package is worth reading separately. Its file list is three built application directories, one command entry point pointing at the built CLI, two asset files including the terminal replay log and an image, and the licence and readme. No source, no tests, no configuration schema, and no examples. Public access is declared for publishing, so this is a real npm package rather than a private workspace root.

For a project at 0.1.x whose README describes a terminal-first product with a persistent local database, none of that is a criticism. It is just worth knowing that the artefact in the tree and the artefact on the registry are not the same build.

The Docker image runs the server, the quick start runs the CLI

There are two programs in this repository and the documentation only ever mentions one of them.

The documented entry point is a single npx invocation, which resolves to a command that points at the built CLI application. That is the path in the quick start, and it needs Node 20 or newer.

The container image runs something else. It copies the built server and the built viewer into the runtime stage and copies neither the CLI build nor the assets directory, then starts the server as its command. The build stage does copy the demo directory, which is also not in the published file list.

That means a Docker deployment does not give you the documented entry point. You get the server process, the viewer, and a flag that tells the code it is running under Docker so it can bind appropriately. The CLI, its doctor subcommand, and the demo mode are all reachable only from a source checkout or from the registry package.

Two details in the image are worth crediting. It creates a dedicated unprivileged system user and group, makes the data directory that user's home, and switches to it before the entry point runs. And the build stage prunes to production dependencies after building, so the runtime layer does not carry the development tree.

The odd one is the toolchain. The build stage installs Python 3, make, and a C++ compiler before installing dependencies, which is the standard requirement for a native Node addon to compile rather than download a prebuilt binary.

A native database addon, and a supply-chain gate that only fails on high severity

The build configuration names the pieces that will bite you on unusual hosts.

Both application bundles are built with the same bundler, and in both cases the native database module is marked external. That single word means the published package expects a compiled native addon to be present at runtime rather than bundling it, which in turn means a prebuilt binary has to be available for your platform or a compiler has to be available to build one. It also explains the Python 3, make, and C++ compiler in the build stage, and it means the published package is not purely portable JavaScript.

The build order is viewer, then server, then CLI, and each bundle cleans its output directory first. The server build targets Node 20 as the minimum, matching the declared engine range and the base image.

On the quality side there is more than most projects at this stage. Linting runs across the whole repository, type checking is a separate script, unit tests run under one runner, end-to-end tests run under a browser driver, and there is a formatting check as well as a formatting write. Schemas are generated from a script rather than hand-maintained, and there is a dedicated doctor subcommand on the CLI.

The supply-chain check is the one to look at closely. It audits production dependencies only, and only fails at high severity or above. That is a common and defensible choice, and it is also a choice: everything below high is reported and ignored.

Agent compatibility is claimed broadly. All agents and model providers are supported through an OpenAI-compatible adapter, with native adapters named for Codex and Claude.

Editorial conclusion

This tool builds a persistent, locally stored dossier on named people, animals, plants, products, places, and organisations, keeps watchers running on them in the background, and is stated to be for defensive biosecurity rather than pathogen engineering or clinical diagnosis. That framing is set by the project itself and belongs at the front of any evaluation. If your use is defensive threat monitoring for something you are responsible for, the honest reasons to try it are the local-first storage and the single guarantee it makes about evidence, namely that observed, inferred, and simulated claims stay separate in the interface. Three things to settle first. The scope is whatever you name, so there is no default target set and no stated ceiling on how many targets or watchers one world holds. The word offline means no vendor calls rather than no network, because the compose file sets an offline flag and ships a self-hosted search service you can switch on. And a version discrepancy means you may not be reading about the build you install: the README says v0.1, the manifest says 0.1.2, and a 0.1.0 tarball is committed at the repository root.

Frequently asked questions

Official sources

1. Forsy-AI/biosecurity-agent on GitHub
2. Issues
3. License: Apache-2.0
4. README