Security Architecture Blueprint: Replacing Shared Master Keys with LIME Machine Passports

[Mawyxx]

Pre-submission Checklist

• This post follows the MCP community guidelines

What would you like to share?

Security Architecture Blueprint: Replacing Shared Master Keys with LIME Machine Passports

Operating autonomous AI agents via hardcoded master keys or raw connection strings (POSTGRES_URL) creates a massive blast radius. If an agent falls victim to a prompt-injection attack, any secret living in its client memory is immediately compromised — often granting the attacker full infrastructure access.

The fix is not “better secret rotation.” It is named machine identity: treat each AI agent as an independent digital passport holder, and move authentication off human-oriented OAuth/redirect theater onto machine-only cryptographic gates.

LIME is a passport system for AI agents. The agent authenticates to LIME with a long-lived opaque Agent Token; LIME issues short-lived Core-signed passport JWTs. Your resource server verifies them locally via JWKS — typically presented today as Authorization: Bearer on MCP.

We published an end-to-end reference implementation that shows this pattern gating a live resource — PostgreSQL behind MCP:

👉 https://github.com/Mawyxx/lime-ref-postgres-mcp

How-to write-up: Secure MCP for AI agents (Postgres)

---

The core LIME pattern (this showcase)

Agent (LIME passport JWT)
        │
        │  Authorization: Bearer <aud=mcp>
        ▼
   MCP Gateway (/mcp)
        │
   ┌────┼──────────────────────────────┐
   ▼    ▼                              ▼
 Step 1              Step 2            Step 3
 0 ms JWKS verify    Policy whitelist  SQL AST defense
 RS256 in-process    agent_id → caps   pglast parse;
 cached public keys  (READ_DATA, …)    block DDL/write
 zero network on     deny by default   for readonly roles
 the hot path

Wire in one line:

1. Agent → LIME (X-Agent-Token + domain) → short-lived passport (aud=mcp)
2. Agent → your MCP RS with Authorization: Bearer
3. RS → local TokenVerifier / JWKS → agent_id = sub → your ACL

No Site Token on the MCP resource server. Agent Token never leaves the agent worker.

---

Key engineering highlights in this reference

1. Zero-network overhead verification (0 ms hot path)

The resource server wraps lime-mcp-server-sdk. At startup it runs a warmup() sequence and caches LIME Core public keys (JWKS). Every subsequent agent passport is validated in memory with asymmetric crypto (RS256). No external HTTP round-trip on the verify hot path.

2. AST-based statement-class guard

Instead of fragile regex over SQL strings, the implementation parses queries into an AST with pglast, then checks the statement class against the agent’s whitelisted capabilities before touching the asyncpg pool. A compromised agent with a READ_DATA-only policy cannot smuggle DROP TABLE past a string filter.

3. Privacy-first event logging

After an authorized agent is established, the core emits immutable AgentActionEvent cards: who called what, and how it ended. The logging pipeline records metadata and outcomes — it does not copy tool response bodies or query rows into the audit stream.

---

What this proves

Machine identity can be enforced tightly without:

• putting master DB credentials in agent configs
• human-in-the-loop IdP redirect theater for tool access
• paying network latency on every passport verify

This repo is a blueprint / reference, not a hosted LIME SaaS. Fork it, point it at your Postgres, map agent_id → capabilities, and plug your own EventBus sink for SIEM if you need it.

---

Links

Reference MCP → Postgres	https://github.com/Mawyxx/lime-ref-postgres-mcp
LIME platform	https://lime.pics
Blog how-to	https://lime.pics/blog/secure-mcp-server-ai-agents-postgres/
Agent SDK	https://github.com/Mawyxx/lime-agents-sdk
MCP RS verify SDK	https://github.com/Mawyxx/lime-mcp-server-sdk
Machine auth skill	https://lime.pics/auth.md

Relevant Links

No response

[bobleer]

Short-lived passports shrink credential blast radius, but I would still worry about a confused-deputy hop inside a multiplexed gateway. Is the authorization decision bound to the exact tool plus normalized arguments, or only to the agent, audience, and capability set? The latter can still be too broad once one MCP endpoint fronts several resources.