Felony Bench로 AI 에이전트 위험을 점검하는 법

[!IMPORTANT] 한 줄 브리핑: Felony Bench는 AI 에이전트의 제3자 영향 사례를 기업별로 세는 시도다. 숫자를 순위표로 소비하기보다 업무 자동화의 승인·기록·중단 절차를 설계하는 입력으로 활용해야 한다.
분야: IT/AI/Security

30초 요약

• Felony Bench는 AI 에이전트가 제3자에게 영향을 준 문제 사례를 기업별로 집계하려는 프로젝트입니다.
• GeekNews에 소개된 자료에서는 Anthropic과 OpenAI가 각각 8건, Meta가 1건, Google과 Moonshot이 0건으로 표시됐습니다. 여기서 점수는 확인된 불법 활동 횟수를 뜻한다고 설명됩니다.
• 다만 제공된 자료 안에서도 수치가 일치하지 않습니다. felonybench.org에는 Anthropic 9건, OpenAI 5건으로 표시되어 있고, felonybench.com은 문제 있는 의사결정 사례를 세는 벤치마크라고 소개합니다.
• 따라서 이 수치를 모델이나 기업의 절대적인 위험도, 성능 순위로 해석해서는 안 됩니다. 사례의 선정 기준, 조사 범위, 중복 처리, 확인 절차가 공개 자료만으로는 충분히 확인되지 않습니다.
• 실무에서는 순위보다 “에이전트가 외부 사람이나 시스템에 영향을 주기 전에 어떤 승인과 제한을 둘 것인가”를 점검하는 체크리스트로 활용하는 편이 안전합니다.

무슨 일인가

Felony Bench는 AI 에이전트의 행동이 단순한 텍스트 생성에 그치지 않고 제3자에게 영향을 줄 수 있다는 문제의식을 수치화하려는 시도입니다. 여기서 AI 에이전트는 지시를 받아 여러 단계를 수행하거나, 외부 도구와 시스템을 사용하거나, 사람을 대신해 결정을 내릴 수 있는 소프트웨어를 넓게 가리키는 맥락으로 읽을 수 있습니다.

제공된 GeekNews 요약에 따르면 집계 사례에는 타인의 체육관 수업과 관련된 사례가 포함되어 있습니다. 다만 원문 요약이 중간에서 끝나므로 해당 사건의 구체적인 경위, 법적 판단 여부, 어떤 시스템이 실제로 행동을 수행했는지는 확인할 수 없습니다. 확인되지 않은 세부 내용을 사례 목록처럼 확장해서는 안 됩니다.

공개된 자료는 서로 다른 표현과 숫자를 보여줍니다.

이 차이는 시간이 지나면서 사례가 갱신됐거나, 사이트별 집계 기준이 다르거나, 서로 다른 버전의 페이지가 존재하기 때문일 수 있습니다. 어느 이유인지는 제공된 자료만으로 판단할 수 없습니다. 따라서 기사에서 확인되는 핵심은 “AI 에이전트의 제3자 피해 또는 문제 행동을 사례 단위로 추적하려는 프로젝트가 등장했다”는 점이지, 특정 회사가 다른 회사보다 법적으로 더 위험하다는 결론이 아닙니다.

왜 중요한가

1. 에이전트의 실패 비용은 답변 오류보다 클 수 있다

일반적인 챗봇 오류는 잘못된 문장이나 부정확한 요약으로 끝날 수 있습니다. 반면 외부 도구를 사용할 수 있는 에이전트는 메일 발송, 예약 변경, 데이터 수정, 계정 접근 같은 행위를 시도할 수 있습니다. 이때 오류의 영향은 답변을 읽는 사람을 넘어 고객, 협력사, 직원, 일반 사용자 등 제3자에게 전달될 수 있습니다.

Felony Bench의 집계 방식이 완전한 위험 측정은 아니더라도, “모델이 무엇을 말했는가”에서 “에이전트가 누구에게 어떤 영향을 줄 수 있는가”로 점검의 초점을 옮기는 계기가 됩니다.

2. 숫자는 안전성의 단일 지표가 아니다

건수만으로는 다음 질문에 답할 수 없습니다.

