AI 에이전트 보안의 무게가 일이 끝난 뒤의 결과 점검에서, 에이전트가 도구를 부르는 호출 하나하나를 그 자리에서 확인하고 감시하는 쪽으로 옮겨 가고 있습니다. 지난 4화에서는 벤치마크가 도구에 대한 지식 대신 실제로 실행될 명령을 재기 시작했다고 짚었습니다. 오늘 논문들은 그 잣대를 평가실 밖의 실제 운영으로 가져옵니다. 명령이 실행되는 순간에 따지고, 일을 마무리하는 시점까지 따지는 방식입니다.
먼저 호출 단위의 감시입니다. 한 연구는 에이전트가 도구로 데이터를 읽고 외부 시스템에 손을 대는 일이 늘수록 호출마다 낮은 지연으로 붙는 감독이 필요하다고 봅니다. 기존 권한 체계는 에이전트가 그 도구를 써도 되는지는 가려냅니다. 하지만 그 호출이 맡은 일의 의도에 맞는 합리적인 한 걸음인지는 판단하지 못합니다. 허용된 호출도 일의 의도에서 벗어날 수 있고, 엇나간 에이전트가 다른 에이전트를 부추겨 호출을 조합할 수도 있습니다. 그래서 연구진은 모든 호출을 검증해야 한다고 보고, 그 검증을 작은 언어 모델로 맡길 수 있는지 살핍니다. 사내 서버에서 돌릴 수 있는 가벼운 감시병이라는 발상입니다.
감시에는 비용이 듭니다. JOVE 연구는 복잡한 질문을 여러 언어 모델에 나눠 맡기면서, 중간 결과 중 어느 것을 비용을 들여 검증할지 고르는 문제를 다룹니다. 실행만 해서는 결과가 맞는지 알 수 없고, 검증은 비동기로 돌며 다음 배정을 개선하는 데 쓰입니다. 연구진은 장기 예산과 질문당 지연 제약 아래에서 지금 실행에 쓸지, 나중을 위한 학습에 쓸지를 저울질합니다. 모든 호출을 검증하라는 요구와 검증은 공짜가 아니라는 현실이 여기서 만납니다.
감시해야 할 대상도 넓어졌습니다. EvoRiskBench는 작업 공간에서 여러 단계를 수행하는 에이전트의 실행 중 위험을 재는 벤치마크입니다. 위험의 출발점을 아홉 범주, 결과로 나타나는 효과를 다섯 범주로 나눕니다. 격리된 환경에서 위험 사례를 직접 실행하고, 실행 기록으로 결과를 독립적으로 확인합니다. 추측이 아니라 실제로 일어난 일을 근거로 삼는다는 점에서 4화의 흐름과 같은 방향입니다. 출처 선호 연구는 또 다른 사각지대를 보여 줍니다. 12개 에이전트 모델을 세 영역에서 살피니, 모델마다 선호하는 출처가 있었고 대체로 서로 일치했습니다. 요구 조건을 하나 덜 채운 항목도 선호 출처에서 나오면 약 3분의 2가 뽑혔고, 반대의 경우에는 거의 뽑히지 않았습니다. 악의적인 침입이 아니어도 호출 결과가 쏠릴 수 있다는 뜻입니다.
마지막은 끝맺음의 문제입니다. 사고나 장애 조사처럼 모은 증거가 사건을 닫기에 충분한지 판단해야 하는 일에서, 훈련하지 않은 90억 매개변수 모델은 답의 97%에서 증거를 과장했습니다. 원인을 84% 맞히는 최고 수준 모델도 91%에서 과장했고, 공식 결론이 원인 불명인 41건 중 17건을 닫았습니다. 연구진은 사례의 출처만 봐도 라벨이 상당히 맞아서, 출처만 읽는 규칙이 균형 정확도 83.0에 이른다는 점도 지적합니다. 맞히는 능력과 닫아도 되는지 아는 능력은 별개라는 이야기입니다.
이 흐름을 한 장으로 옮기면 다음과 같습니다.
정리하면 허용 여부만 보던 권한 확인 위에, 호출의 의도와 실행 기록, 종결 판단이 층층이 쌓이는 모양입니다.
그래서 에이전트를 업무에 쓰는 1인 사업자와 기획자는 세 가지를 봐야 합니다. 첫째, 에이전트가 하는 호출이 맡긴 일의 의도와 맞는지 기록으로 남는지입니다. 둘째, 검증에 쓰는 비용과 지연이 감당 가능한 범위인지입니다. 셋째, 에이전트가 이제 충분하다며 일을 닫을 때 그 근거가 실제로 확인 가능한지입니다. 이 논문들은 모두 연구 단계의 결과이니, 현장에 곧바로 적용되었다고 읽으시면 안 됩니다. 다만 AI 에이전트 보안을 묻는 질문이 이 에이전트를 믿어도 되는가에서, 이 호출을 지금 믿어도 되는가로 바뀌고 있다는 점은 분명합니다.
