Kontext에 400만 달러…AI 에이전트는 로그인 뒤에도 과업을 벗어난다

독일 뮌헨의 AI 에이전트 보안 스타트업 Kontext가 42CAP이 주도하고 a16z CSX와 HTGF가 참여한 400만 달러 자금 조달을 2026년 9월 24일 발표했다고 SiliconANGLE이 보도했다. 조달 자금은 엔지니어링 인력 확충과 에이전트의 행동을 실행 시점에 통제하는 제품 개발에 쓰일 예정이다. 투자 발표가 짚은 문제는 에이전트가 정상적으로 로그인하고 승인된 도구를 쓰면서도 맡은 과업 밖의 행동을 할 수 있다는 점이다.

투자자인 HTGF의 뉴스 목록에도 2026년 9월 24일 Kontext의 400만 달러 조달이 올라 있다. 기업이 에이전트에 계정과 도구 사용 권한을 부여했다면, 다음 판단은 그 권한으로 요청한 개별 행동이 현재 지시한 일에 필요한가에 달려 있다. Kontext가 내세운 통제는 로그인 단계의 신원 확인에 과업별 판단을 더하는 방식이다.

유효한 계정으로도 버그 수정 범위를 넘는 이유

Kontext 공동창업자이자 최고경영자 Jens Ernstberger는 회사의 투자 발표문에서 “An AI agent can be properly authenticated, use an approved tool, and still take an action no one authorized”라고 말했다. 자격 증명이 유효하다는 사실은 그 계정의 주체를 가려 주지만, 해당 주체가 지금 하려는 행동의 목적까지 승인하지는 않는다. 에이전트는 한 번의 지시를 받은 뒤 여러 도구를 연속으로 호출할 수 있어 이 간격이 실제 작업 과정에서 드러난다.

회사가 제시한 사례는 소프트웨어 버그 수정이다. 이 일을 맡은 에이전트에는 코드 저장소를 읽을 이유가 있지만, 같은 코드를 외부 서비스로 보내거나 수정과 무관한 인프라 설정을 변경할 이유까지 주어진 것은 아니다. 저장소에 접근할 수 있는 계정이 두 요청을 모두 수행할 수 있더라도, 과업을 기준으로 보면 허용 여부가 갈린다. 여기서 문제 되는 것은 탈취된 계정이 아니라 정상 권한으로 시작된 행동의 목적이다.

기존 신원·접근관리 체계는 어떤 계정이 어느 저장소와 시스템에 들어갈 수 있는지 정한다. 그 판단이 끝난 뒤 에이전트가 저장소를 읽을지, 코드를 밖으로 보낼지, 무관한 자원을 바꿀지는 새로운 선택이다. 처음부터 계정의 모든 권한을 없애면 버그 수정 자체가 불가능해질 수 있다. 필요한 접근을 유지하면서 용도가 다른 요청을 가려내려면 자원에 대한 일반적인 권한과 배정된 일에 대한 승인을 구별해야 한다.

사람이 도구를 사용할 때는 한 동작마다 목적을 다시 생각하거나 상급자의 승인을 받는 절차를 붙일 수 있다. 에이전트는 사람의 다음 클릭을 기다리지 않고 도구 호출을 이어 갈 수 있으므로, 최초 과업 지시 이후 작업이 진행되는 동안 행동의 대상도 달라진다. 따라서 관리 대상은 에이전트의 계정만이 아니라 그 계정으로 생성되는 개별 요청이다. 두 요청이 같은 도구에서 나왔다는 사실만으로 같은 판단을 내려서는 안 된다.

Kontext의 판단 지점은 도구 호출 직전

제품 설명에 따르면 통제 지점은 에이전트와 에이전트가 호출하는 도구·시스템 사이에 놓인다. 요청이 들어오면 에이전트의 신원, 요청한 행동, 대상 자원, 배정된 과업을 보안 정책과 위험 신호에 비춰 평가한다. 이 중 과업 맥락은 단순한 접근 허용 목록에서 빠지기 쉬운 정보다. 같은 에이전트가 같은 저장소를 이용해도 현재 지시가 버그 수정인지, 다른 작업인지에 따라 허용할 행동의 범위가 달라질 수 있다.

버그 수정 사례에서 저장소 읽기는 에이전트가 코드를 살펴보는 데 필요한 동작이다. 외부 서비스로의 코드 전송은 같은 작업 흐름에서 시작됐더라도 별도의 위험을 만들고, 무관한 인프라 수정은 최초 지시와 연결되지 않는다. 실행 시점 정책은 이 차이를 요청이 전달되기 전에 판별하려는 장치다. 실제로 어느 요청을 허용하고 거부할지는 기업이 설정한 과업 정의와 정책의 내용에 따라 달라진다.

판단 시점도 결과를 바꾼다. 코드가 이미 외부로 전송된 뒤 기록에서 이상을 발견하면 전송 자체는 취소할 수 없다. 반면 도구가 행동하기 전에 거부 결정을 내려 전달을 멈출 수 있다면 그 요청의 실행을 막을 수 있다. Kontext가 설명하는 실행 차단은 이 선행 판단을 가리키며, 어떤 경로의 도구 호출이 그 판단을 거치는지가 제품의 실제 적용 범위를 결정한다.

