Closed core · open ecosystem

TrustforAI agents

Machine-only authorization

Instant cryptographic handshake between machines. No browsers. No redirects. No captchas.

Agents are forced through logins built for eyes and Chrome.

Stop building interfaces for robots as if they have eyes, fingers, and a browser.

Human OAuth is a dead end

Headless agents cannot click redirects. Pretending they have a browser is absurd.

Shared API keys fill the gap

Teams hardcode master secrets into agent configs because nothing else fits.

One injection burns the fleet

Prompt injection leaks the master key. Everyone sharing that key is compromised.

A digital passport for the agent.

A document signed by LIME that proves to the receiving Service: this Agent is authentic, who owns it, and that the passport is valid right now.

0 ms

Your Service verifies that passport locally via public JWKS — 0 ms network to LIME on the verify hot path. We do not sit in your request path.

Master keys vs isolated passports

A remote MCP server opens a private database only when the agent presents a valid LIME passport.

Bad

You put the master database token in the agent config. The bot eats a prompt injection, leaks the key, and the database is gone.

With LIME

The agent requests an isolated short-lived passport for one job, bound to one domain. Even if stolen, it dies in minutes — and does not unlock the rest of the fleet.

Two paths. Same identity.

Humans get redirects. Agents get a cryptographic handshake built for machines.

API / MCP Bearer verify

The Agent presents Authorization: Bearer with a LIME passport. Your Service verifies the signature locally. agent_id is the token subject. This is the primary path for engineers shipping tools today.

Site login

Same identity — for when an Agent must enter a Site in a browser. No human OAuth redirects. A login flow designed for agents: machine handshake, then the Agent is in.

MCP OAuth — without the human circus

External MCP resource servers need an Authorization Server. LIME is machine-only: agents obtain tokens, services verify locally — no click-through OAuth for people.

01 · Discover

Fetch authorization-server metadata (RFC 8414). No browser dance.

02 · Token

Request a short-lived RS256 JWT with the agent credential and a domain claim.

03 · Verify

The MCP resource server verifies locally via Core JWKS — 0 ms network to LIME on the hot path.

What the wire looks like

Four steps on the verify path — then the code.

  1. 01

    Agent obtains a short-lived LIME passport

  2. 02

    Agent calls Service with Authorization: Bearer

  3. 03

    Service verifies JWT via JWKS locally

  4. 04

    agent_id = sub — authorize, audit, quota

verify
import jwt
from jwt import PyJWKClient

jwks = PyJWKClient("https://lime.pics/api/v1/core/.well-known/jwks.json")
key = jwks.get_signing_key_from_jwt(token)
payload = jwt.decode(token, key.key, algorithms=["RS256"])
agent_id = payload["sub"]

Built for machine traffic

Proof-of-Work

Captchas do not work on robots. Agents pay CPU once per login; spam becomes expensive. Difficulty is tunable — not a fake millisecond claim.

Local verify

LIME does not proxy your traffic. Signature verification runs inside your process.

Short-lived JWT

Passports expire fast and can be domain-bound. Stolen tokens die with exp.

Key rotation

Signing keys roll through JWKS (ACTIVE / ROLLOVER / RETIRED). Services keep verifying with public keys.

No robot session DB

Your Service does not need a sticky session store for LIME identity — cryptography, not shared master keys.

Domain binding

A stolen passport should not travel the open web. Domain binding stops it outside the Service it was issued for — theft protection, not a leash on the Agent.

Revoke

Short-lived tokens limit blast radius. Operator revoke stops new passports — the next credential use gets 401.

Straight answers.

What does it cost?

Free forever for core agent identity: issuing passports and verifying them locally. Free covers identification — not every future LIME product.

Do you see our databases or tool data?

No. Traffic between the Agent and your Service does not go through LIME. We are not a proxy.

What do you store?

Who the Agent and Operator are, plus passport issue and revoke records. Not your database contents, prompts, or tool payloads.

Why trust the cryptography?

Your Service checks passports with public keys (JWKS). Private signing keys stay with LIME — that still does not give us access to your Service.

Are you on the request path?

Issuing and revoking go through LIME. Verifying a passport does not — 0 ms network to us on the verify path.

Open or closed?

Closed core · open ecosystem. SDKs and guides are public; the authorization core stays closed.

LIME is not for humans.

If you need Sign in with Google for people — close the tab.

  • Not Auth0 / OktaThose products optimize human login. Agents need a machine passport.
  • Not an API gatewayWe do not proxy your traffic or sit in front of your tools.
  • Not agent hostingWe authorize Agents. We do not run their loops for you.
  • Not Web3No chains, no wallets. Plain web cryptography — RSA / ECDSA.

Three misconceptions

Agents can just use normal OAuth.

They do not have a browser. Redirect theater is the wrong protocol.

Auth infrastructure always adds latency.

LIME verify is local via JWKS — 0 ms network to LIME on the hot path.

API keys are fine for agents.

Until the first log leak or prompt injection. Isolated short-lived passports exist for a reason.

Production-ready SDKs

SDK for agents

Python SDK for Agents — approve login and present passports without babysitting a browser.

pip install lime-agents-sdk
GitHub

SDK for sites

Python SDK for Sites / Services — SSE login flow, on_login handlers, local passport verify.

pip install lime-sites-sdk
GitHub

Active MVP

LIME is in active MVP. Production-ready SDKs are live. We are onboarding the first cohort of agentic platforms.

LIME — Machine Auth for AI Agents