AI 에이전트 보안 - 자격증명 대신 고유 신원과 세분화된 권한을 주는 에이전트 인증 프로토콜 제안

핵심 메시지

• 오늘날 AI 에이전트는 사용자의 자격증명을 그대로 빌려 '사용자인 척' 행동한다. 회사로 치면 신입에게 대표이사 계정을 건네주는 셈이다.
• 발표자는 에이전트에게 자격증명 대신 권한을 주자고 제안한다. '나인 척하라'가 아니라 '이 범위 안에서 나를 대신하라'로 바꾸자는 것이다.
• 해결해야 할 문제는 세 가지다. 에이전트가 할 수 있는 일을 스스로 찾는 발견, 무엇을 허용할지 정하는 권한 부여, 그리고 누가 했는지 남기는 신원이다.
• 각 에이전트에 개인키 기반 고유 신원을 부여하면 어떤 에이전트가 누구를 대신해 무엇을 했는지 로그로 추적하고, 문제가 생긴 에이전트만 골라 차단할 수 있다.
• 이 제안은 오픈소스 초안으로 공개돼 있으며, 장기간 살아 있는 에이전트와 조직 정책을 다루는 다음 버전이 준비 중이다.

쉽게 이해하기

AI 엔지니어 콘퍼런스에서 진행된 이 워크숍은 청중에게 질문을 던지며 시작한다. 매일 AI 에이전트를 쓰는 사람은 많았지만, 지메일이나 캘린더 같은 개인 계정을 에이전트에 연결한 사람은 훨씬 적었다. 발표자는 그 이유를 짚는다. 지금 방식대로 연결하면 에이전트는 사용자를 대신하는 것이 아니라 사실상 사용자인 척 행동하게 되기 때문이다.

발표자가 든 비유는 채용이다. 회사에 사람을 새로 뽑으면 그 사람 몫의 계정과 자격증명을 따로 만들어 준다. 대표이사 계정을 넘겨주고 메일을 읽으라고 하지는 않는다. 그런데 에이전트에게는 정확히 그렇게 하고 있다는 지적이다. 인터넷 초창기에 모두가 기술에 들떠 있다가 뒤늦게 보안과 프라이버시를 고민하기 시작했던 시기와 지금이 닮았다고도 덧붙였다.

첫 번째 문제는 발견이다. 지금은 사람이 일일이 도구를 연결하고 무엇을 할 수 있는지 알려줘야 한다. 발표자는 전화번호부 비유를 들어, 에이전트가 참조할 수 있는 디렉터리가 있어야 한다고 말한다. 제안된 프로토콜에는 OIDC의 well-known 엔드포인트와 비슷한 방식으로 서비스가 자신의 연동 방식과 기능 목록을 공개하는 구조가 담겼다. 다만 모든 서비스가 이를 채택하기 전까지는, 이미 널리 쓰이는 오픈API 명세를 기능 목록으로 변환해 디렉터리를 채우는 방식을 과도기 대안으로 제시했다.

두 번째는 권한이다. 발표자는 기존의 스코프가 너무 뭉툭하다고 본다. '읽기' 스코프 하나로는 무엇을 얼마나 읽는지 통제할 수 없다. 대신 개별 동작 단위의 기능(capability)을 정의해 도구마다 허용 여부를 정하자고 제안한다. 사용자의 의도가 하나 또는 여러 기능에 연결되고, 에이전트는 그 범위 안에서만 움직인다.

세 번째는 신원이다. 제안의 핵심은 에이전트마다 고유한 개인키를 갖게 하는 것이다. 에이전트가 자기 키로 토큰에 서명하면, 서비스 입장에서는 '사용자가 접근했다'가 아니라 '어느 호스트에서 만들어진 어떤 에이전트가 이 사용자를 대신해 접근했다'는 기록이 남는다. 발표자는 이를 두고 에이전트가 사용자 뒤에 숨는 구조에서 벗어나 스스로 주체가 되는 전환이라고 표현했다.

시연에서는 MCP로 연결한 에이전트가 메일을 읽는 과정을 보여줬다. 기본 권한은 읽기로 제한돼 있어, 메일을 보내려 하자 별도의 승인 요청이 뜨고 사용자가 승인한 뒤에야 발송됐다. 승인을 거부하면 동작은 차단됐다. 이어 해당 에이전트를 폐기하자 연결이 끊기고 이전에 보낸 메일을 다시 읽지 못했다. 로그에는 어떤 에이전트 ID가 어떤 사용자를 대신해 무엇을 했는지가 남았다.

주요 인사이트

• 권한 축소보다 신원 부여가 먼저다. 에이전트에 고유 신원이 없으면 감사 로그도, 선별적 차단도 불가능하다. 지금은 문제가 생기면 연동 전체를 끊는 것 외에 방법이 없다.
• 기존 OAuth 체계에서 에이전트는 '사용자를 대신하는 앱'으로만 표현된다. 이 제안은 에이전트 자체를 인증 주체로 승격시켜 책임 소재를 분리하려 한다.
• 발표자는 AI 게이트웨이와의 차이를 묻는 질문에, 게이트웨이는 에이전트마다 고유 신원을 부여하지 않는다는 점을 들어 구분했다. 트래픽 통제와 신원 기반 추적은 다른 층위의 문제다.
• 보안과 사용성의 균형이 실질적 과제로 언급됐다. 매 동작마다 승인을 요구하면 아무도 쓰지 않기 때문에, 호스트별·사용자별 정책으로 기본 허용 범위를 정하는 방식이 논의됐다.
• 과도기 설계가 현실적이다. 모든 서비스가 새 표준을 채택하길 기다리는 대신, 이미 존재하는 오픈API 명세를 재활용해 지금 당장 동작하게 만드는 접근을 택했다.
• 발표자는 이 프로토콜이 기업용에 그치지 않고 AI를 쓰는 모든 개인에게 필요한 것이라고 강조하며 오픈소스 참여를 요청했다.

자주 묻는 질문

관련 AI 소식