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:
- Agent → LIME (
X-Agent-Token + domain) → short-lived passport (aud=mcp)
- Agent → your MCP RS with
Authorization: Bearer
- 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
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: Beareron 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)
Wire in one line:
X-Agent-Token+domain) → short-lived passport (aud=mcp)Authorization: BearerTokenVerifier/ JWKS →agent_id = sub→ your ACLNo 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 awarmup()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 theasyncpgpool. A compromised agent with aREAD_DATA-only policy cannot smuggleDROP TABLEpast a string filter.3. Privacy-first event logging
After an authorized agent is established, the core emits immutable
AgentActionEventcards: 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:
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