에이전트에게 'God Mode' 권한을 주지 않고 안전하게 API를 연결하는 방법은 무엇인가요? (OAuth의 '전부 아니면 전무' 함정)
How are you guys safely giving agents API access without giving them "God Mode"? (The OAuth 'All-or-Nothing' trap)
핵심 요약
에이전트의 API 권한 범위를 세밀하게 제어하기 위한 보안 프록시 계층 구축에 대해 논의함.
- OAuth의 한계 — Gmail 등 API 사용 시 에이전트에게 과도한 권한이 부여되는 문제 발생함.
- 보안 프록시 구축 — 에이전트와 데이터 사이에 AASB 계층을 두어 세밀한 권한 제어를 시도함.
- 커뮤니티 대안 — 미들웨어 계층을 통해 특정 작업만 허용하거나 감사 로그를 남기는 방식을 사용함.
LangGraph로 멀티 에이전트 오케스트레이션 시스템을 구축 중인데, 에이전트에 도구를 바인딩하는 건 정말 쉽습니다. 하지만 프로덕션 환경에서 사용자의 민감한 데이터에 해당 도구를 연결하려는 순간, 표준 OAuth 모델은 완전히 무너집니다.
예를 들어 Gmail 통합을 봅시다: LangChain 에이전트가 단순히 이메일 답장을 초안 작성하게 하고 싶어도, Google의 표준 OAuth는 이메일을 보내고 삭제할 수 있는 권한까지 요구하게 만듭니다. 이건 '전부 아니면 전무'인 함정입니다.
시스템 프롬프트는 실제 보안 경계가 될 수 없고, Human-in-the-loop(HITL)은 자율적인 백그라운드 작업의 목적을 무색하게 만듭니다.
13년간 엔터프라이즈 SaaS를 구축해오면서 이 문제에 너무 좌절한 나머지, 저희 팀은 에이전트 앱 자체를 만드는 걸 멈추고 이를 해결하기 위한 인프라를 만들기 시작했습니다. 저희는 에이전트의 도구 호출과 사용자 데이터 사이에 위치하는 B2B 프록시 계층인 AASB(Agent Access Security Broker)를 설계하고 있습니다. 이를 통해 개발자는 엄격한 경계(예: '초안 작성 전용' 잠금)를 강제할 수 있습니다.
이 아키텍처를 더 깊이 파고들기 전에, LangChain 커뮤니티가 현재 이 문제를 어떻게 우회하고 있는지 알고 싶습니다.
- 도구 호출을 가로채기 위해 직접 커스텀 미들웨어를 만들고 계신가요?
- API 게이트웨이 수준에서 스코프를 제한하고 계신가요?
- 아니면 그냥 HITL에 의존하고 계신가요?
여러분의 접근 방식을 듣고 싶습니다.
