AI 에이전트 위험 식별 및 관리하기

학습 목표

이 유닛을 완료하면 다음을 수행할 수 있습니다.

• 워크플로에서 에이전트가 데이터, 의사결정, 사람들과 상호 작용하는 지점을 식별합니다.
  
• AI 에이전트 위험을 완화하기 위해 위협 모델링을 구현합니다.
  

시작하기 전에

이 모듈을 시작하기 전에, 다음 추천 콘텐츠를 먼저 완료해 보세요.

• 개발자용 위협 모델링
  
• 위협 헌터용 위협 모델링
  

비즈니스 워크플로에 대한 위협 모델링

위협 모델링은 시스템이 어떻게 작동하는지 살펴보고, 문제가 발생할 수 있는 부분을 식별하며, 문제가 발생하기 전에 그러한 위험을 관리하는 방법을 결정하는 구조화된 방법입니다. 이번 유닛에서는 간소화된 버전의 위협 모델링을 사용하여 에이전트가 비즈니스 프로세스의 어느 부분에 활용될 수 있는지, 위험이 어느 지점에 유입될 수 있는지를 추적합니다.

코드 수준의 위협 모델링을 본격적으로 알아보기 전에 AI 에이전트가 대규모 비즈니스 워크플로 안에서 어떻게 작동하는지 이해하면 도움이 됩니다. STRIDE(스푸핑, 변조, 거부, 정보 공개, 서비스 거부, 권한 상승)는 대부분의 개발자들이 잘 알고 있는 위협 모델링 프레임워크로, 애플리케이션 내 기술적 보안 위협을 식별하는 데 사용됩니다. 하지만 아무리 뛰어난 STRIDE 분석이라도 에이전트 사용 방식에서 발생하는 모든 위험을 포착할 수는 없습니다.

개발자와 보안 전문가가 비즈니스 워크플로를 이해하면 위협 모델을 더 정교하게 구현할 수 있습니다. 정교한 위협 모델을 통해 핵심 단계와 에이전트의 의사결정이 외부와 내부로 어떻게 영향을 미치는지를 파악할 수 있습니다. 또한 통합 개발 환경(IDE)에서 드러나지 않는 위험을 인식할 수 있습니다. 승인 누락, 조용한 실패 현상, 불명확한 인계와 같은 문제는 코드 편집기에 표시되지 않습니다. 하지만 워크플로 자체를 모델링하고 점검하면 빠르게 드러나는 문제이기도 합니다.

워크플로 수준의 위협 모델링은 제어가 취약한 지점, 에이전트가 가정에 의존하는 부분, 작은 공백이 비즈니스에 영향을 미치는 문제로 확대될 수 있는 지점을 보여 줍니다.

자체 워크플로를 매핑하기 전에 다음 예시를 살펴보고, 모든 시스템이 정상적으로 작동하는 것처럼 보여도 단 하나의 누락된 단계가 전체 프로세스를 어떻게 무너뜨릴 수 있는지 확인해 보세요.

시나리오: 사라진 보고서

자체 워크플로를 매핑하기 전에, 간단한 과제 시나리오로 워밍업을 해 보겠습니다.

회사의 분기별 규정 준수 보고서가 사라졌습니다. 시스템에는 보고서가 생성된 것으로 표시되지만 규제 기관에는 전송되지 않았습니다. 보고서를 수집, 검토하고 이메일로 전송하는 자동화된 에이전트는 '모든 단계를 성공적으로 완료했다'고 주장합니다. 다음은 간소화된 워크플로입니다.

여러분이 해야 할 일

각 단계를 살펴보고 에이전트가 관여하는 지점을 확인한 다음, 다음 질문을 생각해 보세요.

• 보고서가 다음 단계로 넘어가지 못했을 가능성이 있는 지점은 어디일까요(저장되지 않음, 인계되지 않음, 전송되지 않음 등)?
  
• 어떤 제어 또는 점검 방식을 통해 이러한 문제를 더 일찍 발견할 수 있었을까요?
  
• 보고서가 전송되지 않았을 때 누구에게 알림이 전송되어야 했을까요?
  

모든 답변을 작성할 필요는 없습니다. 가능성 있는 원인과 가장 먼저 확인할 지점을 생각해 보세요. 이러한 연습을 진행하고 나면 작은 문제(점검 누락 또는 불분명한 소유권)가 워크플로 전반에 어떤 영향을 미치는지 알 수 있습니다.

