AI 에이전트가 읽기 전용 보조 도구를 넘어 관찰, 추론, 도구 호출, 결과 검증으로 이어지는 보안 루프에 들어오고 있다. 핵심 변화는 단순히 모델 성능이 좋아진 것이 아니라, 모델에 ID와 시스템 접근 권한, 연속된 작업을 실행할 권한이 결합됐다는 점이다.

AWS, HackerOne, Wiz, Cisco Talos가 공개한 내용은 기계 속도의 방어, 실제 코드베이스 테스트, 통제된 취약점 악용, 사고 대응 운영 등 이러한 변화의 여러 측면을 보여준다. 아직 에이전트가 보안 조직을 대체할 수 있다는 증거는 아니지만, 별도의 거버넌스가 필요한 새로운 운영 계층으로 평가하기에는 충분하다.

보안 어시스턴트가 에이전트가 되면 무엇이 달라지나?

일반적인 AI 어시스턴트는 경보를 요약하거나 사람이 검토할 명령을 제안한다. 에이전트는 여기서 더 나아가 사용자를 대신해 인증하고, 여러 단계의 워크플로를 실행하며, 시스템 전반에서 결정을 내릴 수 있다. AWS는 에이전트 기반 탐지·대응을 설명하면서 이러한 특성을 제시했다.

이 구조는 탐지와 조치 사이의 시간을 줄일 수 있다. 모든 단계를 별도의 수동 대기열로 넘기는 대신 에이전트가 컨텍스트를 수집하고, 도구를 선택하고, 가설을 검증한 뒤 그 결과로 다음 행동을 결정할 수 있기 때문이다.

다만 자율성은 켜짐과 꺼짐으로 나뉘는 단일 옵션이 아니다. 대응 방법만 추천하는 시스템, 읽기 전용 검사를 실행하는 시스템, 리소스를 격리할 수 있는 시스템은 서로 다른 승인 정책과 허용 가능한 영향 범위를 가져야 한다.

공개된 사례는 실제로 무엇을 보여주나?

HackerOne의 Project Glasswing은 자사 코드베이스에서 프런티어 모델을 실행한 경험을 다룬다. 분리된 보안 질문이나 합성 테스트만 사용한 것이 아니라 조직의 실제 코드 환경을 평가 대상으로 삼았다는 점이 중요하다.

Wiz가 공개한 사례에는 더 구체적인 행동 흐름이 등장한다. 회사 설명에 따르면 Wiz Red Agent는 GitHub Copilot의 지원을 받은 풀 리퀘스트와 관련된 GitHub Actions 인젝션을 독립적으로 발견하고 악용했다. 이 문제는 GitHub Advanced Security가 놓친 것으로 보고됐으며, 에이전트는 사람의 개입 없이 Snowflake 내부 Jira의 민감한 데이터에 접근할 수 있음을 검증하고 영향 범위까지 평가했다.

이는 독립 벤치마크가 아니라 공급자가 자사 시스템에 관해 공개한 사례이므로 그 한계를 감안해야 한다. 그럼에도 취약점 발견, 악용 가능성 입증, 접근 경로 추적, 결과 평가를 하나의 흐름으로 연결했다는 설명은 아키텍처 측면에서 의미가 있다. 의심스러운 코드에 라벨을 붙이는 작업과는 권한 및 위험 수준이 다르기 때문이다.

Cisco Talos는 또 다른 긴장을 제기한다. Talos는 보안 운영의 ‘safety penalty’에 관한 분석에서 프런티어 모델의 강화된 제한이 실시간 사고 대응을 방해할 수 있지만 공격자는 동일한 제약을 받지 않을 수 있다고 주장한다. 이는 Talos의 해석이며 모든 안전장치가 방어력을 떨어뜨린다는 증거는 아니다. 방어 임무에 맞는 모델 통제권과 사용 정책이 필요하다는 문제 제기로 읽는 편이 타당하다.

실패의 성격이 잘못된 답변에서 잘못된 행동으로 바뀐다

모델이 텍스트만 생성한다면 잘못된 결론과 프로덕션 시스템 사이에 보통 사람의 검토 단계가 남아 있다. 그러나 토큰, 서비스 ID, 도구 접근 권한을 가진 에이전트의 오류는 구성 변경, 데이터 조회 또는 부적절한 격리 조치로 이어질 수 있다.

