The platform
One asks “is this safe?”
The other decides “is this allowed?”
TrustAuthority is the record — it answers what an artifact is, with the evidence attached. TAP is the control layer — it sits in front of your agents and enforces what they may actually do. You can use either on its own.
The trust record
Ask before you install — packages, MCP servers, agent tools.
TrustAuthority continuously crawls package and MCP registries and keeps a verdict for each artifact, with the evidence that produced it. Ask it over HTTP, from the CLI, or from an agent over MCP — the answer comes back with its reasons, not just a score.
- 📦 npm · PyPI · VS Code · JetBrains · GitHub Actions · MCP registries
- 🕵️ Impersonation verified by publisher, not by name similarity
- 🔄 Rug-pull detection when an approved tool changes silently
- 👤 Maintainer takeovers, dormant-package revivals, digest drift
- ⚡ On-demand: ask about something we’ve never seen and get an answer now
The control layer
Your agents run real commands. TAP decides which ones execute.
TAP is an MCP-aware proxy between your agents and their tools. Every tool call is evaluated before it runs — against your rules, the tool’s declared capabilities, and TrustAuthority’s verdict. High-risk actions can pause for a human instead of simply failing.
- 🛑 Allow, deny, or hold for approval — per agent, per tool, per call
- 🔐 Least privilege: block a tool asking for more than its job needs
- 🌐 Egress control — a tool may only reach hosts you allow
- 🧊 Freeze a server whose manifest changed after you approved it
- 📝 Full audit log of every action, with Slack approve/deny
How a verdict is made
A verdict about someone else’s software is a serious claim. These are the rules we hold ourselves to.
Evidence, not vibes
Every finding carries the underlying data — the actual install script, the maintainer comparison, the manifest diff. If a claim can’t be checked by someone else, it doesn’t ship.
A name is never proof
A package that merely resembles a popular one is a lookalike, not an impersonator. We call it impersonation only when the publisher evidence says so — a maintainer set disjoint from the official package’s, or an org claim no maintainer’s domain backs.
We never accuse without a basis
“Malicious” requires a verified or critical finding. A low score assembled from weak signals is a caution flag, never a public accusation.
We never manufacture trust either
The reverse also holds: an artifact carrying a verified critical finding can never be published as “trusted”, however high its score. Absence of evidence is not a clean bill of health.
We name artifacts, not people
Public verdicts describe the publisher structurally — “one maintainer account, no overlap with the official package’s seven” — never a name or an address. The identities stay internal, used to reach the verdict and to defend it on appeal.
Verdicts are dated, and correctable
A verdict reflects what we could see when we looked. Think one is wrong? Dispute it — it goes to a reviewed queue with an audit trail, and we correct in good faith.
What we don’t claim
A security tool that promises certainty is lying. Ours doesn’t.
- Not a guarantee. We can miss things, and we can flag something that turns out fine. Verdicts are an assessment to help you decide — not a substitute for your own judgement.
- Declared capability isn’t proven capability. A tool’s manifest is self-reported, and a malicious server can lie. We mark declared capabilities as declared, and never present them as observed behaviour.
- Unknown is not safe. If we haven’t assessed something, we say so rather than defaulting it to a pass.
Try it before you trust it
Check a package or an MCP server right now — no account needed.