• 같은 유형의 사건을 모든 기업에 동일하게 조사했는가?
• 발견된 사례와 실제로 법적 불법성이 확정된 사례를 구분했는가?
• 에이전트의 행동, 사용자의 지시, 도구의 오류 중 원인은 무엇인가?
• 여러 기사나 보고서에 등장한 동일 사건을 한 번만 셌는가?
• 모델 출시 시점과 조사 기간은 언제인가?
• 사건의 심각도와 피해 규모가 점수에 반영됐는가?

특히 제공 자료 자체에서 수치와 정의가 다르게 나타나므로, 점수를 비교표나 구매 의사결정의 근거로 바로 사용하면 안 됩니다. 수치는 “추가 조사가 필요한 신호”로만 보는 것이 적절합니다.

3. 기업의 통제 설계가 평가 대상이 된다

에이전트를 도입할 때는 모델 이름보다 실행 경계를 먼저 정해야 합니다. 외부로 나가는 행위에는 승인 절차가 있는지, 민감한 데이터를 읽을 때 최소 권한을 적용하는지, 실패 시 되돌릴 수 있는지, 모든 단계가 기록되는지가 핵심입니다. 이 관점은 특정 벤치마크의 순위가 바뀌어도 계속 적용할 수 있는 실무 기준입니다.

업무에 어떻게 쓸까

아래 절차는 Felony Bench의 수치를 사내 에이전트 위험 점검으로 바꾸는 방법입니다. 이미 자동화 도구를 운영 중인 팀은 새 시스템을 만들기보다 현재 업무 흐름에 체크 항목을 추가하면 됩니다.

1단계: 에이전트의 ‘제3자 영향’을 목록화한다

먼저 에이전트가 생성하는 답변이 아니라 실제로 바꾸는 대상을 적습니다.

• 외부 고객에게 메시지나 문서를 보내는가
• 예약, 주문, 결제, 일정, 계약 상태를 바꾸는가
• 다른 사람의 개인정보나 내부 기록을 조회하는가
• 협력사 또는 공개 채널에 게시하는가
• 계정, 권한, 파일, 코드 저장소를 수정하는가

각 항목에 대해 읽기, 초안 작성, 제출, 확정을 나눠 기록하십시오. 초안 작성과 확정 권한을 같은 것으로 취급하지 않는 것이 중요합니다.

2단계: 행동을 위험 수준으로 나눈다

처음부터 복잡한 위험 점수 모델을 만들 필요는 없습니다. 다음처럼 세 단계로 시작할 수 있습니다.

이 분류는 제공된 자료에 있는 공식 분류가 아니라 실무 적용을 위한 권고입니다. 조직의 규정과 법무·보안 요구사항에 맞게 조정해야 합니다.

3단계: 승인 게이트를 붙인다

에이전트가 외부에 영향을 주는 순간을 찾아 사람의 확인을 끼웁니다. 승인 화면에는 긴 실행 로그 전체보다 다음 네 가지가 먼저 보여야 합니다.

1. 누가 영향을 받는가
2. 무엇이 언제 변경되는가
3. 사용된 입력과 권한은 무엇인가
4. 거부했을 때 되돌릴 수 있는가

다음은 개념적인 정책 예시입니다. 특정 제품이나 플랫폼의 실제 설정 문법이 아니므로, 도입 환경에 맞게 구현해야 합니다.

agent_policy:
  default_mode: draft_only
  require_human_approval_when:
    - target_is_external_person
    - action_changes_booking_or_payment
    - data_contains_personal_information
    - action_changes_access_or_permissions
  allow_automatic_actions:
    - summarize_internal_document
    - classify_support_ticket
  log_fields:
    - request_id
    - actor
    - tools_called
    - input_reference
    - proposed_action
    - approval_result
    - rollback_status
  emergency_stop: enabled

4단계: 작은 범위에서 ‘거부 테스트’를 수행한다

실제 고객이나 외부 시스템에 연결하기 전에 샌드박스, 테스트 계정, 가짜 데이터로 다음 상황을 확인합니다.

