공격 표면이 넓어지는 건 AI 에이전트를 도입해서가 아니라, 어떻게 연결하느냐의 문제입니다. 그리고 얼마든지 피할 수 있습니다.
올해 초 서울에서 열린 Agentic AI Security Summit에서 AI 에이전트와 보안 사이의 이야기를 했는데, 청중석에서는 같은 질문이 계속 나왔습니다: AI 에이전트를 도입하면 공격 표면이 넓어지는 게 당연한 걸까요? 이 문제를 풀 실행 제어 레이어를 몇 년째 만들어 온 입장에서, 제 답은 '아니오'입니다. 그 이유를 짚어 보겠습니다.
제가 반복해서 보는 패턴은 이렇습니다. 프로덕션에 AI 에이전트를 붙일 때, 대개 요청하지도 않은 네 가지가 딸려 옵니다. 새 아이덴티티, 새 키, 새 상시 자격증명, 그리고 아무도 통제하지 않는 새 인바운드 경로. 이 중 어느 것도 에이전트에 딸려오는 것이 아닙니다. 전부 '어떻게 연결했느냐'에서 생긴 것이고, 대부분의 팀은 이걸 AI 도입에 따르는 불가피한 비용으로 받아들입니다.
그렇지 않습니다. 공격 표면이 넓어지는 건 AI 에이전트 때문이 아니라, 그 에이전트를 어떻게 연결했느냐에서 비롯됩니다. 사람이 이미 쓰는 통제된 경로에 에이전트를 그대로 도입하면, 보안 문제 없이 역량만 더할 수 있습니다.
AI 에이전트는 공격 표면을 넓힐까요?
요약: 본질적으로는 아닙니다. 노출은 에이전트 자체가 아니라 대부분의 팀이 에이전트를 연결하는 방식(새 아이덴티티, 상시 키, 새 인바운드 경로)에서 옵니다. 이미 통제하고 있는 접근 경로로 연결하면, 그 경로에 새로 더해지는 공격 표면은 없습니다.
엔지니어가 인프라를 운영할 에이전트를 붙일 때(장애 대응 봇, 배포 봇, 셸 접근을 가진 코딩 에이전트 등), 가장 빠른 길은 자격증명을 쥐여 주는 것입니다. 서비스 계정 하나, 시크릿 매니저에 넣어 둔 SSH 키 하나, 스코프를 넓게 잡은 API 토큰 하나. 스코프를 좁히는 건 번거롭고, 에이전트는 '이것저것 할 수 있어야' 하니까요.
이 하나하나가 새로 생긴 공격 표적이고, 좀처럼 사라지지 않습니다. 게다가 사람과 달리 에이전트의 자격증명은 자동화 속에 남습니다. 파이프라인에 복사되고, 설정에 남고, 잠들지도 오프보딩되지도 않는 프로세스가 남습니다. 더 나쁜 건 증식한다는 점입니다. 에이전트 템플릿 하나가 똑같은 세션 수백 개를 띄우고, 각각이 같은 상시 자격증명을 지닙니다. 사용자를 하나 더한 게 아니라, 아무도 실시간으로 지켜보지 않는 상시 권한을 대규모로 더한 셈입니다.
이미 대다수가 이렇게 하고 있습니다
요약: 대다수 조직은 자기 에이전트조차 못 봅니다. 82%가 미파악 AI 에이전트가 있다고 답했고, 머신 아이덴티티는 클라우드 네이티브·DevOps 환경에서 사람보다 최대 144배 많습니다. 대부분의 팀이 믿는 통제 장치는 에이전트 문제를 보지 못합니다. 에이전트가 하는 모든 행동이 인가된 것이기 때문입니다.
머신 아이덴티티는 이미 사람을 크게 앞지릅니다. 일부 집계는 클라우드 네이티브·DevOps 환경에서 그 비율을 최대 144대 1로 봅니다. 그런데 대부분의 팀은 첫 프로덕션 에이전트를 그 145번째로 만들어 버립니다. 토큰 하나, 키 하나, 유출되거나 잊히기 좋은 계정 하나가 그렇게 또 늘어납니다. 그리고 대부분은 이걸 통제하지 못합니다. 78%가 AI 아이덴티티를 만들거나 없애는 공식 정책이 없고, 92%는 기존 IAM으로 이 위험을 관리할 수 있다고 확신하지 못합니다.
규모는 이미 감시할 수 있는 수준을 넘어섰습니다. 82%의 조직이 자기 환경에 미파악 AI 에이전트가 있고, 65%는 지난 1년간 AI 에이전트 관련 사고를 겪었습니다. RSAC 2026에서는 에이전트 AI가 가장 주목받는 신규 공격 벡터로 꼽혔고, 응답자의 60%는 오작동하는 에이전트를 확실히 종료할 수 없다고 답했습니다. 63%는 에이전트가 무엇을 할 수 있는지를 강제할 수 없다고 했습니다.
그 상시 자격증명 중 하나가 유출되는 순간, 시간은 우리 편이 아닙니다. 유출된 자격증명은 머신 속도로 스캔되고, 권한이 상승되고, 데이터가 빠져나갑니다. 반면 침해가 발견되기까지는 평균 194일이 걸립니다(IBM Cost of a Data Breach 2024). '읽기 전용'이라고 안심할 수도 없습니다. 읽기 접근만으로도 시크릿, 설정, 토폴로지가 새어 나갑니다.
이게 접근이 아니라 실행의 문제인 까닭은 이렇습니다. 보안팀이 지금 기록하고 있는 에이전트 침해 사례를 보면, 일련의 동작 하나하나가 모두 인가된 것입니다. 에이전트는 진짜 자격증명으로 로그인하고, 진짜 명령을 실행합니다. IAM도, EDR도, WAF도, VPN도 걸러 낼 악성 신호가 없습니다. 이들이 보기엔 악성 행위가 일어나지 않았으니까요. 보안 장치는 제대로 작동했습니다. 그런데도 데이터는 빠져나갔습니다. (이런 사고를 자세히 다룬 적이 있습니다. 관문은 세션을 인증했고, 시크릿 볼트는 요청받은 값을 내주었지만, 데이터베이스는 그대로 통째로 빠져나갔습니다.)
그 위험은 대체 어디서 오는 걸까요?
요약: 에이전트를 이미 통제하는 경로 밖에, 자체 아이덴티티·키·인바운드 경로를 가진 새 권한 주체로 붙이는 데서 옵니다. 사람과 같은 경로에 태우면 '에이전트를 더하는 것'이 '표면을 더하는 것'이 아니게 됩니다.
위험은 에이전트가 똑똑해서 생기는 게 아닙니다. 이미 통제하고 있는 경로 밖에, 자기만의 아이덴티티와 키, 아무도 지켜보지 않는 진입로를 가진 새 권한 주체로 에이전트를 갖다 붙이기 때문에 생깁니다.
그래서 해법은 새 표면을 감시할 새 제품이 아니라, 새 표면을 아예 만들지 않는 것입니다. 에이전트를 사람과 똑같은 경로에 태우면(같은 아이덴티티 모델, 같은 접근 결정, 같은 감사 기록), '에이전트를 더하는 것'은 더 이상 '위험을 더하는 것'이 아닙니다. 이미 돌리고 있는 파이프라인에 세션 하나가 추가될 뿐입니다.
구체적으로는 이렇습니다. 에이전트가 무언가를 해야 할 때, 키를 받는 게 아니라 스코프가 정해진 세션을 열고 승인을 기다립니다.
$ alpacon work-session create \
--requester-type agent \
--purpose "fix nginx 501" \
--server staging-web \
--scope command,sudo \
--sudo "systemctl reload nginx" \
--expires-in 1h
✓ session created · pending approval
✓ scope: staging-web · [command, sudo]
✓ audit: streaming →
서버 하나, 미리 선언한 sudo 명령 하나, 1시간 상한. 이 세션은 에이전트가 연 것으로 표시돼 있어서, 스스로 활성화되지 않고 사람의 승인을 거칩니다. 모든 행동은 감사 로그로 실시간 기록되고, 1시간이 지나면 접근은 사라집니다. SSH 키가 오간 적도 없고, 그 에이전트와 관련된 어떤 것도 작업이 끝나면 함께 사라집니다. Alpacon은 바로 이 발상에서 출발합니다.
공격 표면을 늘리지 않고 에이전트를 더하려면?
요약: 사람의 접근 경로와 네 가지(아이덴티티, 키, 네트워크 방향, 권한)를 똑같이 유지하면, 에이전트는 새 구멍을 내는 대신 기존 거버넌스를 그대로 물려받습니다.
에이전트가 사람의 경로에 올라탈 때 네 가지가 그대로 유지됩니다. 바로 그게 핵심입니다.
에이전트는 새 아이덴티티가 아닙니다. Alpacon에서는 인프라에 대한 모든 행동이 Work Session에 속합니다. 세션 밖 경로란 없습니다. 에이전트는 자기만의 아이덴티티 영역을 따로 두지 않고, 이미 존재하는 사용자 또는 애플리케이션 아이덴티티로 동작합니다. 다른 점은 사람이 아니라 에이전트임을 표시하는 플래그 하나뿐입니다. 에이전트를 위한 별도의 접근 경로, 자격증명 저장소, 감사 스트림을 세우지 않습니다. 에이전트의 피해 반경은 그 세션이 선언한 범위로 한정됩니다.
훔칠 새 키가 없습니다. Alpacon은 아이덴티티를 시스템에 직접 묶습니다. Alpacon IAM 아이덴티티가 곧 시스템 아이덴티티이고, 첫 접근 시 프로비저닝되며, 아이덴티티가 삭제되면 함께 사라집니다. 에이전트용으로 볼트에 넣어 둔, 오래 유지되는 SSH 키 자체가 없으니 거기서 빼낼 것도 없습니다. (CI/CD용 서비스 토큰은 예외입니다. 오래 유지되는 대신, 그 토큰이 할 수 있는 일이 전부 사전에 세분화된 접근 목록으로 정의돼 있어야 합니다. 어느 서버, 어느 스코프, 어느 sudo 명령인지까지요. 즉 이건 접근 경로에서 상시 키와 볼트 시크릿을 없앤다는 뜻이지, 자격증명이 하나도 없다는 뜻은 아닙니다.)
새 인바운드 포트가 없습니다. 에이전트가 늘어도 공격 표면이 그대로인 건 바로 이 방식 덕분입니다. 에이전트에게 인프라로 들어올 길을 열어 주는 흔한 방식은 포트를 하나 여는 것입니다. SSH 22번, 데이터베이스 포트, 쿠버네티스 API를 열고, 그걸 대개 인터넷에 곧장 노출하죠. Alpacon은 이를 뒤집습니다. 각 호스트의 Alpamon 에이전트가 컨트롤 플레인으로 아웃바운드 TLS 연결을 겁니다. 그래서 호스트에서 인바운드 트래픽을 기다리는 건 아무것도 없고, 셸이든 파일이든 포트(데이터베이스, API)든 그 하나의 아웃바운드 채널을 타고 스코프 터널로 연결됩니다. 에이전트가 아무리 늘어도 호스트는 닫힌 채로 있고, 공격 표면은 커지지 않고 그대로입니다.
물려받을 상시 권한이 없습니다. Alpacon에서 권한은 결코 상시적이지 않습니다. 권한은 행동할 때마다 관찰 가능한 것들, 즉 세션이 선언한 스코프, 평가된 위험, 입증된 사람의 존재를 근거로 매번 새로 만들어집니다. 행위자가 스스로 누구라고 하든, 그걸 근거로 상시 부여되는 일은 없습니다. 스코프에 sudo가 없는 세션은 슈퍼유저라도 프롬프트가 뜨기도 전에 sudo가 거부됩니다. 에이전트 모드 세션은 생성 시 사람의 승인을 받아야 하고, 토큰을 아무리 많이 쥐어도 스스로 권한 상승을 승인할 수 없습니다. (정직하게 짚자면, 슈퍼유저 API 토큰을 포함한 '모든' 자격증명 유형에서 상시 권한을 닫는 작업은 아직 진행 중이며, 오늘 전면적으로 완료된 것은 아닙니다.)
한 가지는 분명히 해 두겠습니다. 이것은 에이전트가 우리 서버로 가는 경로를 통제하는 것이지, 에이전트 자체의 런타임을 통제하는 것이 아닙니다. 프롬프트 인젝션이나 모델 자체의 침해는 실재하는 위험이지만, 그것은 다른 문제입니다. 이 설계가 보장하는 건 침해된 에이전트라 해도 우리가 보고, 스코프를 정하고, 끊을 수 있는 통제된 경로 외에는 인프라로 들어오는 새 권한 경로를 얻지 못한다는 점입니다.
에이전트를 연결하기 전, 스스로에게 던질 네 가지 질문
요약: 어떤 에이전트든(Alpacon이든 아니든) 아이덴티티, 키, 네트워크 방향, 권한 네 가지를 점검하세요. 각 답이 '통제되는 쪽'에 해당하면 공격 표면이 아니라 역량을 더한 것입니다.
Alpacon이 없어도 지금 쓰는 구성을 스스로 점검해 볼 수 있습니다. 다음 에이전트를 프로덕션에 붙이기 전에 이렇게 물어보세요.
- 아이덴티티: 에이전트가 자체 아이덴티티와 자격증명 저장소를 새로 갖나요, 아니면 이미 통제하고 있는 아이덴티티 아래에서 동작하나요?
- 키: 어딘가에 오래 남는 키나 시크릿을 둬야 하나요, 아니면 접근이 키 없이 아이덴티티에 묶여 세션마다 프로비저닝되나요?
- 네트워크: 연결하면서 새 인바운드 포트를 여나요, 아니면 아웃바운드 전용이라 에이전트가 몇 대가 붙든 호스트가 닫힌 채로 있나요?
- 권한: 여러 서버에 걸친 상시 접근을 쥐나요, 아니면 작업마다 스코프가 정해지고 만료되는 승인된 범위를 받나요?
각 질문의 답이 전자에 해당하면 공격 표면을 더한 것이고, 후자라면 역량을 더한 것입니다. Alpacon은 기본값으로 모든 답이 후자가 되도록 설계됐고, 거기까지 가는 건 스택을 새로 짜는 게 아니라 호스트에 가벼운 에이전트 하나를 얹는 데서 시작합니다.
대부분의 팀이 프로덕션 에이전트를 두고 던지는 질문은 '이 새 공격 표면을 어떻게 모니터링하지?'입니다. 더 나은 질문은 '왜 새 표면을 만들었지?'입니다. AI 역량을 더하는 것과 보안 노출을 더하는 것은 별개의 결정입니다. 첫 번째만 결정하면 됩니다.
공격 표면을 넓히지 않는 건 첫 번째 질문, 즉 '에이전트를 어떻게 연결하는가'일 뿐입니다. 그다음은 일단 들어온 에이전트가 '무엇을 하게 둘 것인가'이고요. 유효한 세션이라도 애초에 스코프에 없던 곳에서 명령을 실행해 버리면 아무 소용이 없으니까요. 그리고 마지막은, 누군가 물었을 때 무슨 일이 있었는지 증명할 수 있는가입니다. 이 두 가지, 즉 에이전트를 위한 just-in-time 권한과 '누가·왜·누구의 승인으로'에 답하는 감사는 이어지는 글에서 다루겠습니다.
자주 묻는 질문
AI 에이전트는 공격 표면을 넓히나요? 이미 통제하는 접근 경로 밖으로 연결할 때만 그렇습니다. 새 아이덴티티, 상시 키, 새 진입로를 주는 방식이죠. 사람이 쓰는 것과 똑같이 스코프가 정해지고 키가 없으며 감사되는 접근에 태우면, 그 경로에 새로 더해지는 공격 표면은 없습니다.
AI 에이전트 접근은 사람 접근과 어떻게 다른가요? 기능적으로는 다르지 않아야 합니다. 에이전트는 사람과 같은 접근 단위, 즉 통제되는 아이덴티티 아래 스코프가 정해지고 시간이 한정된 세션이어야 합니다. 사람이 아님을 표시해 오히려 더 엄격히 다루는 것이지, 감시가 덜한 별도 경로를 주는 게 아닙니다.
AI 에이전트에 전용 SSH 키를 줘야 하나요? 아니요. 에이전트용 장기 SSH 키는 자동화 속에 남아 세션마다 불어나는 값비싼 상시 자격증명입니다. 아이덴티티에 묶여 세션마다 프로비저닝되고, 아이덴티티가 삭제되면 회수되는 키 없는 접근이 낫습니다.
AI 에이전트가 프로덕션 서버에서 무엇을 했는지 감사할 수 있나요? 가능합니다. 단, 에이전트의 모든 행동이 '누가 또는 무엇이, 어떤 스코프로, 누구의 승인으로' 행했는지를 하나의 타임라인에 기록하는 세션 안에서 돌아갈 때에 한해서요. 그 맥락이 없는 명령 로그는 감사가 아닙니다. (이 이야기는 이어지는 글에서 더 다룹니다.)
프로덕션 인프라에 에이전트를 붙이고 있다면, '에이전트를 더하는 것'이 '노출을 더하는 것'이 될지를 결정하는 게 바로 이 레이어입니다.
