헤드리스 (Headless) AI 에이전트를 위한 TOFU 기반 인증 모델

Mohamed Sherif 작성

최근에 AI 에이전트를 구축해 보셨다면, 아마 동일한 문제에 직면했을 것입니다.

첫 번째 통합은 쉽습니다.

에이전트에 GitHub 접근 권한이 필요하면, Personal Access Token (PAT)을 생성하여 .env 파일에 추가하고 다음 단계로 넘어가면 됩니다.

GITHUB_PAT=ghp_xxxxxxxxxxxx

그다음 Slack을 추가합니다.

SLACK_BOT_TOKEN=xoxb-xxxxxxxxxxxx

그다음 Notion을 추가합니다.

NOTION_TOKEN=secret_xxxxxxxxxxxx

그다음 Linear를 추가합니다.

LINEAR_API_KEY=lin_api_xxxxxxxxxxxx

머지않아 당신의 AI 에이전트는 로컬 환경, CI/CD 파이프라인, Kubernetes secrets, 그리고 프로덕션 인프라 전반에 흩어져 있는, 수명이 긴 자격 증명 (Credentials)들의 점점 늘어나는 집합에 의존하게 됩니다.

작동은 합니다.

하지만 작동하지 않게 될 때까지 말이죠.

⸻

모든 에이전트 빌더가 결국 맞닥뜨리는 문제

전통적인 소프트웨어는 사용자를 인증합니다.

AI 에이전트는 스스로를 인증합니다.

이것은 미묘하지만 중요한 차이입니다.

OAuth는 애플리케이션이 접근 권한을 요청할 때 '허용 (Allow)'을 클릭할 수 있는, 브라우저 앞에 앉아 있는 인간을 중심으로 설계되었습니다.

AI 에이전트는 브라우저가 없습니다.

그들에게는 사용자가 없습니다.

에이전트가 실행되는 동안 접근 권한을 승인해 줄 수 있는 사람이 아무도 없습니다.

대부분의 개발자는 결국 다음 네 가지 패턴 중 하나로 회귀하게 됩니다.

1. Personal Access Tokens (PAT)

가장 빠르게 구축할 수 있습니다.

하지만 기술 부채 (Technical debt)를 쌓는 가장 쉬운 방법이기도 합니다.

결국 다음과 같은 상황에 처하게 됩니다:

• 수명이 긴 비밀 값 (Long-lived secrets)
• 런타임 메모리 (Runtime memory)에 상주하는 자격 증명
• 수동 로테이션 (Manual rotation)
• 귀속성 (Attribution) 부재
• 어려운 사고 대응 (Incident response)

2. Custom OAuth

"올바른" 해결책입니다.

모든 제공업체에 대해 다음 작업을 수행해야 합니다:

• OAuth 애플리케이션 등록
• 콜백 (Callbacks) 처리
• 리프레시 토큰 (Refresh tokens) 암호화
• 액세스 토큰 (Access tokens) 갱신
• 만료 관리
• 동의 흐름 (Consent flows) 구축

모든 통합에 대해 이 과정을 반복해야 합니다.

당신의 인증 계층 (Authentication layer)은 당신이 실제로 구축하려는 제품보다 빠르게 커져 버립니다.

3. Secrets Managers

AWS Secrets Manager, Vault, Azure Key Vault…

이것들은 저장 문제를 해결합니다.

하지만 인증 (Authorization) 문제를 해결하지는 못합니다.

누군가는 여전히 자격 증명을 프로비저닝 (Provision)해야 합니다.

결국 에이전트가 자격 증명을 받게 됩니다.

여전히 승인 워크플로 (Approval workflow)가 없으며, 에이전트 간의 구분이 불가능합니다.

1. 서비스 계정 (Service Accounts)

편리합니다.

하지만 해당 계정을 공유하는 모든 에이전트는 사실상 동일한 정체성 (Identity)이 됩니다.

만약 에이전트 하나가 침해되면, 해당 서비스 계정을 사용하는 모든 워크로드 (Workload)가 영향을 받습니다.

⸻

우리가 실제로 원했던 것

이러한 접근 방식들을 검토한 후, 우리는 근본적으로 다른 무언가가 필요하다는 것을 깨달았습니다.

우리의 요구 사항은 놀라울 정도로 단순했습니다.

