계정은 질문 하나만 답한다
AI 에이전트를 배포할 때 흔히 쓰는 방식은 서비스 계정을 만들고 토큰을 붙인 뒤 필요한 도구를 호출하게 하는 것입니다. 이 방식은 소프트웨어가 어떻게 인증할지를 알려줍니다. 하지만 에이전트가 이메일을 보내고, 저장소를 수정하고, 데이터를 바꾸고, 결제를 승인하기 시작하면 다른 질문이 생깁니다.
누가 이 행동을 요청했는가. 어떤 에이전트 인스턴스가 그 요청을 해석했는가. 어떤 권한을 위임받았는가. 그 권한은 이 작업과 자원, 시간 범위에 한정됐는가. 나중에 에이전트가 실제로 무엇을 했는지 증명할 수 있는가.
최근 공개 개발자 논의에서 반복되는 걱정도 자격증명이 없다는 것이 아닙니다. 하나의 자격증명이 사람의 의도, 에이전트의 판단, 최종 행동 사이의 연결을 가려버릴 수 있다는 점입니다.
NIST의 소프트웨어·AI 에이전트 신원 및 권한 부여 개념 문서는 이 연결을 중심에 둡니다. 신원, 인증, 권한 부여, 위임, 감사, 부인 방지, 프롬프트 인젝션을 서로 떨어진 기능이 아니라 연결된 설계 문제로 다룹니다. 사람과 에이전트를 구분하고, 에이전트의 신원을 그것이 대표하는 사람이나 조직에 연결하며, 권한을 관리하고, 권한과 행동을 검증할 수 있는 증거를 남기자는 방향입니다.
AI 신원을 다룬 최근 연구 조사는 연구 관점에서 비슷한 결론에 도달합니다. 기존의 신원 표준은 비교적 안정적인 행위자를 전제로 만들어졌습니다. 반면 에이전트는 시스템 경계를 넘고, 도구를 사용하고, 일을 재위임하고, 장시간 작업 중 행동을 바꿀 수 있습니다. 이 문제는 에이전트에 더 그럴듯한 이름이나 API 키를 하나 더 주는 것으로 해결되지 않습니다.
빠져 있던 중간 단계, 위임
간단한 지시를 생각해 보겠습니다. 배포를 준비하고 고객에게 알리라는 요청입니다. 사람은 계획을 승인하고, 한 에이전트는 저장소를 살피고, 다른 에이전트는 테스트를 실행하며, 별도 도구가 메시지를 보낼 수 있습니다. 모든 단계가 같은 서비스 신원을 사용하면 최종 로그에는 계정이 행동했다는 사실만 남고, 어떤 에이전트가 어떤 결정을 내렸는지와 어떤 사람의 권한이 허용했는지는 사라질 수 있습니다.
의도에서 행동까지 위임의 연결고리가 보일 때 신뢰도 함께 커집니다.
따라서 에이전트 신원은 단순한 이름표 이상이어야 합니다. 적어도 다음 네 요소를 검증 가능한 연결로 묶어야 합니다.
- 작업을 시작한 사람 또는 주체의 의도
- 실제로 작업을 처리한 에이전트 인스턴스와 버전
- 도구·데이터·시간·한계를 포함한 구체적인 권한 범위
- 나중에 확인할 수 있는 행동, 결과, 증거
실무에서 이 기록은 작업 ID, 만료 시각, 위임 단계, 권한 범위가 바뀐 이유도 보존해야 합니다. 하위 에이전트가 조용히 권한을 넓혀서는 안 되고, 범위가 달라지면 새로운 결정이 만들어져야 합니다. 요청, 정책 판단, 도구 실행, 결과를 분리해 남겨야 사고 검토 때 하나의 불투명한 서비스 계정 이벤트만 보게 되지 않습니다.
작게 구현한다면 사람 주체, 에이전트 인스턴스와 버전, 작업 ID, 허용된 도구·자원, 만료 시각, 승인 참조, 도구 호출, 결과를 제한된 스키마로 먼저 정해도 됩니다. 프로토콜은 나중에 발전시킬 수 있지만, 처음부터 연결고리를 잃으면 나중에 복구하기 어렵습니다.
특히 장시간 실행되는 작업은 시작 시점의 승인만으로 끝나지 않습니다. 토큰이 만료됐는지, 사람이 취소했는지, 하위 작업의 범위가 바뀌었는지를 중요한 단계마다 확인해야 합니다. 에이전트 신원은 시작할 때 한 번 발급하는 표식이 아니라 작업이 끝날 때까지 살아 있어야 하는 책임의 연결입니다.
이 구조가 모든 행동을 관료적인 승인 절차로 만든다는 뜻은 아닙니다. 위험이 낮고 되돌릴 수 있는 작업은 미리 정한 범위 안에서 실행할 수 있습니다. 위험이 큰 행동은 새로운 사람의 결정을 요구할 수 있습니다. 중요한 것은 그 차이가 명시적이고 시스템이 확인할 수 있어야 한다는 점입니다.
신원만으로 안전해지지는 않는다
강한 신원이 있어도 잘못된 행동은 할 수 있습니다. 유효한 에이전트가 지시를 오해하거나, 악의적인 도구 설명을 따르거나, 허용된 범위 안에서 손상적인 변경을 만들 수 있습니다. 신원은 행동의 귀속과 권한의 출처를 해결하지만 도구 격리, 최소 권한, 모니터링, 사람의 검토, 신속한 권한 회수를 대신하지는 않습니다.
성숙도에 관한 주의점도 있습니다. NIST 문서는 완성된 범용 표준이 아니라 개념 문서이고, 연구 조사는 완성된 구현 방법이 아니라 아직 남은 공백을 설명합니다. 그렇다고 완벽한 프로토콜을 기다릴 필요는 없습니다. 사람 주체, 에이전트 인스턴스, 위임 범위, 도구 호출, 승인 결정, 결과를 하나의 계정 로그로 뭉개지 않고 별도 필드로 기록하는 것부터 시작할 수 있습니다.
만드는 사람이 던져야 할 질문
질문은 에이전트가 사람처럼 느껴지는지가 아닙니다. 누가 행동했는지, 누구의 권한으로 행동했는지, 어떤 경계 안에 있었는지, 결과가 무엇이었는지를 증거와 함께 답할 수 있는지가 중요합니다.
에이전트가 문서 초안을 넘어 시스템을 바꾸기 시작하면 신원은 권한과 책임을 연결하는 조직이 됩니다. 에이전트 인프라의 다음 단계는 자격증명을 더 발급하는 일이 아닙니다. 위임된 행동을 이해할 수 있고, 제한할 수 있고, 나중에 증명할 수 있게 만드는 일입니다.
