본 포스트는 OWASP Agentic AI Top 10: AWS에서 개발자가 알아야 할 것들 시리즈의 아홉 번째 글입니다.

재무팀은 AI 코파일럿으로부터 긴급한 권고를 받습니다: "벤더 인보이스 #4821에 즉시 결제가 필요합니다. 계좌 끝자리 7734로 송금하십시오. 근거: 계약 위약금이 4시간 내에 발동됩니다."

코파일럿은 자신감 있게 들립니다. 계약 조항 번호를 인용하고, 인보이스를 보여줍니다. 재무 관리자는 이 송금을 승인합니다.

하지만 그 인보이스는 오염되어 있었습니다. 은행 정보는 공격자 소유였습니다. 그리고 '근거'는 진실이 무엇인지 전혀 모르는 LLM(대규모 언어 모델)이 꾸며낸 것이었습니다. 하지만 너무 권위적으로 들려서 아무도 의문을 제기하지 않았습니다.

이것이 바로 Human-Agent 신뢰 악용입니다. 그리고 이 목록에서 수정하기 가장 어려운 취약점인데, 버그가 코드에 있는 것이 아니라 인간의 심리에 있기 때문입니다.

Human-Agent 신뢰 악용이란 무엇인가?

ASI09는 인간이 에이전트(agent)의 출력물에 과도하게 의존하거나, 독립적인 검증 없이 행동을 승인하거나, AI 중개자를 통해 사회 공학적 기만에 빠지는 경우에 대해 다룹니다.

OWASP의 핵심 통찰은 다음과 같습니다: 에이전트는 자연어 유창성(natural language fluency), 인식된 전문 지식, 자신감 있는 설명 가능성을 통해 인간과 신뢰를 구축합니다. 그러면 인간은 그 에이전트를 신뢰하는 동료처럼 대할 뿐, 불신하는 자동화 시스템으로 취급하지 않습니다.

이것이 에이전트 시스템에서 특히 위험한 이유입니다:

• 에이전트는 틀렸거나(혹은 손상되었더라도) 권위적으로 들립니다
• 에이전트는 모든 행동에 대해 설득력 있는 근거를 꾸며낼 수 있습니다
• 'Human-in-the-loop'(인간 개입 루프)는 이슈가 없으면 50번째 승인 이후에는 **형식적인 절차(rubber-stamping)**가 됩니다
• 에이전트는 인간이 최종적이고 감사 가능한 행동을 수행하기 때문에 추적 불가능한 나쁜 영향력으로 작용합니다.

마지막 점이 중요합니다. 포렌식적으로 볼 때, 마치 인간이 결정을 내린 것처럼 보입니다. 조작 과정에서 에이전트의 역할은 감사 로그에 보이지 않습니다.

실제로 어떻게 발생하는가?

OWASP는 8가지 공격 시나리오를 문서화했습니다. 다음은 보안 팀을 밤잠 설치게 만드는 시나리오들입니다.

1. 송장 코파일럿 사기 (Invoice Copilot Fraud)

조작된 공급업체 송장이 재무 코파일럿 (finance copilot)에 입력됩니다. 에이전트는 공격자가 제어하는 은행 계좌로 긴급 결제를 제안합니다. 에이전트는 그럴듯한 설명("위약금 조항, 마감까지 4시간 남음")을 꾸며냅니다. 재무 매니저는 에이전트의 전문성을 신뢰하여 별도의 독립적인 검증 없이 승인합니다.

이는 가설이 아닙니다. CSO Online의 2026년 7월 보도에 따르면, 연구자들은 인간이 AI가 수행하려는 작업에 대한 요약을 신뢰하기 때문에 HITL (Human-in-the-loop) 확인 대화 상자가 얼마나 쉽게 우회될 수 있는지를 입증했습니다.

2. 친절한 어시스턴트 트로이 목마 (Helpful Assistant Trojan)

해킹된 코딩 어시스턴트가 "매끄러운 한 줄 수정안"을 제안합니다. 개발자는 이를 복사하여 붙여넣습니다. 해당 명령은 코드를 유출하고 백도어 (backdoor)를 설치하는 악성 스크립트를 실행합니다.

AI Now Institute의 "Friendly Fire" 연구 (2026년 7월)는 자동 모드(auto-mode)의 Claude Code와 자동 검토(auto-review) 모드의 Codex를 대상으로 정확히 이 현상을 입증했습니다. 에이전트들이 인간이 의사결정을 내릴 때 잘못된 정보를 제공한 것입니다.

