개념 수준의 글이다. 구현 구성의 세부는 특허 출원 후 공개한다.
API 키는 신원이 아니다
에이전트가 외부 서비스를 호출할 때 가지고 가는 것은 대개 API 키입니다. 키는 "이 호출은 허가된 것이다"를 말합니다. 그러나 "이 거래의 책임 주체가 누구인가"는 말하지 않습니다.
둘은 다른 질문입니다. 첫 번째는 인가(authorization), 두 번째는 신원(identity) 입니다. 사람이 직접 쓰는 시스템에서는 이 구분이 잘 드러나지 않습니다. 로그인한 사람이 곧 책임 주체였으니까요. 에이전트가 끼어들면 갈라집니다.
무엇이 문제가 되나
키는 복사됩니다. 위임되고, 환경변수에 남고, 다른 에이전트에게 전달됩니다. 거래 기록에는 "키 A가 호출했다"만 남습니다. 몇 단계 위임을 거친 뒤라면, 그 키를 처음 발급받은 주체가 누구였는지조차 추적이 끊깁니다.
자금세탁방지 체계가 요구하는 것은 거래의 실질 당사자 확인입니다. 에이전트가 거래를 시작하는 환경에서 이 요구를 만족시키려면, 에이전트 뒤의 사람 또는 법인을 알 수 있어야 합니다. 키로는 안 됩니다.
EU AI Act(Regulation (EU) 2024/1689)도 같은 방향을 가리킵니다. 고위험 AI 시스템에 대해 운영자를 식별하고 동작을 기록하도록 요구합니다. 누가 이것을 운영하는가가 규제의 질문입니다.
접근: 새 신뢰 체계를 만들지 않는다
에이전트를 위한 별도의 신원 체계를 만드는 방법도 있습니다. 저희는 그 방향을 택하지 않았습니다. 새 신뢰 체계는 결국 "그 체계를 누가 믿는가"라는 문제를 처음부터 다시 풀어야 합니다.
대신 이미 작동하는 사람·법인의 신원 체계를 에이전트까지 확장합니다. eIDAS 2.0 체계에서 확인된 운영자 신원이 있고, 에이전트 식별자가 있고, 둘을 결속합니다. 에이전트가 거래를 시작할 때 상대는 에이전트 식별자와 함께 "이 에이전트의 운영자는 검증된 누구다"라는 사실을 받습니다.
검증자 입장에서 달라지는 것은 없습니다. 사람의 자격증명을 검증하던 것과 같은 방식으로 검증합니다. 주체가 에이전트일 뿐입니다.
남은 질문들
이 방향이 모든 것을 풀지는 않습니다. 정직하게 남는 질문이 있습니다.
- 위임의 범위를 어떻게 표현할 것인가. 운영자가 에이전트에 준 권한이 "조회만"인지 "송금까지"인지는 신원과 별개의 층위입니다.
- 에이전트가 다른 에이전트를 부를 때 체인을 어떻게 남길 것인가. 다단 위임에서 책임이 희석되지 않게 하는 문제입니다.
- 에이전트 식별자의 수명. 모델이 교체되거나 인스턴스가 재생성될 때 같은 식별자를 유지할지, 새로 발급할지.
저희가 지금 설계하고 있는 부분이고, 출원 후 더 구체적으로 쓸 수 있게 됩니다.
지금 확인해 둘 것
에이전트를 도입하려는 조직이라면, 기술 선택 이전에 답해 둘 질문이 있습니다. 에이전트가 한 거래에 문제가 생겼을 때, 우리 기록만으로 책임 주체를 특정할 수 있는가. 지금 대답이 "키 발급 대장을 찾아봐야 한다"라면, 그 대장이 신원 체계를 대신하고 있는 셈입니다.