How do you handle an unreliable or bad-actor agent today?

[ucsandman]

Hey, quick question, I'm not selling anything. I'm building a reputation oracle for AI agents (Sybil-resistant scoring, signed receipts, open source: https://github.com/ucsandman/Agent-Reputation-Oracle) and trying to figure out if it solves a real problem before I build more of it.

When an agent listed in the registry turns out to be unreliable or a bad actor, how do you handle that today? A blocklist, a manual review queue, something else?

Genuinely just trying to learn what already exists. Happy to be told this is a non-problem.

[Michael-WhiteCapData]

The official MCP Registry does not currently provide reputation scoring or a blocklist for agents. It is also important to distinguish that the Registry catalogs MCP servers, not AI agents.

For published servers, the current trust layer starts with namespace authentication, which verifies that a publisher controls the claimed GitHub account or domain. The Registry then applies a deliberately permissive moderation policy. Maintainers can manually mark malware, spam, illegal content, or completely broken servers as deleted, but they explicitly do not promise broad security review or removal of every buggy or vulnerable server.

Security scanning and reputation are intentionally left to package registries and downstream aggregators. The Registry documentation specifically describes aggregators adding ratings, security scans, and other custom metadata. That means a reputation oracle would not duplicate an existing Registry feature. It would fit more naturally as a downstream aggregator or subregistry that consumes Registry metadata and adds evidence based reputation signals.

If you take that route, I would key each result to the verified publisher namespace, server name, exact version, and package digest where available. That avoids carrying a good or bad score across unrelated releases and keeps signed receipts tied to the artifact that actually produced them.

The relevant documentation is in About the MCP Registry, the moderation policy, and the aggregator guide.

[alipishbin77]

Not a blocklist on our end — the design tries to make "unreliable" mostly not matter. We run a small agent-to-agent marketplace (io.github.alipishbin77/aether, paid per call in USDC): a buyer's payment is escrowed before the call, and only released to the seller if the seller's endpoint actually returns a successful result. Timeout, error, or garbage output — full automatic refund, no manual review needed. Success rate and rating are public on each listing, so a bad-acting or flaky seller just naturally stops getting picked, without anyone needing to police it.

That said, this only solves "did I get charged for nothing" — it doesn't solve actually-malicious output (a seller that returns plausible-looking garbage and still "succeeds"). Haven't needed to solve that yet since there's no real seller volume. Curious whether your reputation-oracle approach is aimed more at that second problem.

[yaohuangguan]

The distinction above is important: the official Registry indexes MCP servers, not autonomous agent identities. From the operator side, I'd treat reputation as a discovery/admission signal, not as the security boundary for the next action.

For an unreliable or potentially malicious agent/tool provider, I'd separate three responses:

1. Containment now: revoke its authorization, disable the specific tool/device, and require explicit approval for any pending mutation. This should work without waiting for a registry-level blocklist or a new reputation score.
2. Evidence: record the actor/client, server and version (if known), requested tool, target, operation ID, actual execution outcome, and timestamp. Crucially, “returned success”, “the state now matches the request”, and “this invocation actually caused the change” are three different claims.
3. Re-admission later: evaluate signed receipts, failure history, publisher identity, and the exact server version/artifact rather than attaching a permanent good/bad label to a display name. A fresh version needs fresh evidence.

For a reputation oracle, I would test how it distinguishes (a) a transient timeout, (b) an incorrectly claimed success, (c) a policy-denied attempt, and (d) a genuinely harmful side effect. Otherwise a score risks penalizing safe policy refusals while rewarding tools that confidently claim success.

Disclosure: I'm working on Remote Arc, a remote-computer MCP bridge. We use a different, complementary layer: new devices are read-only by default, OAuth scopes do not override per-device tool restrictions, and devices can revoke write/terminal execution independently. We do not implement a reputation oracle; the experience is why I would keep risk scoring and execution-time containment separate.

For your design, is a signed receipt intended to certify the tool result claimed by the server, or independent observation that a side effect occurred? That choice seems pivotal to how trustworthy the score can be.