AI 에이전트를 위한 제로 휴먼 인증 (Zero Human Auth): OAuth를 암호화된 패스포트 (Cryptographic

당신의 AI 에이전트가 새벽 3시에 고객의 대시보드에 로그인해야 합니다. 당신은 사람에게 **Allow(허용)**를 클릭해달라고 요청할 수 없습니다. 에이전트는 브라우저가 없습니다. OAuth 리다이렉트(redirect)를 완료할 수 없습니다.

그래서 당신은 다음 중 하나를 선택합니다:

워커(worker)에 영구적인 API 키를 저장한다 (그리고 절대 유출되지 않기를 기도한다)
Playwright로 헤드리스 Chrome(headless Chrome)을 실행한다 (그리고 로그인 UI가 바뀔 때마다 이를 수정한다)
디바이스 권한 부여 방식 (Device Authorization Grant)을 사용한다 (그리고 누군가가 QR 코드를 스캔할 때까지 기다린다)

이것들은 임시방편(duct tape)일 뿐입니다. 이것들은 당신에게 **AI 에이전트 신원 (AI agent identity)**을 제공하지 않습니다. 즉, 특정 사이트 세션에 결합되어 있고, 외부 도구 서버의 MCP OAuth를 위한 별도의 경로를 가진, 어떤 에이전트가 로그인했는지에 대한 서명된, 감사 가능한 증거를 제공하지 못합니다.

**제로 휴먼 인증 (Zero Human Auth)**은 로그인 경로에 사람이 없음을 의미합니다. 이것이 "인증 없음"을 의미하는 것은 아닙니다.

개발자들이 현재 이 문제를 해결하는 방식 (그리고 왜 실패하는가)

패턴 A: 정적 API 키 (static API key)

# agent_worker.py — 많은 팀이 처음에 배포하는 방식
import os

...

키 순환(key rotation), 고객별 범위 지정(per-customer scoping), 감사("어떤 에이전트가 이것을 했는가?"), 또는 침해된 워커가 관리자 권한(god-mode access)을 유출하는 상황이 발생하기 전까지만 작동합니다.

패턴 B: Playwright + OAuth

# brittle_login.py — 이를 운영 환경에 배포하지 마세요
from playwright.async_api import async_playwright

...

유지보수 비용이 높습니다. 종종 고객의 이용 약관에 위배됩니다. CI(지속적 통합) 환경에서 논리적으로 추론하는 것이 불가능합니다.

패턴 C: after — 한 번의 LIME 호출

import asyncio
import os

...

사이트 백엔드는 SSE를 통해 **암호화된 패스포트 (cryptographic passport)**를 수신하고 JWKS로 이를 검증합니다. 에이전트는 사용자의 세션 JWT를 절대 보유하지 않습니다.

왜 클래식 OAuth가 헤드리스 에이전트에게는 작동하지 않는가

OAuth 2.0은 브라우저에서의 **인간의 동의 (human consent)**를 중심으로 설계되었습니다:

사용자를 IdP(Identity Provider)로 리다이렉트
사용자가 인증
사용자가 범위(scopes)를 승인
권한 부여 코드(Authorization code)가 클라이언트로 반환

헤드리스 에이전트는 1단계와 3단계에서 실패합니다. 우회 방법들은 문제를 일으킵니다:

우회 방법 (Workaround)	대규모 확장 시 실패하는 이유
디바이스 인증 권한 부여 (Device Authorization Grant)	여전히 다른 기기에 사람이 필요함
...

MCP (Model Context Protocol) 도구 서버의 경우에도 동일한 문제가 반복됩니다. 에이전트는 표준 Authorization: Bearer 의미론을 사용하여 외부 **MCP 리소스 서버 (MCP resource servers)**를 호출해야 하지만, 모든 에이전트 프로세스 내부에 수명이 긴 비밀값 (long-lived secrets)을 생성해서는 안 됩니다.

두 가지 경로가 필요합니다:

사이트 로그인 (Site login) — 에이전트가 신원을 증명하고, **귀하의 백엔드 (your backend)**가 검증 가능한 세션 아티팩트 (session artifact)를 수신합니다.
MCP OAuth — 사이트 세션과는 별개로, 외부 도구 서버를 위한 수명이 짧은 JWT (short-lived JWT).

LIME은 암호화된 패스포트 (cryptographic passports) (RS256 JWT)와 공식 Python SDK를 통해 이 두 가지를 모두 구현합니다.

해결책: 암호화된 패스포트 + 단일 에이전트 호출

브라우저를 리다이렉트하는 대신, LIME은 **헤드리스 로그인 프로토콜 (headless login protocol)**을 실행합니다:

사이트 백엔드 (Site backend)                LIME Core                 에이전트 워커 (Agent worker)
     |                          |                          |
     |-- 로그인 요청 생성 (create login request) ->|                          |
...

주요 특징:

암호화된 패스포트 (Cryptographic passport) — LIME Core가 서명한 RS256 JWT (aud=lime-site-login, TTL ~60초); 사이트는 JWKS 검증 (JWKS verification) (GET /api/v1/core/.well-known/jwks.json)을 통해 이를 검증합니다.
제로 휴먼 인증 (Zero Human Auth) — 에이전트가 login(request_id)를 한 번 호출합니다. OAuth 리다이렉트나 QR 코드가 필요 없습니다.
작업 증명 (Proof-of-Work) — CAPTCHA 대신 SHA-256 PoW 챌린지를 사용합니다 (봇은 연산 비용을 지불하고, 사람은 지불하지 않습니다).
패스포트는 에이전트가 아닌 사이트로 전달됨 — 워커가 침해되더라도, 사용자의 사이트 세션 JWT를 절대 보유하지 않습니다.

이것은

사이트 백엔드 (Site backend) — 요청 생성, SSE를 통한 패스포트 수신

from contextlib import asynccontextmanager

from fastapi import FastAPI
...

verify_passport()는 서명 (JWKS), aud == "lime-site-login", 만료 시간 (플랫폼 TTL ≤120s), 선택적 request_id 바인딩을 확인하며, agent_id, user_id, agent_reputation과 같은 클레임 (claims)을 노출합니다.

에이전트 워커 (Agent worker) — 단일 호출, PoW 포함

import asyncio
import os

...

login()은 PoW (Proof of Work) 챌린지를 가져와 스레드 풀 (thread pool)에서 이를 해결하고, X-Agent-Token으로 승인합니다. **암호화된 패스포트 (cryptographic passport)**는 에이전트에게 반환되는 것이 아니라, SSE를 통해 사용자의 사이트로 전달됩니다.

MCP OAuth: 자격 증명을 섞지 않고 도구 사용하기

에이전트는 또한 **외부 MCP 리소스 서버 (external MCP resource servers)**를 호출합니다. 이는 다른 JWT (aud=mcp, 약 5분 TTL)를 사용합니다. MCP를 위해 사이트 패스포트를 재사용하지 마세요.

import asyncio
import os

...

자격 증명 경로 (Credential lanes) (이를 혼용하면 보안이 깨집니다):

경로	헤더	용도
LIME 플랫폼	`X-Agent-Token`	`login()`, `get_mcp_access_token()`
외부 MCP RS	`Authorization: Bearer <mcp_jwt>`	`list_tools`, `call_tool`

MCP 서버 측에서는 lime-mcp-server-sdk를 사용하여 Bearer 토큰을 검증하세요 — JWKS + RS256, 캐싱된 키, 비동기 (async) 친화적입니다.

지금 바로 시도해 보세요. 만약 이것이 귀하의 문제와 일치한다면: 설치에는 약 2분이 소요됩니다.
pip install lime-agents-sdk lime-sites-sdk
문서: https://lime.pics/docs

LIME과 대안들의 비교

솔루션	복잡도	에이전트 네이티브 여부?	MCP OAuth 지원?	가격
자체 제작 API 키 (Roll-your-own API key)	낮음	아니요	아니요	무료
...

LIME은 현재 AI 에이전트 신원 (AI agent identity) 및 헤드리스 사이트 로그인 (headless site login)을 위해 무료로 제공됩니다. 비즈니스 모델은 향후 에이전트 결제에 대한 수수료 방식입니다. 이는 Stripe가 패스포트 발급 비용을 청구하는 대신 거래에서 수수료를 가져가는 방식과 유사합니다.

Agent Passport는 위임 체인(delegation chains)과 7가지 규범적 제약 조건(normative constraints)을 가진 완전한 프로토콜(IETF 초안)입니다. 강력하지만 구현하기에는 무겁습니다. Auth0는 대규모 사용 시 유료 플랜을 제공하는 프리미엄(freemium) 경로를 제공합니다. LIME은 더 작은 표면적에 최적화되어 있습니다. 에이전트 측에서의 단 한 번의 Python 호출, 사이트 측에서의 SSE + JWKS 검증 (JWKS verification), 그리고 외부 리소스 서버를 위한 즉시 사용 가능한 MCP OAuth JWT를 제공합니다.

보안 참고 사항 (운영 환경 적용 전 반드시 읽어주세요)

이 모델이 올바르게 처리하는 부분

에이전트 메모리에 영구적인 API 키를 두는 대신, 수명이 짧은 서명된 아티팩트(signed artifacts)를 사용합니다.
사이트는 캐싱된 Core JWKS를 통해 JWT를 검증합니다. 키가 워밍업(warm)된 후에는 매 요청마다 LIME API를 호출하는 왕복(round-trip) 과정이 필요 없습니다.
작업 증명(PoW)은 정당한 에이전트의 사용자 경험(UX)을 저해하지 않으면서도, 무차별적인 승인 스팸(brute approval spam)에 대해 속도 제한(rate-limits)을 적용합니다.
사이트 패스포트와 MCP 토큰의 분리는 피해 범위(blast radius)를 제한합니다.

여전히 직접 수행해야 하는 작업

LIME_AGENT_TOKEN 및 LIME_SITE_TOKEN을 비밀값(secrets, 예: Vault, K8s secrets, CI vars)으로 저장하세요. 클라이언트 측 코드나 LLM 컨텍스트에 절대 포함해서는 안 됩니다.
request_id를 일회용으로 취급하고, verify_passport(expected_request_id=...)에서 이를 바인딩하세요.
프로세스당 하나의 LimeSite를 실행하고 영구적인 SSE 연결을 유지하세요. HTTP 요청마다 생성하지 마세요.
워커(worker)가 침해된 경우 LIME 소유자 포털에서 에이전트 토큰을 교체(rotate)하세요.
PoW는 남용 방지(abuse resistance) 수단이지 멀웨어 탐지기가 아닙니다. 자체적인 에이전트 허용 목록(allowlists) 및 속도 제한(rate limits)과 병행하여 사용하세요.

Zero Human Auth는 권한 부여 흐름(authorization flow)에서 인간을 제거하지만, 보안에 대한 귀하의 책임을 제거하는 것은 아닙니다. LIME은 도구(JWT, JWKS, PoW)를 제공할 뿐입니다. 비밀값 관리, 토큰 교체, 속도 제한 설정은 여전히 귀하의 몫입니다.

LIME을 사용할 때 vs 직접 구현할 때

소유하고 있는 두 서비스 간에 단일 정적 API 키만 필요한 경우라면 직접 구축하세요.

다음과 같은 경우에는 **AI 에이전트 신원 계층 (AI agent identity layer)**을 고려하십시오:

여러 에이전트가 감사 가능한 신원(auditable identity)을 가지고 **고객 사이트 (customer sites)**에 로그인해야 하는 경우
JWKS 검증 (JWKS verification) 및 표준 JWT 클레임 (agent_id, request_id, agent_reputation, user_kyc_level)이 필요한 경우
MCP 생태계에 참여하고 있으며, 요청마다 PyJWT와 메타데이터 페치(metadata fetch)를 직접 구현하지 않고 MCP OAuth를 사용하고 싶은 경우

OAuth와 싸우는 것을 멈추세요. 패스포트를 출시하세요.

pip install lime-agents-sdk lime-sites-sdk

PyPI: lime-agents-sdk · lime-sites-sdk · lime-mcp-server-sdk

GitHub: lime-agents-sdk · lime-site-sdk · lime-mcp-server-sdk

Docs: https://lime.pics/docs

에이전트에게 암호화된 패스포트 (cryptographic passport)를 부여하세요. JWKS로 이를 검증하세요. MCP는 독자적인 OAuth 경로를 유지하게 하세요.

질문이 있으신가요? GitHub에 이슈를 오픈하거나 X에서 @MawyxxMC에게 멘션(ping)을 보내주세요.

Dev.to 태그: python, ai, security, jwt, mcp, oauth

Insights