Self-hosted or cloud-based · Report-only
Know what AI tooling your developers actually have installed.
The codegate agent runs on each developer machine and inventories every skill, MCP server, rules file and config it finds. It scans them and reports what it saw. Visible Agents aggregates those reports and shows you which of it is dangerous.
- Postgres, and nothing else
- No telemetry, no external API
- MIT licensed
How it works
This server never sends anything to a machine.
It receives, evaluates and displays. Remediation happens on the machine, by the person who owns it — and the next report is the evidence it happened. There is no channel in the other direction to misuse, and no credential on this server that would let anyone open one.
On the machine
It reads, and it analyses
The agent walks the AI tooling it knows about — a versioned knowledge base of where each tool keeps its skills, rules, MCP servers and settings, in the project and in the home directory. Then it reads what it found and analyses the content.
Environment overrides, command execution, consent bypasses, instructions injected into rules files, symlink escapes, git hooks, and artifacts matched by hash against known-bad content. That pass is offline and deterministic by default — same input, same answer — and it needs no account and no model.
A deeper pass goes further: MCP tool descriptions, toxic chains where untrusted input can reach an exfiltration sink, registry metadata for the packages a server pulls. Most of that is deterministic too. The part that reads instruction files with a language model is opt-in, and today it runs on the machine, using whatever model access the developer already has.
Every one of those steps is a read. Nothing on the machine is changed by scanning it — remediation is a separate command, it backs up what it touches, and it can be undone.
On the wire
Conclusions, not contents
A check-in carries an inventory: for each artifact, which tool it belongs to, its kind and scope, where it lives, the risk surface it represents, and a sha256 of its bytes.
Alongside it go the findings the scan produced — rule, severity, category, which layer raised it, the file, and the specific lines that matched.
By default the files themselves stay on the machine: Visible Agents identifies an artifact by its hash, which is how it can tell two files apart without holding either one. An operator can switch on collection for skills and rules files — prose the agent found something in — and nothing else: configuration, and anything that can hold a credential, never leaves the machine whatever the policy says.
On the server
It evaluates. You decide
Visible Agents aggregates check-ins, derives each finding's status from report history, and evaluates your policies against what every machine reported.
What that produces is a judgement, not an action. The engine can tell you a skill looks malicious; it cannot tell you whether you allow it. That call belongs to a person — acknowledge a finding to take responsibility for it, or suppress it with a written reason that stays on the record.
Neither reaches the machine. And an acknowledgement does not close anything: a finding resolves only when a later report from that machine no longer carries it.
Identity
Identity is the content, not the name.
Every artifact is keyed by the hash of its bytes. Two files sharing a name but differing by one byte are two different artifacts here, so a malicious skill cannot hide behind a familiar filename.
Matches the copy published in the content bundle, byte for byte.
Two lines longer than the original. The addition posts the working diff to an external endpoint.
Same filename. Two artifacts, listed separately, tracked separately. Visible Agents will never show you one while you are looking at the other.
What it shows
Six surfaces, and the API behind every one of them.
Machines
Every machine reporting in, who is accountable for it, what it carries, and when it last checked in.
Inventory
Artifacts keyed by content hash, not by name. The same skill across forty machines is one row, and a tampered copy is a different one.
Findings
A lifecycle nobody has to maintain: open while a machine still reports it, resolved when a later report no longer does. Status is derived, never stored.
Policies
Rules evaluated here against what each machine reported. Visible Agents flags a violation; it cannot block anything on a laptop.
Activity
Who or what did something, and the API call behind it — including every check-in this server refused, and why.
API & access
The console is a client of its own API. Anything you can do here, a script can do with a session.
Getting started
From nothing to a reporting fleet.
- 1
Deploy it
Postgres and the console. Nothing else to run, and nothing to sign up for.
- 2
Claim the instance
The first operator registers with the setup token you generated, so a networked instance cannot be claimed by whoever reaches the port first.
- 3
Enrol a machine
Mint a code, run two commands. The machine is issued its own reporting token — check-ins are identified by that token, not by the id in the request.
- 4
Read the fleet
Every check-in writes a report. Findings open when a machine reports them and resolve when it stops, so the next report is the evidence a fix landed.
# on the server
docker compose up --build
# on each developer machine
npx codegate-ai enrol --server https://guardian.example.internal --code FLEET-XXXX-XXXX
npx codegate-ai reportDeliberate limits
What it deliberately doesn’t do.
Worth knowing before you deploy it, rather than after.
It cannot block anything
Visible Agents flags; the laptop keeps running. Enforcement belongs to the agent on the machine and the person who owns it — this server only ever describes what it was told.
One instance, one operator
No roles, no user management, no second account. A deliberate limit rather than an oversight: a console that can add operators needs invitations, roles and an audit trail of who granted what, and none of that is built.
It talks to Postgres, and nothing else
No hosted database, no analytics, no error reporting, no external API. Fonts are vendored rather than fetched, so even the build reaches nothing but this repository.
Open source
Every line of it, on GitHub.
MIT licensed, both halves. A tool that reads what is on your developers’ machines is a tool you should be able to read back — so the agent that does the reading and the console that stores it are the same code you can audit, fork and run yourself. Nothing here asks to be taken on trust.
Hosted
Or let us run it for you.
Self-hosting Visible Agents means a container, a Postgres, a certificate and somebody to keep all three patched. We are building a hosted version that is the same code without the operations — and that runs the model-backed deep pass centrally, once per artifact rather than once per machine, so fleet coverage stops depending on what each developer happens to have installed.
The constraint does not change. It still never sends anything to a machine.
Your address goes to LaunchList, who run the waitlist, and is used for nothing but telling you when hosted Visible Agents is ready. Nothing else on this page contacts anyone.
Ready to run one?
This page does not host a console. The repository has everything to deploy your own: a compose file, published images for amd64 and arm64, and a setup token that makes the first account yours.