• 에이전트는 절대로 장기 자격 증명 (Long-lived credentials)을 받아서는 안 됩니다.
• 사람은 새로운 에이전트를 정확히 한 번만 승인해야 합니다.
• 모든 작업은 특정 에이전트의 소행임을 추적할 수 있어야 합니다.
• 에이전트 하나를 취소 (Revoking)하더라도 다른 배포 (Deployment)에 영향을 주어서는 안 됩니다.
• 기존의 에이전트 프레임워크 (Agent frameworks)를 변경할 필요가 없어야 합니다.

이러한 조합은 예상보다 더 어려웠습니다.

⸻

SSH에서 아이디어 빌려오기

돌파구는 예상치 못한 곳에서 찾아왔습니다.

SSH는 수년 전 매우 유사한 문제를 해결했습니다.

서버에 처음 연결할 때, SSH는 다음과 같이 묻습니다:

"이 호스트를 신뢰하십니까?"

승인하면 서버 지문 (Fingerprint)이 기억됩니다.

이후의 연결은 자동으로 이루어집니다.

만약 지문이 예기치 않게 변경되면, SSH는 경고를 보냅니다.

이 모델을 최초 사용 시 신뢰 (Trust On First Use, TOFU)라고 부릅니다.

우리는 스스로에게 질문했습니다:

AI 에이전트도 같은 방식으로 작동한다면 어떨까?

⸻

AI 에이전트에 TOFU 적용하기

서버 지문을 신뢰하는 대신, 에이전트 지문을 신뢰합니다.

알 수 없는 에이전트가 연결된 서비스에 대한 액세스를 처음 요청할 때:

1. 게이트웨이 (Gateway)가 요청을 일시 중단합니다.
2. 소유자에게 승인 알림이 전송됩니다.
3. 소유자가 에이전트를 승인 (또는 거부)합니다.
4. 지문이 저장됩니다.
5. 해당 지문으로부터 오는 향후 요청은 자동으로 진행됩니다.

시각적으로 흐름은 다음과 같습니다:

개발자가 GitHub에 한 번 연결
│
▼
Gateway가 OAuth 자격 증명(credential)을 저장
│
▼
개발자가 에이전트에게 하나의 Passkey URL을 제공
│
▼
에이전트가 GitHub 액세스를 요청
│
▼
알 수 없는 지문(fingerprint)인가?
│
예 ─────────► 사용자의 승인
│
▼
지문이 신뢰됨
│
▼
수명이 짧은 토큰(short-lived token)이 교환됨
│
▼
에이전트가 GitHub를 호출

중요한 차이점은 에이전트가 무엇을 받지 못하는가 하는 점입니다.

에이전트는 다음 항목들을 절대 볼 수 없습니다:

• OAuth 리프레시 토큰 (refresh tokens)
• 개인 액세스 토큰 (Personal Access Tokens)
• 저장된 자격 증명 (stored credentials)
• 클라이언트 비밀번호 (client secrets)

대신, 에이전트는 현재 세션을 위한 수명이 짧은 토큰을 받습니다.

⸻

비밀번호 대신 지문 (Fingerprints Instead of Secrets)

모든 에이전트는 고유한 정체성(identity)을 가집니다.

공유된 비밀번호(shared secret)로 정체성을 식별하는 대신, 우리는 에이전트의 런타임(runtime) 특성으로부터 지문(fingerprint)을 도출합니다.

그 지문이 우리가 권한을 부여하는 정체성이 됩니다.

이를 통해 몇 가지 유용한 속성을 확보할 수 있습니다.

귀속 (Attribution)

모든 API 요청은 하나의 특정 에이전트 정체성과 연결될 수 있습니다.

감사 (Audit)

어떤 에이전트가 어떤 서비스에 언제 접근했는지 정확히 알 수 있습니다.

취소 (Revocation)

신뢰된 지문 하나를 삭제하는 것만으로 자격 증명을 교체하거나 인프라를 재배포할 필요 없이 즉시 해당 에이전트를 차단할 수 있습니다.

폭발 반경 감소 (Blast Radius Reduction)

에이전트 하나가 침해되더라도 해당 에이전트 자신에게만 영향을 미칩니다.

동일한 자격 증명을 사용하는 모든 배포에 영향을 주지 않습니다.

⸻

통합 방식 (What Integration Looks Like)

서비스 연결은 대시보드를 통해 단 한 번만 이루어집니다.

