Securing Agents with Open Standards - Bobby Tiernay and Kam Sween, Auth0

영상 링크: Securing Agents with Open Standards — Bobby Tiernay and Kam Sween, Auth0
채널명: AI Engineer

오픈 표준으로 AI 에이전트의 보안을 강화하는 방법 핵심 요약

• 본 영상은 OPZero(오제로) 엔지니어인 Bobby Tiernay와 Kam Sween이 AI 에이전트 중심의 세계에서 신원 및 접근 제어를 안전하게 구현하는 방법, 구체적으로 오픈 표준에 기반한 접근법을 설명함
• 에이전트가 사용자를 대신해 실제 행동을 수행하면서 주요 보안 문제가 발생함: 시크릿이 프롬프트에 노출, 범위가 지나치게 넓은 권한, 추적·감사가 어려운 상황 등
• OWASP가 ‘과도한 에이전시(excessive agency)’라 부르는 문제는, 에이전트에게 충분한 제한(guardrail) 없이 API 호출, 토큰 사용 등 과도한 권한을 부여한 결과임
• 보안 강화를 위해선 에이전트가 각 사용자, 각 API별로 짧은 수명의 토큰을 백엔드 서버를 통해 받아 사용하고, 이를 통해 누가 어떤 행동을 했는지 추적 가능해야 함
• 신원(identity)는 모든 행동(로그)과 사용자를 연결하는 필수 조건: 신원 연결 없이 범위 제한, 토큰 회전 등으로도 실제 보안은 확보할 수 없음
• 에이전트가 누구를 위해 동작하는지 명확히 하려면 OAuth 2.1, Rich Authorization Requests(RAR), 토큰 교환 등 오픈 표준 플로우를 활용해 실제 사용자의 권한과 행동을 연결해야 함
• RAG(Retrieval-Augmented Generation) 시스템 등에서 미세한 권한 제어(fine-grained authorization) 및 정책 강제화가 중요하며, 이는 항상 LLM 내부가 아닌 데이터 검색 단계에서 이루어져야 함
• SIBA(클라이언트 주도 백채널 인증) 등 사용자의 명시적 승인(컨센트)이 필수적인 액션을 위해 비동기적 인증 과정을 지원, 화면이 없는 상황 등에서도 보안성과 사용성을 모두 확보
• MCP(Multi-Client Platform) 서버, 토큰 볼트 등 최신 인프라 패턴을 적용하면 에이전트 동작의 컨텍스트, 데이터 접근, 제3자 인증 정보 노출 문제를 해결할 수 있음
• 오픈 표준 활용과 실무 예시, 데모(로컬 AI 주식거래 에이전트 시연), Ozuro와 같은 플랫폼 및 OpenFGA, OIDC, SIBA 등 표준 및 툴의 실제 적용 방식을 상세히 소개함

세부 요약 - 주제별 정리

에이전트가 진화함에 따라 새로운 보안 위협이 확대되고 있음

• AI 에이전트가 단순 프롬프트 응답을 넘어 실세계에서 API 호출, 워크플로우 실행, 외부 시스템 제어 등 실제 행동을 수행함에 따라 새로운 보안 취약점이 드러남
• 시크릿(credential, API key 등)이 프롬프트나 환경 변수에 노출됨
• 범위(scope)가 너무 넓은 접근 권한을 가진 토큰이 재사용되면 책임 주체가 모호해지고, 사고 시 감사와 추적이 어려워짐
• 보안 인시던트가 생겼을 때 문제의 원인과 사용자 식별이 어렵고, 이런 맹점이 OWASP에서 언급된‘excessive agency(과도한 에이전시)’와 연결됨
• 에이전트가 과도하게 권한을 가져갈 때, 민감 데이터 노출(OWASP 위험 항목) 등 다양한 보안 이슈가 동시에 발생

기존의 공유 시크릿 방식과 사용자별 토큰 기반 보안 접근법의 차이점을 구체적으로 설명

• 기존 패턴: 에이전트가 환경 변수에 저장된 공유 API 키로 외부 서비스 호출
  • 여러 사용자·서비스에서 동일 키 사용 → 책임소재 미구분, 토큰 교체·회전 어려움, 위험
• 개선 패턴: 에이전트는 사용자 별·API 별 백엔드 서버로부터 단발성(짧은 수명) 토큰을 발급받아 사용
  • Token Exchange, 토큰 볼트 등 적용
  • 감사(누가, 언제, 어디에서 어떤 행동을 했는지) 가능
  • 토큰 회전, 키 관리, 다양한 시스템 연동이 중앙화·자동화되어 대규모 에이전트 환경에서도 안정적으로 확장 가능

신원(identity)은 모든 에이전트 행동의 근본적인 통제 수단임을 강조

• 신원(identity)이 없는 에이전트 설계에서는 아무리 토큰 범위를 잘 제한해도 실질적인 접속 제어·추적이 불가능
• 에이전트가 실제 누군가를 대신해서 행동하려면, 신원 인증 과정을 통한 사용자의 권한 위임이 필요함
• ‘Confused deputy problem’(혼동된 대리인 문제): 에이전트가 실제로 누구를 대신해서 어떤 범위 내에서 동작해야 하는지 불명확하면 위험함
• OAuth 2.1, RAR, 토큰 교환 등 오픈 표준을 써서 신원-권한-행동 3자 연계 필요

백엔드 기반 단일 사용자·API 토큰 설계 및 운용 방식의 구체 절차를 상세히 다룸