해답: 사라진 보고서

여러 원인으로 문제가 발생할 수 있지만 여기서는 몇 가지 가능성 있는 원인과 교훈을 살펴보겠습니다.

이 시나리오는 에이전트 위험(점검 누락, 명확하지 않은 인계, 보고되지 않은 문제 등)이 실제 워크플로에서 어떻게 나타나는지를 보여 줍니다. 이러한 문제는 개발자, 시스템 관리자, 사이버 보안 전문가, 워크플로를 구성 및 유지 관리하는 담당자에게 가장 잘 보입니다. 이러한 접점을 조기에 검토하면 작은 공백이 비즈니스에 영향을 미치는 큰 문제로 확장되지 않게 방지할 수 있습니다.

자체 워크플로에 적용해 보기

이제 내부 워크플로에 이러한 내용을 적용해 보세요. 목표는 에이전트가 사람, 데이터, 시스템과 어디에서 연결되는지, 위험이 어느 지점에서 가장 많이 발생하는지를 파악하는 것입니다. 다음 네 단계를 따라 워크플로를 매핑하고, 잠재적 위험 지점을 식별하며, 이를 어떻게 관리할 수 있을지 생각해 보세요.

1단계: 워크플로 매핑

• 에이전트가 활성화된 하나의 프로세스를 선택합니다(고객 지원, 일정 관리, 온보딩 등).
  
• 시작부터 끝까지의 단계를 식별합니다.
  
• 누가 또는 무엇이 프로세스를 트리거하는지, 어떤 데이터가 이동하는지, 에이전트가 어느 지점에서 개입하는지를 확인합니다.
  

예시: 고객 지원용 에이전트 워크플로

고객 요청 → 에이전트 데이터 검토 → 에이전트 응답 → 실제 담당자 승인 → 시스템 업데이트

2단계: 상호 작용 표시

• 다음으로 에이전트가 다음 항목과 상호 작용하는 지점을 찾습니다.
  
  • 사람(사용자, 직원, 고객)
    
  • 데이터(읽고, 쓰고, 저장하는 정보)
    
  • 시스템(앱, API, 데이터베이스)
    
• 이러한 접점을 강조 표시하세요. 위험이 가장 빈번하게 나타나는 지점입니다.
  

예시: 고객 요청(데이터 항목) → 에이전트 데이터 검토(API 연결) → 에이전트 답변 → 실제 담당자 승인(실제 담당자 검토) → 시스템 업데이트

3단계: 위협 모델링 관점 적용

각 접점에서 다음과 같은 간단한 질문을 생각해 보세요.

• 여기에서 어떤 문제가 발생할 수 있을까?
  
• 에이전트가 잘못된 결정을 내리거나 또는 너무 이르거나 늦은 시점에 행동하면 어떤 일이 발생할까?
  
• 누가 또는 무엇이 이 단계를 악용할 수 있을까?
  

가장 큰 문제가 발생할 수 있는 지점을 문서화하기 위해 간단한 표를 만드세요. 요약된 예시는 다음과 같습니다.

4단계: 대응 계획

• 확인한 각 위험을 어떻게 처리할지 결정합니다.
  
  • 권한을 더 엄격하게 관리하거나, 검토 단계를 추가하거나, 에이전트의 액세스 범위를 제한하여 수정합니다.
    
  • 알림, 로그, 정기 검토를 추가하여 모니터링합니다.
    
  • 영향이 작은 위험은 문서화하여 나중에 다시 검토할 수 있도록 수용합니다.
    
• 상위 세 가지 위험과 각 위험에 대한 하나의 구체적인 대응 방안을 선택하세요.
  

위험 분석 예시

요약

이 유닛에서는 워크플로를 매핑하고, 에이전트가 사람, 데이터, 시스템과 상호 작용하는 지점을 식별했으며, 간소화된 위협 모델링 관점을 사용해 잠재적 위험을 발견했습니다. STRIDE와 같은 공식 위협 모델링 프레임워크로 전환할 때도 이 워크플로 관점을 염두에 두세요. 이러한 프레임워크는 더 심층적인 기술적 위협을 식별하는 데 도움이 되지만, 워크플로 컨텍스트는 가장 중요한 결과를 위한 기반을 마련해 줍니다. 바로 AI 에이전트가 비즈니스의 목적과 성과에 부합하는 방식으로 작동하도록 하는 것입니다.