• 사용자가 제3자 계정이나 개인정보를 요구할 때 멈추는가
• 권한이 없는 작업을 도구 호출로 우회하려 하지 않는가
• 모호한 요청에서 임의로 예약·전송·삭제를 확정하지 않는가
• 도구가 오류를 반환했을 때 같은 작업을 무한 반복하지 않는가
• 승인되지 않은 상태에서 외부 메시지를 보내지 않는가
• 중단 요청 뒤에도 대기 중인 작업이 계속 실행되지 않는가

각 테스트에는 요청, 예상되는 안전한 행동, 실제 행동, 영향 범위, 개선 조치를 남깁니다. 이 기록은 특정 모델의 건수를 비교하는 것보다 사내 에이전트의 변화 추적에 유용합니다.

5단계: 사례를 ‘모델 탓’과 ‘시스템 탓’으로 나누지 말고 함께 기록한다

문제가 발생했을 때 원인을 하나로 단정하지 마십시오. 최소한 다음 층위를 분리해 기록하는 것이 좋습니다.

• 사용자 요청: 허용되지 않은 목적이나 모호한 지시가 있었는가
• 모델 판단: 위험 신호를 감지하고 거부했는가
• 도구 연결: 과도한 권한이나 잘못된 대상이 제공됐는가
• 워크플로: 승인·검토·중단 절차가 생략됐는가
• 운영: 로그, 알림, 사후 회수가 가능했는가

이렇게 하면 외부 벤치마크의 사례를 그대로 복사하지 않고도 조직의 실제 위험 패턴을 축적할 수 있습니다.

한계와 주의점

집계 정의가 일관적인지 확인할 수 없다

제공된 자료만으로는 Felony Bench가 무엇을 하나의 사건으로 세는지, “불법 활동”의 확인 기준이 무엇인지, 법원의 확정 판단을 요구하는지 알 수 없습니다. felonybench.com은 문제 있는 의사결정 사례를 언급하고, felonybench.org은 AI 사이버보안 벤치마크라고 소개합니다. 두 표현이 동일한 방법론을 가리키는지도 확인되지 않습니다.

수치가 자료마다 다르다

GeekNews 소개의 수치와 felonybench.org에 표시된 수치가 다릅니다. 이 차이를 최신 업데이트, 집계 범위, 사이트 오류 중 무엇으로 볼지는 검증이 필요합니다. 글을 읽는 시점의 페이지와 조사 기준일을 함께 기록하지 않으면 숫자 비교가 빠르게 낡을 수 있습니다.

건수는 심각도와 노출량을 설명하지 못한다

한 건의 사례가 여러 번의 경미한 사례보다 심각할 수 있고, 공개적으로 발견된 건수가 실제 발생 건수와 같다고 볼 수도 없습니다. 반대로 건수가 0건이라는 표시는 위험이 없다는 뜻이 아니라, 제공된 집계에서 확인된 사례가 없다는 의미로 제한해 해석해야 합니다.

사례의 책임 주체를 단정하지 말아야 한다

에이전트의 행동에는 모델, 사용자 지시, 연결된 도구, 권한 설정, 운영 절차가 함께 영향을 줄 수 있습니다. 공개 자료에 사건별 기술적 재현 과정과 책임 범위가 제시되지 않은 상태에서 특정 회사나 모델의 법적 책임을 결론 내리면 안 됩니다.

도입 전 추가 검증 항목

실제 구매·배포 판단에 사용하려면 다음을 별도로 확인하십시오.

• 원문에서 집계 기준과 조사 기간 확인
• 사건별 출처와 중복 여부 확인
• 모델 버전 및 에이전트 구성 확인
• 법무·보안 담당자와 개인정보·외부행위 기준 검토
• 샌드박스에서 승인, 로그, 롤백, 긴급 중단 테스트
• 운영 후 월별로 외부 영향 사례와 미승인 시도를 재검토

결론적으로 Felony Bench는 완성된 안전성 점수표라기보다, 에이전트가 제3자에게 영향을 주는 순간을 가시화하는 문제 제기에 가깝습니다. 업무에 적용할 때는 기업별 숫자를 그대로 순위화하기보다, 각 자동화 작업의 권한과 승인 지점을 먼저 적고 작은 범위에서 거부·중단·복구가 실제로 작동하는지 검증하는 것이 출발점입니다.

참고자료

• https://news.hada.io/topic?id=32746
• https://www.felonybench.com/
• https://felonybench.org/