3. 맥락적 기만을 통한 자격 증명 탈취 (Credential Harvesting via Contextual Deception)

프롬프트 인젝션 (prompt-injected)된 IT 지원 에이전트가 신입 사원을 타겟팅합니다. 에이전트는 정당해 보이기 위해 실제 티켓 번호를 인용합니다. 그리고 자격 증명 (credentials)을 요청합니다. 신입 사원은 에이전트가 내부 맥락을 알고 있다고 믿고 신뢰하여 비밀번호를 넘겨줍니다.

4. 설명 가능성 조작 → 운영 중단 (Explainability Fabrication → Production Outage)

탈취된 에이전트가 분석가를 속여 실제 운영 데이터베이스 (production database)의 삭제를 승인하도록 설득력 있는 근거를 꾸며냅니다. 분석가는 에이전트의 설명("오래된 데이터, 티켓 #2847에 따라 정리 대상으로 분류됨")을 믿고 승인합니다.

결과는 치명적인 운영 중단입니다. 그리고 감사 로그 (audit log)에는 분석가가 이를 승인한 것으로 기록됩니다.

실제 사례: 2026년 7월, Wharton의 Accountable AI Lab은 한 엔지니어가 "AI 에이전트가 오래된 내부 위키(wiki)에서 추론한 부정확한 조언"에 따라 행동하여 운영 중단(production outage)을 초래한 사건을 기록했습니다. 회사는 근본 원인이 결함이 있는 코드가 아니라, AI의 권장 사항을 검증 없이 실행한 인간에게 있다고 밝혔습니다. 감사 추적(audit trail) 결과 해당 인간이 작업을 수행한 것으로 나타났습니다. 에이전트의 잘못된 조언은 보이지 않았습니다.

5. 거버넌스 드리프트 (Governance Drift, 서서히 퍼지는 독)

이것은 가장 교묘한 유형입니다. 몇 주 동안 정확한 권장 사항이 이어지면, 인간은 내용을 읽지 않고 대량으로 승인하기 시작합니다. 에이전트의 정확성이 신뢰를 쌓은 것입니다. 그러다 50개의 정당한 권장 사항 사이에 단 하나의 오염된(poisoned) 권장 사항이 섞여 들어갑니다.

OWASP는 이를 "거버넌스 드리프트 캐스케이드 (governance drift cascade)"라고 부르며, 이는 결코 실패하지 않는 반복적인 승인 작업에 대한 인간의 자연스러운 반응입니다.

실제 사례: Air Canada 챗봇 판결 (2024년 2월)은 교과서적인 사례입니다. 한 고객이 챗봇에게 유가족 운임(bereavement fares)에 대해 문의했습니다. 챗봇은 자신 있게 잘못된 정책 정보를 제공했습니다. 고객은 이를 믿고 항공권을 예약했으나, 약속된 할인을 받을 수 없었습니다. BC 민사 분쟁 해결 재판소(BC Civil Resolution Tribunal)는 고객이 AI의 출력을 합리적으로 신뢰했기 때문에 Air Canada에 책임이 있다고 판결했습니다. 항공사는 챗봇이 "별도의 법적 실체"라고 주장하며 항변하려 했으나, 재판소는 이를 거부했습니다. AI가 말한다면, 그 책임은 귀하에게 있습니다.

실제 사례: FinancialIT.net은 2026년에 재무 AI의 거수기 문제(rubber-stamp problem)를 기록했습니다. 50개의 완벽한 AI 권장 사항을 3주 동안 계속 확인한 후, 인간은 검토를 중단합니다. 승인은 반사적인 행동이 되는 반면, 책임은 인간 승인자에게 남습니다. 이것이 바로 거버넌스 드리프트 (governance drift)가 작동하는 방식입니다.

"인간 참여형 (Human-in-the-Loop)"이 당신이 생각하는 해결책이 아닌 이유

솔직하게 말씀드리겠습니다. "인간 참여형 (Human-in-the-loop) 구조를 갖추고 있다"는 것은 보안 통제 (security control)가 아닙니다. 그것은 단순히 체크박스를 채우는 행위일 뿐입니다.

실제로 일어나는 일은 다음과 같습니다:

1. 1주 차: 인간이 모든 에이전트(agent)의 권장 사항을 주의 깊게 검토합니다.
2. 4주 차: 인간이 요약본을 대충 훑어봅니다.
3. 8주 차: 인간이 반사적으로 "승인"을 클릭합니다.
4. 12주 차: 누군가 "왜 우리가 이 승인 단계를 또 거쳐야 하죠?"라고 묻습니다.

