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.

[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.