에이전트의 모든 행동을 같은 지점에서 볼 수 있다고 단정할 수는 없다. 보호 대상 도구와 연결되지 않은 경로로 자원에 접근할 수 있다면 해당 요청은 정책 평가를 거치지 않을 수 있다. 그래서 ‘에이전트를 지원한다’는 표현만으로 기업의 모든 저장소, 명령, 외부 서비스 요청이 차단 대상이라는 뜻은 되지 않는다. 발표문은 통제 구조를 설명하지만, 특정 기업 환경에서의 탐지 정확도나 차단 범위를 수치로 제시하지는 않았다.

관찰 모드, 차단, 감사 기록의 차이

관찰 모드는 정책을 곧바로 강제하지 않고 실제 에이전트 행동에 적용하면 어떤 결정을 내릴지 기록하는 단계다. 업무를 중단시키지 않으면서 정상적인 저장소 조회가 거부 대상으로 잡히는지, 외부 전송처럼 관심을 둔 요청이 기록에 나타나는지 살필 수 있다. 따라서 관찰 결과는 정책을 조정하는 자료가 된다. 같은 이유로 관찰만 활성화된 상태에서는 위험하다고 분류된 행동도 실행 전에 멈추지 않는다.

실행 차단 모드의 역할은 구별된다. 정책에 맞지 않는 요청을 도구가 수행하기 전에 거부하는 것이 제품이 제시한 기능이다. 경고를 관리자에게 보내는 것과 실제 도구 호출을 중지시키는 것은 결과가 다르다. 저장소 코드를 외부로 보내려는 요청을 예로 들면, 차단이 유효하려면 코드가 전송된 후의 알림이 아니라 전송 동작 앞에서 판단이 내려져야 한다.

감사 기록은 허용된 행동과 거부된 행동에 모두 의미가 있다. 에이전트가 무엇을 시도했고, 어떤 정책이 적용됐으며, 왜 그 결정을 내렸는지를 남겨야 나중에 한 세션의 경위를 재구성할 수 있다. 접근 로그에 계정과 시각만 남는다면 그 계정이 당시 어떤 과업을 수행하던 중이었는지까지 설명하기 어렵다. 반대로 과업과 대상 자원이 결정 기록에 연결되면 정상적인 저장소 읽기와 범위 밖 전송 시도를 분리해서 볼 여지가 생긴다.

세 기능은 서로 대체하지 않는다. 관찰은 강제 전에 정책의 반응을 드러내고, 차단은 허용되지 않은 요청의 실행 여부를 바꾸며, 기록은 사후에 판단 근거를 남긴다. 관찰에서 많은 정상 작업이 거부 대상으로 표시된다면 정책을 그대로 강제할 때 업무가 막힐 수 있다. 반대로 기록이 충실해도 차단 가능한 경로가 좁으면 같은 에이전트의 다른 행동을 예방하는 효과는 제한된다.

국내 기업이 확인할 연결 범위와 운영 기준

도입을 검토하는 기업에 중요한 것은 배포된 에이전트가 어떤 도구를 실제로 호출하는지와 그 호출을 제품이 어느 시점에 포착하는지다. 버그 수정 업무라면 저장소 조회, 파일 변경, 명령 실행, 외부 서비스 요청이 서로 다른 경로를 탈 수 있다. 일부 경로에서만 실행 전 결정을 내릴 수 있다면 같은 과업이라도 정책의 적용 범위가 달라진다. 이 차이를 구분해야 ‘접근 가능’과 ‘과업상 허용’을 혼동하지 않는다.

관찰 결과를 볼 때도 단순히 거부 예정 요청의 개수를 세는 것보다 그 요청이 정상 업무에 속하는지 확인하는 편이 유용하다. 실제 업무에서 필요한 파일 읽기를 막는 정책이라면 강제 전 조정이 필요하고, 무관한 인프라 변경 요청이 보이지 않는다면 연결 지점을 살펴야 한다. 이 검토는 제품의 탐지 성능을 입증하는 시험 결과가 아니라, 조직의 과업 지시와 정책이 맞물리는지 확인하는 운영 기준이다.

감사 기록에서는 에이전트 신원과 배정된 과업, 요청한 도구 및 대상 자원, 허용·거부 이유가 함께 남는지가 핵심이다. 결정은 남아도 과업 정보가 빠지면 같은 계정의 적절한 사용과 범위 밖 사용을 구별하기 어렵다. 국내 조직이 기존 보안 로그와 연결하려 한다면 기록 형식, 보관 위치, 내보내기 범위도 실제 조사 절차에 맞춰 봐야 한다. 이렇게 해야 기록된 정책 결정이 기존 조사 흐름에서도 의미를 갖는다.

투자금이 개발 인력과 제품 고도화에 투입되는 만큼, 다음에 확인할 변화는 지원 도구와 차단 가능한 요청 경로가 얼마나 늘어나는지다. 더 넓은 연결 범위가 확보돼도 정상 작업을 잘못 막는 사례가 많다면 기업의 적용은 어려워진다. 에이전트가 유효한 계정으로 움직이는 동안에도 과업의 경계를 유지할 수 있는지는 실제 요청에 대한 선행 결정과 그 결과를 설명하는 기록에서 드러날 것이다.

함께 읽기:

• AIR에 5000만 달러…AI 에이전트의 플러그인까지 검사한다
• Proofpoint 보안 에이전트, 조사하지만 계정 차단은 사람이 한다
• Zendesk AI 에이전트가 환불까지 맡는다…승인 경계는 기업이 정한다