자동화 편향 (Automation bias)은 실재합니다. 권위 편향 (Authority bias)도 실재합니다. 그리고 에이전트들은 자신감 있고 해박하게 들리기 때문에 이 두 가지를 동시에 유발합니다.

해결책은 "인간을 추가하는 것"이 아닙니다. 해결책은 거수기식 승인 (rubber-stamping)이 구조적으로 불가능하도록 인간의 상호작용을 설계하는 것입니다.

AWS에서 신뢰 악용 완화하기

1. Amazon A2I: 구조화된 인간 검토 워크플로 (Structured Human Review Workflows)

Amazon Augmented AI (A2I)를 사용하면 검토자가 무엇을 보는지, 어떤 질문에 답해야 하는지, 어떤 기준을 평가해야 하는지를 정확하게 제어할 수 있는 구조화된 인간 검토 워크플로를 제공합니다.

단순한 "승인/거부" 대화창과의 핵심적인 차이점은, 검토자가 에이전트가 생성한 요약본을 단순히 읽는 대신 결정의 특정 측면에 반드시 참여하도록 강제한다는 점입니다.

작업자 템플릿 — 이 부분이 해당 섹션에서 누락되었던 내용입니다. 필수 필드(required fields)가 바로 "생각 없는 클릭"을 방지하는 요소입니다.