OAuth가 완료되면 자격 증명은 Gateway 내부에 머뭅니다.

에이전트 설정은 매우 간결하게 유지됩니다.

{
"mcpServers": {
"passkey": {
"command": "npx",
"args": ["passkey-mcp"]
}
}
}

LangChain, CrewAI, Strands, Bedrock AgentCore 또는 기타 MCP 호환 프레임워크의 관점에서는 아무것도 변하지 않습니다.

에이전트는 단순히 다음과 같은 도구들을 발견할 뿐입니다:

github__list_issues
github__create_comment
slack__post_message
linear__create_issue
notion__query_database

인증 계층은 보이지 않게 됩니다.

⸻

토큰 교환 (Token Exchange)을 선택한 이유

한 가지 설계 결정에 대해서는 설명이 필요합니다.

모든 요청을 프록시(Proxying)하는 대신, 게이트웨이는 토큰 교환 (Token Exchange)을 수행합니다.

인증이 완료되면, 에이전트는 수명이 짧은 업스트림 토큰 (Upstream Token)을 받습니다.

그 후 API 트래픽은 제공자(Provider)에게 직접 전달됩니다.

이는 다음과 같은 몇 가지 장점을 제공합니다:

• 낮은 지연 시간 (Lower Latency)
• 게이트웨이 병목 현상 없음
• 독점 프로토콜 (Proprietary Protocol) 미사용
• 기존 MCP 툴링과의 호환성

⸻

기타 설계 결정

연결 URL 순환 (Rotating Connection URLs)

연결 URL은 순환하는 슬러그 (Slugs)를 사용합니다.

어제의 URL을 캡처하는 것만으로는 액세스 권한을 얻기에 충분하지 않습니다.

반드시 신뢰할 수 있는 지문 (Fingerprint)과도 일치해야 합니다.

동적 클라이언트 등록 (Dynamic Client Registration)

지원되는 경우, 모든 고객은 플랫폼 전체에서 하나를 공유하는 대신 각자의 OAuth 클라이언트를 할당받습니다.

이를 통해 속도 제한 (Rate-limit) 경합을 줄이고 조직 간의 장애를 격리할 수 있습니다.

MCP 네이티브 (MCP-Native)

또 다른 SDK를 발명하는 대신, 우리는 MCP를 중심으로 구축했습니다.

이미 MCP를 지원하는 모든 프레임워크는 추가적인 통합 작업 없이 동일한 인증 모델을 사용할 수 있습니다.

⸻

이 접근 방식이 유효한 경우

이 모델은 특히 다음과 같은 경우에 유용합니다:

• 에이전트가 여러 SaaS 플랫폼과 통신하는 경우
• 프로토타입 단계를 넘어 배포하는 경우
• 자격 증명 관리 (Credential Management)가 운영 오버헤드가 된 경우
• 귀속 (Attribution) 및 감사 가능성 (Auditability)이 필요한 경우
• 보안 팀이 인프라 전반에 PAT가 퍼지는 것을 원치 않는 경우

단 하나의 통합만 사용하는 주말 프로젝트를 만들고 있다면, PAT로도 충분할 것입니다.

하지만 여러 통합과 프로덕션 배포가 고려 대상이 되면, 트레이드오프 (Trade-offs)가 변하기 시작합니다.

⸻

시도해 보기

이 모델을 실험해 보고 싶다면, 로컬 브로커 (Local Broker)를 설치하세요:

npx passkey-mcp

그 다음 다음을 통해 모든 것을 관리하세요:

👉 https://dashboard.v2n2x.com

Passkey 대시보드를 통해 첫 번째 OAuth 제공자를 연결한 다음, MCP 호환 에이전트를 해당 지점으로 지정하세요.

현재 플랫폼은 GitHub, Slack, Jira, Confluence, Notion, Stripe, Salesforce, HubSpot, Linear를 포함하여 19개의 통합을 지원합니다.

프로덕션 AI 에이전트를 구축하는 개발자분들의 피드백을 기다립니다.

우리가 답하고자 했던 가장 큰 질문은 간단했습니다:

개발자 경험 (Developer Experience)을 악화시키지 않으면서, AI 에이전트로부터 장기 생존 자격 증명 (Long-lived credentials)을 제거할 수 있을까?

지금까지의 답변은 '그렇다'입니다.