.svg)
%201.svg)
%201.svg){kind=icon}
담당자가 프로모션 코드를 발송해 드립니다.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
WhaTap AI를 경험해 보세요.
AI 에이전트 감사 로그, 사람과 에이전트 구분하기
사내 도구에 에이전트를 붙이는 팀이 늘고 있습니다. 이슈 트래커에서 티켓을 정리하게 하거나, 사내 위키를 검색해 답을 만들게 하거나, 운영 데이터베이스에 조회 쿼리를 실행하게 하는 식입니다. 토큰을 연결하는 방법은 대개 비슷합니다. 담당자가 자기 계정에서 토큰을 발급해 에이전트 설정에 넣어 둡니다. 이 방식이 몇 달 뒤 AI 에이전트 감사 로그에서 어떻게 문제가 되는지부터 봅니다.
담당자 토큰을 그대로 넣는 방식은 당장 잘 동작합니다. 고칠 이유가 없으니 임시로 넣은 토큰이 그대로 굳습니다. 문제는 몇 달 뒤 감사 로그를 열었을 때 드러납니다. 기록에는 담당자 이름만 찍혀 있고, 그중 어느 것이 사람이 직접 한 일이고 어느 것이 에이전트가 한 일인지 구분할 방법이 없습니다.
에이전트 신원은 에이전트가 시스템에 자기 자신으로 인증하는 수단이고, 감사 로그는 그 신원으로 무엇을 했는지 남긴 기록입니다. 에이전트 신원과 감사 로그는 한 쌍입니다. 신원을 주지 않으면 로그에 남길 주어가 없습니다. 반대로 로그를 남기지 않으면 신원을 발급한 의미가 사라집니다.
AI 에이전트에 사용자 토큰을 그대로 주면 생기는 두 가지
에이전트에 사람의 토큰을 그대로 넘기는 구조에서는 성격이 다른 문제가 둘 생깁니다. 기록에서 하나, 권한에서 하나입니다.
첫째, 사람이 한 일과 에이전트가 한 일이 구분되지 않습니다. 감사 로그에 남는 주체가 담당자 하나뿐이면, 담당자가 직접 한 일과 그 토큰을 받은 에이전트가 한 일이 같은 이름으로 쌓입니다. 사고가 났을 때 그 동작을 사람이 시작했는지 에이전트가 시작했는지 가릴 수 없고, 내부 감사나 규제 대응에서 흔히 요구하는 "책임 있는 주체"를 증명할 수도 없습니다.
기록이 비어 있는 정도가 아니라 사실과 반대로 남는 경우도 생깁니다. 에이전트가 지우지 말아야 할 것을 지웠는데 로그에는 담당자가 지운 것으로 남습니다.
둘째, 권한이 작업 범위를 넘습니다. 그 토큰으로는 담당자가 할 수 있는 모든 일을 할 수 있습니다. 티켓을 읽으라고 붙여 준 에이전트가 티켓을 지울 수도 있습니다. 조회만 시켰는데 쓰기까지 열려 있습니다. 담당자가 그 작업에 허락한 범위와 토큰으로 실제 할 수 있는 범위가 처음부터 어긋나 있습니다.
프롬프트 인젝션 공격의 피해가 커지는 것도 에이전트가 쥔 권한이 넓기 때문입니다. 공격자가 에이전트를 속여 의도하지 않은 동작을 시키더라도, 에이전트가 가진 권한이 작업에 필요한 만큼으로 좁혀져 있으면 피해가 허락된 범위 안에서 멈춥니다. 사람의 토큰을 그대로 가지고 있으면 사람이 할 수 있는 모든 일이 피해 범위가 됩니다.
에이전트 신원 인증과 권한 위임을 나누는 설계
에이전트의 신원과 권한을 관리하는 일(AI agent IAM)을 두고, 여러 표준이 신원과 권한 위임을 나눠서 다룹니다. 에이전트에는 자기 자신의 고정된 신원을 주고, 누구를 대신해 이 작업을 하는지는 작업마다 따로 실어 보냅니다.
이렇게 두면 로그에 주어가 둘 남습니다. 어느 에이전트가 움직였는지와, 그 권한이 누구에게서 왔는지입니다. 이렇게 나누면 기록의 문제와 권한의 문제가 각각 풀립니다. 에이전트 신원으로 행위자를 특정하고, 위임에 실린 만큼으로 권한 범위를 제한합니다.
티켓 정리를 맡은 에이전트를 예로 들면 이렇습니다.
표준은 이미 마련돼 있습니다. OAuth 2.0 토큰 교환(OAuth 2.0 Token Exchange, RFC 8693)이 그 바탕입니다. RFC 8693은 한 토큰을 다른 토큰으로 바꾸면서 행위 주체(subject)와 대리 주체(actor)를 따로 표현할 수 있게 정의합니다. 앞의 티켓 정리 예시에서 "김 아무개의 권한으로 support-agent가 움직였다"를 토큰 안에 담을 수 있다는 뜻입니다.
다른 조직의 시스템을 호출하는 경우(신뢰 도메인 간 호출)는 IETF OAuth 워킹그룹이 별도로 표준화하고 있습니다. OAuth Identity and Authorization Chaining 문서로, 2026년 9월 현재 draft-17(7월 19일자)이 IETF 기술 운영 그룹(IESG)의 검토를 통과해 RFC 발행 절차에 들어가 있습니다. 아직 RFC는 아니고 인터넷 드래프트 단계입니다.
에이전트가 외부 도구를 호출하는 구간에서는 Model Context Protocol(MCP)의 인증 규격이 같은 원칙을 더 강하게 명시합니다. MCP 서버는 OAuth 리소스 서버로 동작하고, 받은 토큰이 자기 자신을 대상으로 발급된 것인지 반드시 확인해야 합니다. 받은 토큰을 그대로 다음 API에 넘기는 것은 명시적으로 금지돼 있습니다.
MCP 서버는 MCP 클라이언트에게서 받은 토큰을 통과시켜서는 안 된다. 상위 API에 요청할 때 쓰는 액세스 토큰은 상위 인증 서버가 발급한 별도의 토큰이다. (MCP 인증 규격)
금지의 이유는 혼동된 대리자(confused deputy) 문제입니다. 중계 서버가 남의 토큰을 그대로 넘기면, 그 뒤의 API는 앞단에서 검증이 끝난 요청으로 처리합니다. 검증하지 않은 요청을 신뢰하는 구조여서, 로그를 아무리 잘 남겨도 어느 지점에서 권한이 새어 나갔는지 추적할 수 없습니다.
AI 에이전트 감사 로그에 무엇을 남겨야 하는가
로그 항목을 정할 때 기준은 하나입니다. 몇 달 뒤에 로그 한 줄만 보고 "누가 무엇을 왜 했는가"를 재구성할 수 있는가. 최소한 다음이 필요합니다.
agent_version과 승인 기록이 빠지기 쉬운 항목입니다. 몇 달 뒤에 필요한 건 "support-agent가 지웠다"가 아니라 "support-agent v1.7.3이 김 아무개의 요청으로 실행했고, 삭제 직전 박 아무개가 승인했다"입니다. 버전이 빠지면 특정 배포에서만 나던 문제를 좁힐 방법이 없습니다. 승인 기록이 없으면 통제 절차가 실제로 동작했는지 증명하지 못합니다.
실제 로그 한 줄은 이렇습니다. 필드 이름은 쓰는 도구에 맞추면 됩니다.
{
"timestamp": "2026-09-15T04:12:33Z",
"agent_id": "support-agent",
"agent_version": "1.7.3",
"user_id": "hjkim@example.com",
"delegated_by": "hjkim@example.com",
"scope": "tickets.write",
"tool": "issue_tracker",
"action": "delete_comment",
"resource": "PROJ-1421#c9",
"task_id": "task-1832",
"trace_id": "8a31c7e0",
"approved_by":
"spark@example.com",
"status": "success"
}agent_id가 움직인 주체이고 delegated_by가 권한의 출처입니다. agent_id와 delegated_by가 같은 줄에 있어야 "에이전트가 한 일인데 권한은 김 아무개에게서 왔다"가 한눈에 읽힙니다.
사용자 요청만 남겨서는 부족합니다. 사람이 한 번 시킨 작업이 에이전트 안에서는 수십 번의 도구 호출로 나뉩니다. 요청 단위로만 남기면 "문서를 정리해 달라"는 한 줄과 그 과정에서 일어난 삭제 사이의 연결이 끊깁니다.
그렇다고 도구 호출만 남기면 반대 문제가 생깁니다. 삭제가 있었다는 건 알지만 누가 왜 시켰는지가 안 보입니다. 사용자 요청과 도구 호출을 함께 남기되, 하나의 작업 식별자로 서로를 이어 둡니다.
task_id 사용자가 시킨 작업 하나
└─ run_id 에이전트가 그 작업을 수행한 실행 단위
├─ tool_call 001 위키 검색
├─ tool_call 002 티켓 조회
└─ tool_call 003 댓글 삭제 ← 외부 시스템이 실제로 바뀐 지점외부 시스템을 바꾼 호출은 빠뜨리지 않습니다. 재시도나 병렬 실행이 있으면 같은 작업에 실행 단위가 여럿 달릴 수 있어서, 작업과 도구 호출 사이에 실행 단위를 한 단계 더 둡니다.
로그를 어디에서 남기느냐에 따라 빠지는 경로가 달라집니다.
애플리케이션 코드에 직접 심는 방식. 에이전트가 무엇을 하려는지 가장 가까이에서 알 수 있어 맥락이 풍부합니다. 대신 에이전트마다 따로 구현해야 하고, 새 에이전트를 붙일 때 빠뜨리기 쉽습니다.
에이전트와 도구 사이를 지나는 계층에서 남기는 방식. AI 게이트웨이나 추적 도구가 그 계층에 해당합니다. 기록이 한곳에 모이고 에이전트 코드를 고치지 않아도 되지만, 그 계층을 우회하는 경로가 있으면 그쪽은 기록에 안 잡힙니다.
실무에서는 두 방식을 함께 쓰는 경우가 많습니다. 게이트웨이 같은 중계 계층에서 호출 흐름을 기본으로 모으고, 판단 근거처럼 애플리케이션만 아는 정보는 코드에서 덧붙이는 식입니다. 어느 쪽을 택하든 기록되지 않는 경로가 어디인지부터 짚어 두는 편이 낫습니다. 빠진 경로를 모르면 로그가 있다는 사실만 믿고 넘어갑니다.
에이전트 접근 통제를 설계할 때 생기는 문제
원칙은 단순한데 실제 적용에서 막히는 대목이 있습니다.
토큰 수명과 작업 시간이 어긋납니다. 유출 피해를 줄이려면 토큰 만료 시간을 짧게 두는 편이 맞지만, 에이전트 작업은 사람보다 오래 걸리는 경우가 있습니다. 문서 수백 건을 읽는 작업이 토큰 만료보다 길어지면 중간에 끊깁니다. 자동 갱신을 넣으면 해결되지만 갱신 권한 자체가 새로 지켜야 할 대상이 됩니다.
권한을 미리 좁히기 어렵습니다. 필요한 만큼만 주는 최소 권한(least privilege)이 원칙이지만, 에이전트는 어떤 도구를 쓸지 실행 전에 확정하지 못하는 경우가 많습니다. 여유 있게 열어 두면 최소 권한이라는 원칙이 사실상 사라집니다. 반대로 좁게 설정하면 작업이 중간에 실패합니다. 실무에서는 자주 쓰는 경로만 미리 허용하고 나머지는 승인을 거치게 하는 절충을 씁니다.
사람 승인을 어디에 둘지가 까다롭습니다. 승인을 촘촘히 걸수록 에이전트를 쓰는 의미가 줄어듭니다. 그렇다고 승인 없이 두면 취소가 안 되는 동작까지 사람의 확인 없이 실행됩니다. 삭제, 외부 전송, 권한 변경처럼 취소가 어려운 것만 골라 거는 방식이 현실적입니다.
신원이 늘어나는 속도도 변수입니다. 사람 계정은 입사와 퇴사에 맞춰 늘고 줄지만, 에이전트 신원은 배포할 때마다 생깁니다. 만드는 절차만 있고 회수하는 절차가 없으면 쓰지 않는 신원이 쌓입니다. 발급 절차를 만들 때 폐기 절차도 같이 만들어 둡니다.
에이전트 신원은 사람이 아닌 주체에 발급하는 계정이라 비인간 신원(NHI, Non-Human Identity)으로 분류합니다. 서비스 계정, API 키, 워크로드 신원이 같은 범주입니다. 이미 비인간 신원 관리 체계를 갖춘 조직이라면 에이전트를 아주 새로운 것으로 다루기보다 기존 관리 절차를 넓히는 편이 빠릅니다. 발급·회수·주기적 점검 절차를 그대로 쓸 수 있습니다.
다만 한 가지가 다릅니다. 기존 서비스 계정은 정해진 일만 반복하지만, 에이전트는 무엇을 호출할지 실행 중에 정합니다. 그래서 누구를 대신해 움직이는가라는 항목이 하나 더 늘어납니다. 에이전트마다 대신하는 사람이 달라지기 때문에 신원과 위임을 따로 둡니다.
AI 에이전트 권한 점검 체크리스트 여덟 가지
설계를 바꾸기 전에 현재 구조부터 점검합니다. 아래 여덟 항목을 짚어 보면 지금 어디쯤인지 드러납니다.
- 개인 API 키나 사용자 OAuth 토큰을 에이전트가 그대로 쓰고 있는가
- 로그에서 사용자와 에이전트를 각각 식별할 수 있는가
- 에이전트마다 별도 신원이 있는가, 아니면 하나를 공유하는가
- 토큰 권한 범위가 실제 작업 범위보다 넓지 않은가
- 누가 권한을 위임했는지가 기록에 남는가
- 외부 시스템을 바꾼 도구 호출까지 추적되는가
- 삭제, 외부 전송, 권한 변경에 승인 기록이 남는가
- 폐기한 에이전트의 자격 증명도 함께 회수되는가
체크가 안 되는 항목이 있어도 당장 전부 고칠 필요는 없습니다. 되돌리기 어려운 동작을 하는 에이전트부터 순서를 잡으면 됩니다. 조회만 하는 에이전트와 삭제 권한이 있는 에이전트는 급한 정도가 다릅니다.
감사 로그와 실행 추적을 함께 봐야 하는 이유
실제 운영에서는 기록이 한 종류 더 필요합니다.
인증 시스템에는 에이전트가 어떤 권한으로 접근했는지가 남습니다. 그런데 사용자 요청 하나가 어떤 판단을 거쳐 몇 번의 도구 호출로 이어졌는지, 중간에 무엇이 실패해 재시도가 일어났는지는 인증 로그에는 남지 않습니다. 실행 과정은 호출 흐름을 따라가는 에이전트 옵저버빌리티 추적에서만 보입니다.
사고 경위를 따져 볼 때는 두 기록이 서로를 보완합니다. 감사 로그에는 누가 무엇을 했는지가 있고, 실행 추적에는 그 동작에 이르기까지의 과정이 있습니다. 삭제가 일어난 사실은 감사 로그에 남지만, 그 앞에서 검색 결과를 잘못 읽었다는 건 추적에만 남습니다. 신원과 권한 기록을 실행 추적과 같은 식별자로 쓰면 감사 로그와 실행 추적을 오가며 볼 수 있습니다. 로그 항목 표에 task_id와 trace_id를 함께 넣은 이유입니다.
자주 묻는 질문
서비스 계정 하나를 여러 에이전트가 같이 쓰면 안 되나요
동작은 하지만 사용자 토큰을 그대로 쓸 때와 같은 문제가 생깁니다. 로그의 주체가 다시 하나로 합쳐져서 어느 에이전트가 한 일인지 구분되지 않습니다. 계정을 나누기 어렵다면 최소한 로그에 에이전트 식별자를 따로 실어야 합니다.
이미 SIEM을 쓰고 있는데 그대로 넣으면 되나요
수집은 됩니다. 다만 보안 이벤트를 모아 분석하는 SIEM(Security Information and Event Management)의 기존 규칙은 사람 계정을 전제로 짜여 있는 경우가 많습니다. 짧은 시간에 수백 번 호출하는 패턴은 사람이면 이상 징후지만 에이전트에게는 정상입니다. 에이전트 신원에는 다른 기준선을 적용해야 오탐이 줄어듭니다.
프롬프트 인젝션을 당하면 신원을 나눈 게 무슨 소용인가요
공격 자체를 막지는 못합니다. 대신 피해 범위가 그 에이전트에 허락된 만큼으로 제한되고, 사후에 어느 에이전트가 무엇을 했는지 가려낼 수 있습니다. 다만 위임받은 범위 안에서 벌어지는 오작동은 그대로 통과하므로, 되돌리기 어려운 동작에는 승인을 따로 걸어 둡니다.
내부망에서만 도는 에이전트도 감사 로그가 필요한가요
망 경계와 행위자 기록은 다른 문제입니다. 외부에서 접근할 수 없다고 해서 내부에서 누가 무엇을 했는지가 남는 것은 아닙니다.
마치며
에이전트에 사람의 토큰을 그대로 넘기는 방식은 빠르게 동작하지만, 감사 로그에서 행위자를 잃고 권한이 필요 이상으로 넓어집니다. 신원은 에이전트에 주고 위임은 작업마다 따로 싣는 구조여야 로그에 주어가 남습니다.
지금 당장 큰 설계를 바꾸기 어렵다면 점검부터 해 보셔도 됩니다. 지금 운영 중인 에이전트가 누구의 토큰으로 움직이는지, 그 동작이 로그에서 사람과 구분되는지 두 가지만 알아도 어디부터 손댈지 드러납니다.
실행 과정 쪽 기록이 아직 없다면 와탭 AI Agent Observability에서 에이전트가 어떤 순서로 LLM을 호출했는지와 호출별 LLM 토큰·비용을 확인할 수 있습니다. 15일 무료로 시작하기
더 읽을거리