따라서 보안 에이전트는 API를 연결한 챗봇이 아니라 특권 머신 ID로 관리해야 한다. 권한은 최소화하고 수명을 짧게 설정하며 환경별로 분리해야 한다. 중개 도구가 비밀을 노출하지 않고 작업을 수행할 수 있다면 비밀 값을 모델 컨텍스트에 직접 넣지 않는 것이 바람직하다.

관측 가능성은 전체 의사결정 체인을 포괄해야 한다. 어떤 입력을 참조했는지, 어떤 도구와 파라미터를 사용했는지, 어느 리소스가 변경됐는지, 어떤 증거로 결론을 내렸는지를 추적할 수 있어야 한다. 운영 관점에서는 기존 대시보드에 AI 기능을 붙이는 것보다 관리형 Control Plane을 설계하는 문제에 가깝다.

취약점 악용 검증에는 추가 경계가 필요하다. 실제 악용 가능성을 입증하면 정적 경고보다 강한 우선순위 신호를 얻을 수 있지만, 서비스 중단이나 의도하지 않은 접근, 민감 데이터 보관 위험도 생긴다. 실행 전에 대상 범위, 중단 조건, 증거 처리 규칙을 명시해야 한다.

개발 조직은 어떻게 평가해야 하나?

첫 단계로는 가치가 높으면서 영향 범위가 제한된 워크플로가 적합하다. 경보 컨텍스트 보강이나 격리된 환경에서의 테스트가 예다. 인상적인 데모를 수행했다는 이유만으로 전역 쓰기 권한이나 되돌릴 수 없는 대응 권한부터 부여해서는 안 된다.

1. 자율성 단계를 정의한다: 권고, 승인 후 실행, 자동 실행을 구분하고 각 단계를 리소스 종류와 사고 심각도에 연결한다.
2. ID와 도구를 제한한다: 최소 권한, 단기 자격 증명, 명시적인 도구 허용 목록, 호출 속도 제한을 적용한다.
3. 검사 가능한 증거를 요구한다: 자신감 있는 최종 답변만 받지 말고 도구 호출 기록, 영향받은 리소스, 조치 근거를 보존한다.
4. 탈출 경로를 만든다: 파괴적 작업에는 사람의 승인을 유지하고 긴급 중지와 이전 상태 복원 절차를 준비한다.
5. 허가된 실제 워크플로에서 평가한다: 공급자 데모를 일반화하지 말고 통제된 환경에서 조직의 저장소, 경보, 정책을 사용해 검증한다.

평가 지표에는 유용한 결론까지 걸린 시간뿐 아니라 승인된 조치의 비율, 오탐, 롤백이 필요했던 작업, 감사 로그의 완전성도 포함해야 한다. 목표는 자동화를 최대화하는 것이 아니다. 기존 절차보다 안전하거나 효과적임을 입증할 수 있는 자동화를 만드는 것이다.

업무 완료 여부와 함께 정책 준수도 테스트해야 한다. 취약점을 찾았더라도 허용 범위를 무시한 에이전트는 성공한 시스템이 아니다. 반대로 의미 있는 방어 작업을 모두 거부한다면 좁은 의미에서는 안전할 수 있어도 실무 가치는 낮을 수 있다.

결론

• AI 에이전트는 보안을 답변 생성이 아니라 행동 거버넌스의 문제로 바꾼다.
• 공개 사례는 탐지, 악용 검증, 영향 평가가 하나의 루프로 연결될 가능성을 보여준다.
• 자율성을 높이기 전에 최소 권한, 격리, 감사 가능한 증거, 중단 장치를 갖춰야 한다.
• 현재 대부분의 조직에는 광범위한 프로덕션 권한보다 통제된 평가가 적합하다.

관련 글

• Ventura React: 이 경량 컴포넌트 라이브러리는 새 프로젝트에도 적합할까?
• Nova MCP: Cursor와 Claude를 제품 제작 팀으로 바꾸는 방법
• Ansible Automation Orchestrator: 관리형 Control Plane 설계

참고 자료

• The safety penalty: Reclaiming operational sovereignty in the age of AI
• Agentic security: Detection and response at machine speed
• Project Glasswing: What We Learned Running a Frontier Model on Our Own Codebase
• Wiz Red Agent Finds Its Way Into Snowflake’s Internal Jira Through a Flaw in a GitHub Copilot–Assisted PR