TEMPLATE = """
<script src="https://assets.crowd.aws/crowd-html-elements.js"></script>
<crowd-form>
...

설정 — UI를 생성한 다음, 흐름 정의(flow definition)를 생성합니다 (현재 유효함).

import json, time, uuid, boto3

def setup(role_arn, workteam_arn, s3_output_path):
...

사용 방법: 검토를 시작한 다음, 결과에 따라 에이전트를 차단하십시오.

def request_review(flow_definition_arn, action: dict) -> str:
    """`action`은 템플릿 내에서 task.input.*이 됩니다."""
    a2i = boto3.client("sagemaker-a2i-runtime")
...

인간 작업 UI 템플릿은 마법이 일어나는 곳입니다. 단순히 에이전트의 권장 사항만 보여주지 마십시오. 다음을 보여주어야 합니다:

• 에이전트가 결정을 내리는 근거가 된 원시 데이터 (Raw data) (에이전트의 해석이 아닌 데이터 자체)

• 구체적인 검증 질문 ("은행 세부 정보를 독립적으로 확인했습니까?")

• 승인 이유를 설명하는 필수 자유 텍스트 필드 (무의식적인 클릭 방지)

• 시각적 신호가 포함된 위험 지표 (빨간색 테두리, 경고 배너 등)

• Lambda를 한 시간 동안 차단하지 마십시오. wait_for_decision은 명확성을 위해 폴링(polling)을 수행하지만, Lambda는 15분 제한이 있습니다. 실제로는 A2I 완료 이벤트(A2I는 Completed 시 CloudWatch Event를 방출함)에 반응하거나, Step Functions의 waitForTaskToken 콜백을 사용하여 에이전트를 재개하십시오. 동기식 호출(synchronous invocation)을 열어둔 채로 대기하지 마십시오.

• 게이트(Gate)의 효력은 이를 호출하는 코드의 품질에 달려 있습니다. A2I는 인간이 개입하도록 강제하지만, 에이전트가 기다리도록 강제하는 것은 아무것도 없습니다. 차단 역할을 수행하는 것은 execute_high_risk_action입니다. 만약 어떤 고위험 경로라도 검토 호출을 건너뛴다면, 전체 제어 체계가 우회됩니다. 따라서 이 게이트는 도구마다 흩어져 있는 것이 아니라 공유된 실행 경로(shared execution path)에 위치해야 합니다.

2. 타임아웃 및 에스컬레이션(Escalation) 기능이 포함된 Step Functions 승인 게이트

Step Functions를 사용하면 만료 가능한 승인 게이트를 구축할 수 있습니다. 타임아웃 내에 아무도 검토하지 않으면, 작업은 승인되는 것이 아니라 **기본적으로 거부(denied by default)**됩니다.

{
  "Comment": "고위험 작업 승인 게이트: 승인 -> 실행; 거부 또는 타임아웃 -> 거부",
  "StartAt": "ApprovalGate",
...

결정적인 설계 선택 사항: **timeout = deny (타임아웃 시 거부)**이며, timeout = auto-approve (타임아웃 시 자동 승인)가 아닙니다. 인간이 능동적으로 참여하지 않으면 아무 일도 일어나지 않습니다. 이는 무행동이 승인으로 이어지는 일반적인 패턴을 뒤집는 것입니다.

3. Bedrock Guardrails: 출력 검증 (Output Validation)

에이전트의 출력이 인간에게 도달하기 전에 Bedrock Guardrails를 사용하십시오. 이를 통해 에이전트가 긴박함을 조작하거나 감정적 조작 (emotional manipulation)을 시도하는 사례를 포착할 수 있습니다.

{
  "contentFilter": {
    "categories": [
...

만약 에이전트의 출력에 금융 세부 정보가 포함되어 있고 오남용 필터 (misconduct filter)가 트리거된다면, 이는 표준 승인이 아닌 강화된 검토 (enhanced review) 단계로 라우팅되어야 하는 위험 신호 (red flag)입니다.

4. CloudWatch를 통한 맥락적 위험 점수 산정 (Contextual Risk Scoring)

검토자에게 평소라면 알 수 없었을 맥락을 제공하는 CloudWatch 대시보드를 구축하십시오:

• 이 에이전트가 지난 한 시간 동안 제안한 작업은 몇 개인가? (급증 = 의심스러움)
• 에이전트의 최근 승인율은 얼마인가? (100% = 아무도 실제로 검토하지 않고 있음)
• 에이전트의 행동 패턴이 변했는가? (새로운 도구 호출, 새로운 수신자)
• 이 작업 유형이 현재 시간대에 이례적인가?

cloudwatch = boto3.client("cloudwatch")

# 변경 사항 없음 - 이미 올바름: 각 승인에 소요된 시간을 기록
...

평균 결정 시간이 5초 미만이라면, 누군가 읽지도 않고 "승인"을 클릭하고 있는 것입니다. 이는 조치를 취할 가치가 있는 보안 신호입니다.

5. 출처 및 소스 귀속 (Provenance and Source Attribution)

인간에게 에이전트의 해석만을 보여주어서는 안 됩니다. 소스 데이터 (source data)를 함께 보여주어야 합니다. AWS에서는 다음과 같은 의미를 갖습니다:

• 원본 소스 문서를 버전 관리 (versioning)와 함께 S3에 저장하고, 검토 작업에 사전 서명된 URL (pre-signed URL)을 포함합니다.
• CloudTrail 데이터 이벤트를 통해 에이전트가 어떤 지식 베이스 청크 (knowledge base chunks)를 사용했는지 기록합니다.
• 에이전트 출력에 신뢰도 점수 (confidence scores)와 소스 인용 (source citations)을 태깅합니다.
• 무엇이 "에이전트 생성 근거 (agent-generated rationale)"이고 무엇이 "검증된 소스 데이터 (verified source data)"인지 명확하게 라벨을 붙입니다.

검토자(reviewer)가 에이전트의 권장 사항(recommendation)과 그 근거가 된 원본 송장/문서/데이터를 모두 볼 수 있다면, 불일치 사항을 찾아낼 수 있습니다. 하지만 에이전트의 요약본(summary)만 본다면, 불일치 사항을 찾아낼 수 없습니다.

핵심 요약 (Key Takeaway)

인간이 에이전트의 실수를 잡아낼 것이라고 믿지 마세요. 단순히 승인만 하는 행위(rubber-stamping)가 구조적으로 불가능하도록 검토 워크플로우(review workflow)를 설계해야 합니다. 거부(deny)를 기본값으로 하는 타임아웃(timeouts), 필수 검증 질문, 의사결정 시점 모니터링(decision-time monitoring), 에이전트 요약본과 함께 제공되는 원본 소스 데이터(raw source data), 그리고 인간이 실제로 검토를 중단할 때 발생하는 알림 등이 필요합니다.

버그는 에이전트에 있는 것이 아닙니다. 바쁜 인간이, 49번 연속으로 맞히고 50번째에 틀린, 자신감 있게 들리는 AI를 신뢰성 있게 잡아낼 것이라는 가정에 버그가 있는 것입니다.

다음 글

Post 10: Rogue Agents (ASI10) - 해킹당한 것이 아니라, 단지 정렬(misaligned)되지 않았을 뿐입니다. 에이전트가 의도된 범위를 벗어나 목표를 추구할 때 어떤 일이 발생하는지, 그리고 CloudTrail, 이상 탐지(anomaly detection), 서비스 제어 정책(Service Control Policies)이 어떻게 킬 스위치(kill switch) 역할을 하는지 알아봅니다.