AI 에이전트는 새 직원인데, 우리는 20년 된 출입증을 쥐여줬다

이미지 출처: The Hacker News

한 보안팀이 사내에 도입한 업무 자동화 에이전트의 로그를 들여다보다 이상한 장면을 마주했다고 합니다. 결제 시스템, 인사 DB, 사내 위키, 외부 SaaS까지 — 사람 직원이라면 결재 단계를 몇 번이고 거쳐야 닿을 자원들을, 그 에이전트 하나가 한밤중에 거리낌 없이 드나들고 있었던 거죠. 공격이 있었던 건 아니었습니다. 단지 그 에이전트가 "예전부터 쓰던 서비스 계정"의 권한을 그대로 물려받았을 뿐이었어요. 문제는 바로 거기에 있습니다. 우리는 새로운 종류의 일꾼을 들여놓고는, 사람을 위해 설계한 20년 된 출입 체계를 그대로 끼워 맞추고 있는 겁니다.

핵심 요약

• AI 에이전트는 사람이 아니라 '기계 신원(NHI)'인데, 대부분 사람용으로 만든 낡은 권한·인증 체계를 그대로 물려받아 과잉 권한을 떠안음.
• 정적 비밀키·광범위한 서비스 계정·장수 OAuth 토큰을 에이전트가 상속하면, 한 번의 프롬프트 인젝션이나 탈취가 곧바로 합법적 자격증명을 쥔 침해로 번짐.
• 방어의 핵심은 에이전트 신원의 가시화(인벤토리)·최소권한·단기/임시 자격증명·행위 기반 이상탐지·즉시 차단 스위치임.

왜 '낡은 인프라'가 위협이 되는가

기존 IAM(신원·접근관리)은 철저히 사람을 가정하고 만들어졌습니다. 근무 시간에, 한 번에 한 작업을, 가끔 비밀번호를 틀리고, MFA 푸시를 누르는 존재 말입니다. 그런데 에이전트는 그 전제를 전부 깨버립니다. 초당 수십 번 API를 호출하고, 도구를 도구로 연쇄 호출하며, 24시간 멈추지 않죠. 이 신참을 기존 체계에 욱여넣다 보니 다음과 같은 구멍이 생깁니다.

• 정적 비밀키 의존 — 코드나 설정파일에 박힌 장수 API 키·토큰을 에이전트가 그대로 사용함. 한 번 새면 만료도 회수도 어려움.
• 과잉 권한 서비스 계정 상속 — "일단 막히면 곤란하니" 넓게 열어둔 계정을 물려받아, 실제 업무에 필요 없는 자원까지 손이 닿음.
• 장수 OAuth 토큰 — 사람 세션을 가정해 발급한 토큰을 자동화가 무기한 재사용. 누가 언제 무엇에 썼는지 추적이 흐려짐.
• 식별 불가능성 — 로그에 사람 계정처럼 찍혀, '이건 봇이 한 행동'이라는 사실 자체가 드러나지 않음.

에이전트가 위험을 증폭하는 지점

여기서 한 발 더 들어가 볼게요. 에이전트가 무서운 건 '스스로 판단해 행동을 이어간다'는 점입니다. 외부에서 들어온 문서나 웹페이지에 악의적 지시가 숨어 있으면(이른바 프롬프트 인젝션), 에이전트는 그걸 정당한 명령으로 오해하고 자기가 쥔 진짜 자격증명으로 실제 행동을 해버릴 수 있습니다. 개념만 짚자면, 공격자가 직접 비밀번호를 훔칠 필요가 없어지는 거예요. 이미 강력한 권한을 쥔 에이전트를 '설득'하기만 하면 되니까요. 게다가 도구가 도구를 부르는 연쇄 구조라, 작은 오작동 하나가 여러 시스템으로 빠르게 번집니다. 낡은 인프라가 준 과잉 권한 위에 에이전트의 자율성과 속도가 얹히면, 사고의 폭발 반경이 단숨에 커지는 셈입니다.

그래서 어떻게 탐지하고 완화하나

다행히 막을 길은 분명합니다. 핵심은 에이전트를 '사람의 연장'이 아니라 별도의 신원 클래스로 다루는 거예요. 개인적으로는 다음 순서로 점검해보길 추천합니다.

• 먼저 인벤토리부터 — 사내에 돌아가는 에이전트와 그것들이 쥔 키·토큰·계정을 전부 목록화함. 안 보이는 신원은 지킬 수 없음.
• 최소권한 재설계 — 상속받은 넓은 권한을 끊고, 그 에이전트가 실제로 필요한 자원·동작만 허용함. 거부를 기본값으로 둠.
• 단기·임시 자격증명 — 정적 비밀키를 걷어내고, 작업 시점에만 발급돼 곧 만료되는(JIT) 짧은 토큰으로 대체함. 새도 수명이 짧아 피해가 제한됨.
• 행위 기준선과 이상탐지 — '이 에이전트의 정상 패턴'을 학습해두고, 한밤중 대량 조회·평소 안 건드리던 시스템 접근 같은 이탈을 경보로 잡음.
• 감사 가능한 로그 — 모든 행동이 '어느 에이전트가, 어떤 권한으로, 무엇을' 했는지로 남게 함. 사람 계정 뒤에 숨지 못하게.
• 즉시 차단 스위치 — 의심 정황이 보이면 해당 신원의 토큰을 한 번에 회수·격리할 수 있는 경로를 미리 만들어 둠.

외부 입력을 신뢰 경계 밖으로 다루고, 민감한 동작 앞에는 사람 승인 단계를 한 겹 끼워두는 것도 프롬프트 인젝션의 피해를 줄이는 현실적인 장치입니다.

마무리

AI 에이전트 도입을 멈출 필요는 없습니다. 다만 새 직원에게 회사 마스터키를 통째로 쥐여주지는 않듯이, 에이전트에게도 그만큼의 절차와 경계가 필요할 뿐입니다. 결국 화근은 AI 자체보다, 그 AI를 떠받치는 낡은 권한 체계인 경우가 많거든요. 오늘 당장 우리 환경의 에이전트 목록과 그것들이 쥔 토큰부터 한번 펼쳐보면 어떨까요. 막연했던 위험이 의외로 또렷하게 보일 겁니다. 점검해보고 막막한 지점이 있으면 댓글로 같이 풀어봐요.