JIT는 에이전트가 들어오는지, 그리고 언제인지를 정합니다. 일단 들어온 뒤 무엇을 하는지는 다루지 못합니다.
올해 초 한 AI 코딩 에이전트가 프로덕션 환경에서 terraform destroy를 실행해 라이브 데이터베이스를 날렸습니다. 무려 190만 행의 데이터였고, 에이전트가 판단하기에는 맞는 행동이었기에 벌어진 일입니다. 곱씹어 볼 대목은 이겁니다. 그 에이전트는 유효한 자격증명과 정당한 세션을 갖고 있었습니다. 여기에 just-in-time(JIT) 접근을 적용했다면 세션은 필요할 때 발급되고 작업이 끝나는 순간 완벽하게 회수됐을 텐데, 결과는 조금도 달라지지 않았을 겁니다.
바로 이게 JIT 접근의 허점입니다. 훌륭한 발상이지만, 더 느린 행위자를 위해 만들어진 것이죠. 앞선 글에서 저는 에이전트를 더한다고 공격 표면까지 넓어져선 안 된다고 말했습니다. 그건 에이전트가 '어떻게 연결되는가'에 관한 이야기였습니다. 이번 글은 그다음 질문입니다. 완벽하게 스코프가 정해지고 완벽하게 일시적인 세션으로 일단 들어온 뒤, 에이전트가 실제로 무엇을 하는지는 무엇이 통제할까요?
JIT 접근이 AI 에이전트에게 충분할까요?
요약: JIT는 상시 권한, 즉 접근이 존재하는지와 언제 존재하는지를 해결합니다. 유효하고 스코프가 맞으며 완벽하게 일시적인 세션 '안에서' 에이전트가 무엇을 하는지는 다루지 않습니다. 상시 권한 제거는 필요조건이지 충분조건이 아닙니다.
업계는 에이전트 접근에 대해 한 가지 답으로 수렴했습니다. 상시 권한을 없애라. 에이전트에 지속되는 것을 아무것도 주지 말고, 접근을 필요할 때 발급하고, 스코프를 좁히고, 작업이 끝나면 만료시켜라. 이제 모든 PAM 벤더가 같은 말을 하고, 맞는 말이긴 합니다. 상시 admin 자격증명을 쥔 에이전트는 상시 위험 요소니까요.
근데 terraform destroy를 다시 보세요. 상시 권한 문제는 없었습니다. 세션은 유효했고 스코프는 정당했으며, JIT였다면 몇 초 뒤 회수됐을 겁니다. JIT는 자기 일을 다 했는데도 데이터는 사라졌습니다. JIT는 에이전트에게 접근이 있는지와 언제 있는지를 결정할 뿐, 그 접근으로 무엇을 하는지는 결정하지 않기 때문입니다.
Alpacon도 JIT를 합니다. 세션은 만료되고, 세션 시간이 지나면 아무것도 남지 않으며, 에이전트 세션에는 상시 권한이 없습니다. 이번 글이 다루는 건 그 위의 레이어, 즉 행위 그 자체를 판단하는 레이어입니다.
'grant then trust'가 왜 AI 에이전트에겐 안 통할까요?
요약: JIT도 접근이 허가되면 그 세션은 신뢰합니다. 그 신뢰는 사람을 전제했습니다. 검토할 만큼 느리고, 신뢰할 만큼 예측 가능한 존재를요. 에이전트는 둘 다 아닙니다. 머신 속도로 움직이고, 행동에 본질적인 제한이 없습니다.
예전 모델은 접근을 허가한 뒤 세션을 신뢰합니다. 세션 안의 존재가 사람이었기에 통했습니다. 사람은 대체로 예측 가능합니다. 설명할 수 있는 이유로 행동하고, 검토할 수 있는 속도로 움직이며, 책임지는 규범 안에서 움직입니다. '한 번 허가되면 세션은 신뢰된다'는 사람에 대한 합리적인 가정이었습니다.
에이전트는 그 가정을 두 축에서 깨뜨립니다. 첫째는 속도입니다. 프롬프트 하나가 이 문장을 다 읽기도 전에 수십 개의 도구 호출로 퍼지니, '하는 걸 다 검토하면 되지'는 처리량이 사람이 지켜볼 수 있는 선을 넘는 순간 무너집니다.
둘째는 더 심각합니다. 에이전트는 설계상 예측 불가능합니다. 같은 프롬프트가 다른 경로를 밟고, 모델은 즉흥적으로 판단하며, 어떤 운영자도 택하지 않을 길로 목표를 좇아 다음으로 '논리적인' 명령을 실행합니다. terraform destroy나 엉뚱한 경로의 rm -rf 같은 것을, 사람이라면 망설임이나 책임감을 느꼈을 법한 것들을요. 각종 연구도 이를 뒷받침합니다. autonomy-induced risk 조사는 바로 이 실패 양상, 즉 되돌릴 수 없는 툴 체인과 의도에서 벗어나는 행동을 하나하나 정리하고, 2026년 논문 'The End of Trust'는 그 해법이 행위자를 신뢰하는 대신 행위를 평가하는 것, 즉 suspect-by-default라고 주장합니다.
그래서 모델이 뒤집힙니다. 이렇게 빠르고 열려 있는 행위자에게는 'grant then trust'를 확장할 수 없습니다. 예전엔 아이덴티티가 컨트롤 플레인이었습니다. 사람을 인증하고 그 뒤를 신뢰하는 것이죠. 에이전트에게는 컨트롤 플레인이 런타임으로, 행위 그 자체로 옮겨 가야 합니다. 지금 무슨 일이 일어나려는지를 여전히 볼 수 있는 곳은 그곳뿐이기 때문입니다.
에이전트의 모든 동작에는 무엇이 묶여야 할까요?
요약: 두 가지입니다. 스코프는 정적인 상한, 즉 어느 서버에 어떤 권한까지입니다. 의도(intent)는 동작 단위의 판정, 즉 스코프 안의 여러 가지 중 '바로 이 동작'이 세션을 연 목적에 맞는가입니다.
Alpacon에서 에이전트의 모든 동작은 Work Session에 속하고, 세션 밖 경로란 없습니다. 세션은 스코프와 필수 **목적(purpose)**을 미리 선언합니다. 나중에 덧붙이는 게 아닙니다. 그 선언된 목적이 세션의 의도이고, Alpacon은 각 동작을 거기에 비추어 판단합니다. 스코프는 별개로, 일반 역할 권한 위에 놓인 상한선입니다. 스코프에 sudo가 없는 세션은, 슈퍼유저라 해도, 어떤 프롬프트가 뜨기도 전에 sudo가 거부됩니다. 에이전트가 스스로 자기 상한을 올릴 수는 없습니다.
다만 스코프만으로는 여전히 부족합니다. '로그 파일을 삭제해도 된다'는 스코프 안에서는, 아래 두 경우 모두 괜찮다고 판단합니다.
✅ rm -rf /var/log/nginx/old/* 의도: 오래된 nginx 로그 정리
⚠️ rm -rf /var/log/* 의도: 불분명, 작업 범위보다 훨씬 넓음
같은 명령어입니다. 하나는 세션을 연 목적인 정리 작업이고, 다른 하나는 서버의 모든 로그로 조용히 번집니다. 스코프는 이 둘을 구분하지 못하지만, 의도는 구분합니다. Alpacon은 각 동작을 세션이 선언한 목적에 비추어 판단합니다. 그래서 첫 번째는 부합하고, 두 번째는 선언된 의도에서 벗어난 것으로 표시됩니다. 판정의 대상은 세션을 쥔 아이덴티티가 아니라 동작 그 자체입니다. RSAC 2026에서 응답자의 63%는 에이전트가 무엇을 할 수 있는지를 강제할 수 없다고 답했는데, 바로 그 간극을 동작에 의도를 묶는 방식이 메우려는 것입니다.
이건 가정이 아닙니다. Alpacon이 실제로 잡은 명령입니다. 이름과 경로는 익명화했습니다.
bash -c 'rm -rf /home/deploy/release && mkdir -p /home/deploy/release && echo OK'Recursively deletes /home/deploy/release, which contradicts the session description targeting /var/www/app—risk of data loss if the path is wrong or shared.
- Recursive deletion of a sensitive target
- Novel commands for server: mkdir, echo
- Does not serve the work_session description
이 rm -rf는 자격증명으로 실행 가능한, 스코프 안의 명령이었습니다. 하지만 세션이 선언한 목적과 모순됐고, 그래서 의도가 고위험으로 판정해 거부했습니다. 삭제는 실행되지 않았습니다. 스코프는 허용했을 겁니다. 의도는 허용하지 않았습니다.
여기엔 접근 제어가 구조적으로 보지 못하는 구멍도 있습니다. 유효하고 스코프가 정해진 에이전트도 프롬프트 인젝션이나 오염된 툴 출력으로 하이재킹돼, 자기가 쥔 접근을 도리어 공격 수단으로 되돌릴 수 있습니다. 실제로 공격자가 가짜 에러 메시지를 심어 코딩 에이전트가 개발자 본인의 자격증명으로 명령을 실행하게 만든 사례가 있었죠. 자격증명은 유효하고 행위도 스코프 안일 수 있어서, 아이덴티티·경계 검사는 아무 이상을 못 봅니다. 그 행위를 세션이 선언한 의도에 비추어 판단하는 것만이 잡아냅니다.
에이전트를 늦추지 않으면서 동작을 실시간으로 판단하려면?
요약: 결정론 우선(deterministic-first) 캐스케이드입니다. 규칙과 기준선이 뻔한 경우를 즉시 정리하고, 모델은 정말 애매한 경우에만 개입합니다. 대부분의 동작은 LLM을 거치지도 않습니다.
'AI가 명령을 판단한다'는 말에서 걱정되는 건 느리고 못 믿겠다는 점입니다. 그래서 판단을 계층으로, 값싼 것부터 쌓습니다. 규칙 계층이 명백히 허용되는 것을 통과시키고 명백히 금지되는 것을 즉시 표시합니다. 기준선 계층은 이 아이덴티티가 평소 하는 것과 그 동작을 비교합니다. 규칙으로 정리되지 않고 일상적이지도 않은, 그 사이의 좁은 회색지대만 모델로 넘어가 선언된 의도에 비추어 저울질됩니다. 빠르고 결정론적인 검사가 대부분을 처리하고, 값비싼 판단은 정말 필요한 곳에만 씁니다.
이건 분류에서 끝나지 않습니다. Alpacon은 그 판단을 실시간으로 실행에 옮길 수 있습니다. 규칙이나 세션의 허용 범위를 위반한 명령은 호스트에 닿기 전에 거부되고, 애매한 고위험 명령은 사람에게 넘겨져 승인이나 거부가 날 때까지 붙잡힙니다. 어느 쪽으로 운영할지는 직접 고릅니다. 차단 없이 점수만 매기고 기록하는 모니터 모드로 돌리거나, 판단을 실시간으로 실행에 옮기는 enforce 모드로 돌리거나. 한 가지 짚고 넘어가면, 이것은 에이전트가 우리 서버로 가는 경로를 통제하는 것이지 에이전트의 사고 자체를 통제하는 것이 아닙니다. 프롬프트 인젝션은 실재하는 위험이고, 또 다른 문제입니다.
정책이 확신하지 못할 때는 누가 결정할까요?
요약: 제한된 자율성(bounded autonomy)입니다. 대다수 동작은 손대지 않고 흘려보내고, 애매하거나 고위험인 일부만 사람에게 에스컬레이션합니다. 그리고 인간이 아니라면 결코 자기 에스컬레이션을 스스로 승인할 수 없습니다.
핵심은 모든 명령 뒤에 사람을 세우는 게 아닙니다. 정반대입니다. 명백히 경계 안쪽인 것은 에이전트가 자유롭게 달리게 두고, 정말 애매하거나 고위험인 일부에만 사람을 부릅니다. 설계 목표는 에이전트 동작의 약 95%가 사람 개입 없이 진행되고, 남은 약 5%가 Slack이나 웹훅, 모바일 푸시를 통해 몇 초 안에 적절한 사람에게 닿는 것입니다.
이걸 안전하게 만드는 두 가지 성질이 있습니다. 에스컬레이션은 별도 승인 채널로 돌아옵니다. 승인은 에이전트가 요청한 채널이 아니라 에이전트가 통제하지 못하는 별도 채널로 돌아오죠. 그래서 서비스 토큰은 아무리 많이 쥐어도 자기 자신을 슬쩍 승인할 수 없습니다. 그리고 애초에 에이전트 모드 세션은 생성 시 사람의 승인을 받습니다. 슈퍼유저가 열더라도 자동으로 활성화되지 않습니다. 규제도 같은 요구로 수렴하고 있습니다. EU AI Act는 고위험 AI 시스템이 사람이 개입하거나 정지시킬 수 있도록 의무화합니다. Bessemer는 '표적화된 실시간 개입(targeted in-flight intervention)'을 AI 에이전트 보안에서 가장 덜 개발된 영역으로 꼽았습니다. 바로 JIT가 애초에 다루도록 만들어지지 않은 레이어입니다.
그래서 무엇을 얻게 되나요?
요약: 스코프가 정해지고 의도를 인지하며 사람으로 경계 지어진 자율성. 경계가 문이 아니라 동작에 묶이기에, 마음 놓고 달리게 둘 수 있는 에이전트입니다.
JIT는 사람에게 옳았고, 지금도 답의 일부입니다. Alpacon은 세션을 만료시키고 에이전트 세션에 상시 권한을 두지 않습니다. 하지만 상시 권한 제거는 에이전트가 들어오는지 여부만 결정합니다. 일단 들어온 뒤 무엇을 하는지, 즉 선언된 스코프와 의도에 묶이고, 실시간으로 판단되며, 애매한 일부가 사람에게 넘겨지는 것, 이것이 머신 속도의 에이전트를 실제로 통제하는 레이어입니다.
이제 한 가지 질문이 남습니다. 무언가 벌어진 '뒤에' 받게 되는 질문이죠. 에이전트가 무엇을, 어떤 의도로 했고, 누가 승인했는지 증명할 수 있는가? 여기서 일어난 모든 허용, 에스컬레이션, 거부가 기록이 됩니다. 그 기록을 실제로 답할 수 있는 감사로 바꾸는 이야기가 다음 글입니다.
자주 묻는 질문
JIT 접근만으로 AI 에이전트를 지킬 수 있나요? 아니요. 필요조건이지 충분조건이 아닙니다. JIT와 상시 권한 제거는 훔칠 수 있는 지속적 접근을 없애고, 이건 중요합니다. 하지만 에이전트가 접근 권한을 갖는지와 언제 갖는지만 통제할 뿐, 유효하고 스코프가 정해진 일시적 세션 '안에서' 무엇을 하는지는 통제하지 않습니다. 제대로 JIT로 발급된 세션도 살아 있는 몇 초 안에 파괴적인 명령 하나를 실행할 수 있습니다.
AI 에이전트에게 스코프와 의도는 어떻게 다른가요?
스코프는 정적인 상한, 즉 세션이 쓸 수 있는 서버와 권한입니다. 의도는 동작 단위의 판정, 즉 스코프 안의 모든 것 중 '바로 이 동작'이 세션을 연 목적인가입니다. 오래된 로그 경로의 rm -rf와 모든 로그의 rm -rf는 스코프는 같지만 의도는 다릅니다.
실시간 명령 판단이 에이전트를 느리게 하나요? 대부분의 동작은 모델에 닿지도 않습니다. 결정론적 규칙·기준선 계층이 명백히 허용·금지되는 것을 즉시 정리하고, 애매한 회색지대만 선언된 의도에 비추어 판단됩니다. 무거운 판단은 필요한 곳에만 씁니다.
AI 에이전트가 하는 모든 걸 사람이 승인해야 하나요? 아니요. 설계는 제한된 자율성입니다. 설계 목표상 약 95%의 동작은 손대지 않고 흘러가고, 애매하거나 고위험인 일부만 사람에게, 그것도 에이전트가 통제하지 못하는 채널로 몇 초 안에 라우팅됩니다. 에이전트는 자기 에스컬레이션을 스스로 승인할 수 없습니다.
프로덕션 인프라에 에이전트를 사용하고 있다면, 유효한 세션이 안전한 세션이기도 한가를 결정하는 게 바로 이 레이어입니다.
