How Obolo protects connected agents
Obolo sits between your agent and third-party MCP servers. That spot in the middle is where the controls apply: private-network blocking, schema-change detection, spend caps, and verification tiers. Below, what each one does and does not do.
Overview
The principle is simple: an agent should not have to blindly trust an MCP server it found in a directory. Obolo turns "trust and hope" into concrete controls that run on every call, before the upstream response reaches the agent.
SSRF protection
On outbound calls to upstreams, the gateway blocks private-network destinations. A compromised or malicious MCP server cannot use Obolo to reach cloud metadata, internal services, or loopback addresses. The destination is resolved and validated to defeat DNS rebinding, not just the first lookup.
Schema drift / rug-pull detection
Every manifest is reduced to a stable canonical hash. If a server changes its tools without disclosure — a schema rug-pull — the hash changes and Obolo detects it before that altered schema reaches a connected agent. Tier-2 verification is anchored to that hash.
Spend caps + 429 cutoff
Every key has a hard spend cap against a prepaid balance. When spend hits the limit, the gateway cuts off with a 429 instead of continuing to charge. This is the defense against a looping agent or a server trying to inflate usage: maximum damage is bounded up front.
Verification tiers as a signal
The tier is the trust label an agent sees before it spends. "crawled" (tier 1) is metadata only, indexed from a public directory. "verified" (tier 2) means the publisher proved ownership via DNS and registry and the schema passed static analysis with a canonical hash. An operator can require tier 2 only.
Merchant of record + audit logs
Obolo is the merchant of record: it charges the buyer and settles with the publisher. Every tool call lands in an audit log — which server, which tool, what it cost — so spend is reconstructable and disputable, not a black box.
Frequently asked questions
Verification is static: ownership proof (DNS + registry), analysis of the declared schema, and a canonical hash. It does not run the server to verify it. When a third-party stdio server is executed to discover its tools, it runs in an isolated sandbox with egress restricted by allowlist; that is not the path production credentials or calls take.
The gateway blocks private-network destinations on outbound calls (SSRF protection) and validates the resolved destination to defeat DNS rebinding. A server cannot use Obolo as a pivot toward cloud metadata, internal services, or loopback.
The manifest has a canonical hash. An undisclosed change alters the hash, Obolo detects the drift, and the altered schema is not served to connected agents as if it were the verified one.
Reporting a vulnerability
If you find a security issue, contact us before disclosing it publicly. We respond to good-faith reports at: hola@obolo.dev