Securing AI Access to Financial Data: How We Govern Bitcoin MCP with agentgateway

What happens when an AI agent has a tool called send_raw_transaction?

That's not a hypothetical. bitcoin-mcp is a Model Context Protocol server that gives AI agents access to 49 tools for querying the Bitcoin network -- block analysis, fee estimation, mempool inspection, address lookups, transaction decoding, and yes, broadcasting signed transactions to the network.

For a data analyst building a dashboard, these tools are a goldmine. For a production deployment without guardrails, they're an open door.

We built Bitcoin Gateway Guard to close that door and hand out keys only to the people who should have them.

The Threat Model

AI agents are not users. They don't have judgment. They do exactly what their prompt says, and prompts can be injected, manipulated, or just poorly written. Consider what goes wrong when an AI agent has unrestricted access to Bitcoin tools:

Accidental broadcast. A developer testing transaction construction accidentally calls send_raw_transaction instead of decode_raw_transaction. The transaction is irreversible.

Prompt injection. A malicious input tricks the agent into calling generate_keypair, and the private key appears in a response that gets logged, cached, or displayed in a UI.

Runaway loops. A bug in the agent's reasoning causes it to hammer the Bitcoin node with thousands of requests per minute, degrading service for everyone.

Shadow access. Six months later, nobody can tell you which agents accessed what data, when, or why. Your compliance team is not happy.

These are not exotic attacks. They are the predictable consequences of deploying AI agents on financial infrastructure without the same controls you'd apply to human users.

Four Layers of Defense

Bitcoin Gateway Guard places agentgateway -- an open-source MCP security gateway built in Rust -- between AI agents and bitcoin-mcp. Every request passes through four independent security layers.

Layer 1: JWT Authentication

No anonymous access. Every request must carry a valid JWT signed with RS256. The gateway validates the signature, issuer (bitcoin-gateway-guard), audience (bitcoin-mcp), and expiration before the request touches any downstream logic.

No token? HTTP 401. Expired token? HTTP 401. Wrong issuer? HTTP 401.

Layer 2: Role-Based Access Control

We define two roles using CEL (Common Expression Language) expressions:

jwt.role == "admin"
jwt.role == "reader" && mcp.tool.name != "send_raw_transaction" && mcp.tool.name != "generate_keypair"

The reader role gets access to 47 read-only tools -- everything you need for dashboards, analytics, research, and monitoring. The two tools that can modify state or create sensitive material -- send_raw_transaction and generate_keypair -- are reserved for admin.

This is a single line of policy. No code. No middleware. No if-else chains buried in application logic. The policy is auditable, declarative, and lives in a YAML config file that can be version-controlled and reviewed.

Layer 3: Rate Limiting

A token bucket algorithm caps every consumer at 10 requests per minute with burst capacity of 10. This is deliberately conservative. A legitimate dashboard refresh needs one request every few seconds. An agent stuck in a loop will hit the limit in under a second.

localRateLimit:
  - maxTokens: 10
    tokensPerFill: 1
    fillInterval: 60s

Rate limiting is the safety net that catches everything else. Even if authentication and authorization both pass, a runaway agent cannot overload your Bitcoin node.

Layer 4: Audit Trail

Every tool invocation generates an OpenTelemetry span exported to Jaeger. Each span records the tool name, the JWT subject (who), the JWT role, the authorization decision (allowed or denied), the HTTP status, and the latency.

Open Jaeger at localhost:16686, select the agentgateway service, and you have a complete, searchable, time-ordered record of every AI agent interaction with your Bitcoin data. Feed it into your SIEM, set up PagerDuty alerts on denied requests, run weekly access reviews.

The Demo

Setup takes two commands:

python scripts/generate_keys.py   # Generate RSA keys + JWT tokens
docker compose up -d               # Start bitcoin-mcp + agentgateway + Jaeger

Then test the security model:

# Reader queries block height -- works fine
python scripts/test_rbac.py --user reader --tool get_block_count
# Result: ALLOWED

# Reader tries to broadcast a transaction -- blocked
python scripts/test_rbac.py --user reader --tool send_raw_transaction
# Result: DENIED (authorization)

# Burst 15 requests -- rate limited after 10
python scripts/test_rbac.py --user reader --tool get_fee_estimates --burst 15
# Summary: 10 allowed, 5 rate-limited

Every one of these interactions shows up in Jaeger with full context. The denied requests are flagged. The rate-limited requests are logged. Nothing is invisible.

Why agentgateway?

We evaluated building custom middleware, wrapping bitcoin-mcp with authentication logic, and using a general-purpose API gateway. agentgateway won because it understands MCP natively.

A generic API gateway can rate-limit HTTP requests and validate JWTs. But it cannot inspect MCP tool names, apply per-tool authorization rules, or trace MCP-specific context. agentgateway speaks the protocol. Its CEL-based authorization rules reference mcp.tool.name directly. No regex on request bodies. No custom plugins. No fragile parsing.

The configuration is 40 lines of YAML. The entire security policy -- authentication, authorization, rate limiting, and tracing -- is declared in a single file that a security engineer can review in five minutes.

Why This Matters

The AI industry is moving fast toward giving agents access to real-world systems. Financial data. Infrastructure controls. Business operations. The tools are getting more powerful. The guardrails are not keeping up.

MCP is becoming the standard protocol for AI agent tool access. But MCP itself has no built-in security model. There's no authentication, no authorization, no rate limiting, and no audit trail in the protocol specification. That's by design -- MCP is a transport protocol, not a security framework.

The security has to come from the deployment layer. And it has to be as easy to configure as the tools themselves, or teams will skip it.

Bitcoin Gateway Guard demonstrates that you can add enterprise-grade security to any MCP server -- not just bitcoin-mcp -- with a single configuration file and zero code changes to the underlying server. The same pattern applies to database MCP servers, cloud infrastructure tools, payment APIs, or anything else you'd hesitate to give an AI agent unrestricted access to.

The question is not whether AI agents should have access to financial tools. They should -- the productivity gains are real. The question is whether that access is governed with the same rigor we apply to human users.

With agentgateway, the answer is yes. And you can prove it to your auditors.

---

Bitcoin Gateway Guard is open source. The full configuration, Docker setup, and test scripts are available at github.com/Bortlesboat/bitcoin-gateway-guard. Built with bitcoin-mcp and agentgateway for the MCP & AI Agents Hackathon -- Secure & Govern MCP category.