• 에이전트는 공유 구성 정보에서 키를 꺼내는 대신, 백엔드에 요청을 보내 단일 사용자·API 전용 짧은 수명 토큰을 받아 사용
• 백엔드는 Vault에서 크리덴셜을 관리, 토큰 교환(token exchange) 등 표준 플로우로 토큰 발급
• 발급된 토큰은 즉시 사용 후 폐기되어, 에이전트 자체에 시크릿을 저장할 필요 없음
• OAuth, OIDC 등 표준을 준수함으로써 검증된 보안 모델 활용

RAG 시스템에서 데이터 접근 권한을 미세 조정하고 정책 기반 접근 제어 구현이 필수임을 설명

• Retrieval-Augmented Generation(RAG) 시스템에서 단순히 데이터를 모델에 “던져주기”만 하면 사용자별로 차등된 데이터를 보호하기 어려움
• 미세 권한부여(fine-grained authorization)는 LLM이 아니라 데이터 검색(rerieval) 단계에서 구현되어야 정책 강제화가 쉬움
• 민감 데이터 접근을 사전에 차단·정책적으로 제어하여 기업·사용자 보안이 강화됨

SIBA(클라이언트 주도 백채널 인증)를 활용해 사용자 동의 없는 무분별한 에이전트 행동을 원천 차단함

• SIBA(Client Initiated Back Channel Authentication) 개념 도입: 에이전트가 민감한 행동(예: 주식 매수 등) 실행 전, 인증 서버가 사용자의 기기로 푸시 알림 등 요청→ 사용자가 명시적으로 승인/거부/추가 정보 요청을 할 수 있음
• 사용자가 화면(UI)에 직접 드러나지 않아도, 백채널을 통해 행동 승인을 얻을 수 있어 백그라운드 에이전트, 저화면 환경 등에서 유용함
• Ozero 등 주요 플랫폼, OIDC 스펙 등에서 공식적으로 지원

실제 TypeScript 기반 주식 거래 에이전트 데모를 통한 보안 설계 방식 시연

• 로컬 AI 트레이딩 어시스턴트가 주식 매수 명령(tool call)을 통해 브로커 서비스에 실거래를 시도하는 데모를 진행
• 에이전트가 거래 요청을 하면, SIBA를 통해 사용자의 명시적 승인을 받는 흐름
• 사용자 인증 및 컨텍스트 지정 단계→ 토큰 볼트(System)를 통한 시크릿 관리→ SIBA 정책 적용해 tool call 시 매번 승인 요청
• OIDC 래퍼(예: useDeviceFlow)로 사용자 액세스 토큰 부여, SIBA로 최종적 사용자의 거버넌스 보장
• 토큰 볼트는 패스워드 매니저와 다르게 크리덴셜이 아닌 토큰을 관리하는 시스템임

실시간 데모에서 발생하는 실무적 고려사항 및 관리자 시나리오 전개

• 여러 사용자, 여러 에이전트, 실시간 데이터 접근 등 복잡한 환경에서는 반드시 신원 인증과 인증 데이터의 일관된 관리가 필요함
• 실무 환경에서는 유저 인증을 UI에서 진행, 이후 민감 작업은 SIBA를 이용한 추가 동의만 받으면 됨(브라우저 노출 불필요)
• OAUTH2, OIDC, SIBA 등 공개 표준 위주로 개발하면, 추후 확장 시에도 문제없이 연계 가능

일부 흐름 실패시 대안 설명 및 사용성 강조

• 실제 데모 환경에서 Wi-Fi 등 네트워크 이슈 발생 시, 데모 과정을 구두로 설명
• SIBA를 통한 푸시 알람 승인 요청이 단순 “무작위 알림”이 아니라 “에이전트가 무엇을, 누구를 위해 실행하려는지” 명확히 전달
• 일단 한 번 인증하면, 이후 반복적인 액션에서는 추가 UI나 복잡한 인증 없음(단, SIBA 루프에서만 해당)
• OpenID Connect(OIDC), SIBA, Rich Authorization Requests 등이 실제 공식 표준이 되어 가고 있음을 강조

오픈 표준 및 개발자 친화 기술 도구들(Ozero, OpenFGA 등)의 활용과 커뮤니티 협업 방향 정리

• 개발자 입장에서 직접 모든 빌딩 블록을 구현하는 부담을 줄이기 위해, 다양한 오픈 플랫폼과 모듈 활용 가능
• Ozero·OpenFGA·MCP 등 도구들은 Token Exchange, Token Vault, fine-grained authorization, 비동기 승인 등에서 이미 강력한 지원
• 반드시 Ozero 외에도, 표준(OpenID/FGA MCP 등)과 호환 가능한 다양한 오픈소스 라이브러리 혼합 사용 가능
• MCPO 등 오픈 MCP 규격에 대한 사양 논의에도 참여, 업계 전반의 보안 표준 재정립을 목표로 활동

영상의 결론부에서 원칙과 실무적 권장사항을 정리

• API 기반 AI 에이전트 시대에 신뢰성 있는 신원 기반 인증, 명확한 사용자 범위 제한, 행동 권한 추적이 핵심임
• 표준(Command Confirmation, SIBA, Token Exchange 등) 준수, 오픈 툴 활용, 사용자 주도 보안 프로세스 구현이 필수
• 현존하는 오픈 표준, API, Dev 툴로 대부분의 보안 문제를 이미 현장에서 해결할 수 있음을 입증
• 현행 보안 문제·운영상 어려움이 있는 개발자 누구든 커뮤니티 및 오픈소스 협업을 환영한다는 메시지로 마무리