금융권 AI 에이전트 도입 시 반드시 지켜야 할 보안 아키텍처 설계 가이드 — 2026 금융보안원 기준·실전 사례 5선·코드까지 총정리
이 글을 끝까지 읽으면, 금융보안원이 레드팀 평가에 적용하기 시작한 'AI 에이전트 보안 평가기준'의 방향을 이해하고, 우리 회사 에이전트 아키텍처에 바로 적용할 7가지 설계 원칙과 실행 가능한 통제 코드 3종을 손에 쥐게 됩니다.
안녕하세요. 오랜 기간 개발과 보안 현장을 오가며 살아온 ICT리더 리치입니다. 요즘 금융권 보안 담당자분들을 만나면 거의 같은 이야기를 듣습니다. "위에서는 AI 에이전트 빨리 붙이라고 하는데, 보안 검토 기준이 뭔지 아무도 모른다"는 하소연이죠.
솔직히 저도 처음엔 챗봇 보안 점검하던 체크리스트를 그대로 들고 들어갔다가 크게 당황한 적이 있습니다. 챗봇은 '말'만 하지만, 에이전트는 계좌를 조회하고, 메일을 읽고, 시스템에 쓰기 작업까지 '행동'을 합니다. 프롬프트 한 줄이 곧 실행 명령이 되는 구조에서 기존 점검표는 절반쯤 무용지물이었습니다.
오늘은 2026년 6월 개정된 금융분야 AI 가이드라인, 10월 공개된 금융보안원 AI 에이전트 보안 평가기준 초안, 그리고 실제로 터졌던 사고 사례들을 엮어서 "금융권 AI 에이전트는 어떤 구조로 설계해야 감사·레드팀·실제 공격을 모두 버틸 수 있는가"를 아키텍처 관점에서 정리해 드리겠습니다.
📌 바로가기 목차
 |
| 모델 외부의 정책 통제와 다층 방어를 중심으로 금융 AI 에이전트의 보안 구조를 설계합니다. |
1. 왜 지금인가 — 2026년 금융권 AI 에이전트 규제 지형 총정리
혹시 "AI 에이전트 보안 기준은 아직 없으니 일단 PoC부터 하자"는 말, 회의실에서 들어보셨나요? 2025년까지는 어느 정도 통하던 말이었습니다. 하지만 2026년 들어 상황이 완전히 달라졌습니다.
1월 22일 인공지능기본법이 시행되면서 '고영향 AI'에 대한 법적 의무가 생겼고, 금융위원회는 6월 18일 금융분야 인공지능 가이드라인 개정안을 발표했습니다. 개정안은 보안성을 포함한 7대 원칙을 제시하면서, 최종 판단과 책임은 사람이 지는 '인간 관여 원칙'과 CEO 등 경영진의 역할·책임을 명확히 했습니다. 시행일(6월 22일)에 맞춰 세부 이행 문서인 'AI 위험관리 프레임워크'와 'AI 보안 안내서'도 함께 배포됐죠.
결정타는 10월에 나왔습니다. 금융보안원이 6개 영역·17개 점검 항목으로 구성된 'AI 에이전트 보안 평가기준' 초안을 마련해 전 금융권 AI 레드팀 평가에 적용하기로 한 겁니다. 핵심은 점검 범위가 탈옥·시스템 프롬프트 유출 같은 '모델 수준'에서 권한 관리, 도구 사용 승인, 결과 검증, 자율 행동 제한 같은 '실행 수준'으로 넓어졌다는 점입니다. 연말까지 시범 적용 후 2027년 정식 기준이 될 예정입니다.
그런데 현장은 아직 준비가 덜 됐습니다. 국회에 제출된 금융감독원 자료(2026년 8월 기준)를 보면, 국내 20개 은행이 수행한 모의해킹 78건 중 AI 에이전트를 활용한 건은 9건, 약 11.5%에 불과했습니다. 인터넷은행 3사는 8건 중 4건으로 비중이 가장 높았지만, 지방은행 다수와 특수은행은 한 건도 없었죠.
정리하면 이렇습니다. 규제는 '실행 통제'를 보겠다고 선언했는데, 상당수 조직은 아직 '모델 응답 점검'에 머물러 있습니다. 이 간극을 메우는 게 바로 아키텍처 설계입니다.
다음 섹션에서는 챗봇 시절의 위협 모델이 에이전트에서 왜 통하지 않는지, 표 하나로 비교해 보겠습니다.
2. 챗봇 vs AI 에이전트 위협 모델 비교 — 보안팀이 가장 많이 하는 실수
경험상 보안팀이 가장 많이 하는 실수는 "시스템 프롬프트를 튼튼하게 쓰면 된다"고 믿는 것입니다. 시스템 프롬프트에 "절대 고객정보를 외부로 보내지 마라"라고 적는 건 방어가 아니라 '부탁'에 가깝습니다. LLM은 확률적으로 동작하기 때문에, 외부에서 들어온 문서·메일·웹페이지 안에 숨은 지시문이 그 부탁을 덮어쓸 수 있습니다.
챗봇이 잘못 답하면 '틀린 답변'으로 끝납니다. 하지만 에이전트가 속으면 '틀린 행동'이 일어납니다. 금융보안원이 예로 든 것처럼, 목표를 받은 에이전트가 성능을 높이겠다며 백신을 끄거나, 비밀번호 재설정 메일을 읽고 스스로 비밀번호를 바꿔버릴 수도 있는 것이죠. 아래 표로 차이를 정리했습니다.
| 구분 | 생성형 AI 챗봇 | AI 에이전트 |
|---|---|---|
| 사고의 결과 | 잘못된 정보 제공·민감정보 노출 | 이체·정보 변경·데이터 반출 등 실제 거래 발생 |
| 주 공격 벡터 | 직접 프롬프트 인젝션·탈옥 | 간접 프롬프트 인젝션(메일·문서·CRM 데이터), 도구 오남용 |
| 신뢰 경계 | 사용자 ↔ 모델 1개 경계 | 사용자·외부 데이터·도구·타 에이전트 등 다중 경계 |
| 신원(Identity) | 사용자 세션으로 충분 | 에이전트 자체가 비인간 계정(NHI) — 별도 ID·권한 필요 |
| 핵심 통제 위치 | 입력·출력 필터 | 입출력 필터 + 도구 호출 정책 엔진 + 네트워크 egress + 감사 로그 |
| 레드팀 점검 범위 | 탈옥, 시스템 프롬프트 유출 | 권한·도구 승인·결과 검증·자율 행동 제한까지 확대 |
표를 보면 결론은 하나입니다. 모델을 신뢰 경계 '안쪽'에 두면 안 됩니다. LLM은 언제든 속을 수 있는 구성요소로 가정하고, 실제 실행 권한은 그 바깥의 결정론적 시스템이 쥐고 있어야 합니다. 여러분 회사의 PoC 구조도는 지금 LLM이 API 키를 직접 들고 있지 않나요?
다음 섹션에서 이 원칙을 7가지 설계 규칙으로 풀어보겠습니다.
3. 반드시 지켜야 할 보안 아키텍처 7대 설계 원칙
여기서부터가 오늘 글의 핵심입니다. 금융분야 AI 가이드라인의 보안성·인간 관여 원칙, 금융보안원 에이전트 평가기준의 실행 수준 통제 방향, OWASP의 Agentic AI 위협 분류를 아키텍처 언어로 번역하면 아래 7가지로 수렴합니다.
생각보다 새로운 개념은 별로 없습니다. 제로트러스트, 최소권한, 직무분리처럼 금융권이 20년 넘게 써온 원칙을 '사람이 아닌 실행 주체'에게 똑같이 적용하는 것뿐이죠. 문제는 그걸 LLM 앞에서 자꾸 잊는다는 겁니다.
- ① 에이전트 전용 신원(Agent Identity): 에이전트마다 고유 서비스 ID를 발급하고, 수명이 짧은 토큰(분 단위)으로 인증합니다. 고객 대신 행동할 때는 고객 위임 토큰과 에이전트 ID를 함께 기록해 '누가, 누구를 대신해' 실행했는지 추적 가능해야 합니다.
- ② 도구 허용 목록 + 최소권한: 에이전트가 호출할 수 있는 도구(API)를 명시적으로 열거하고, 조회(read)와 변경(write)을 분리합니다. 상담 에이전트에 이체 API가 '혹시 몰라서' 붙어 있다면 그 자체가 취약점입니다.
- ③ 정책 집행 지점(PEP) 분리: LLM은 도구 호출을 '제안'만 하고, 실행 여부는 별도의 정책 게이트웨이가 결정합니다. 게이트웨이는 결정론적 코드여야 하며, LLM이 우회할 수 있는 경로가 네트워크상 존재하지 않아야 합니다.
- ④ 신뢰 데이터·비신뢰 데이터 분리: 외부 메일, 고객 입력 폼, 웹 문서처럼 공격자가 쓸 수 있는 데이터는 '지시'가 아닌 '데이터'로 태깅합니다. 비신뢰 데이터가 컨텍스트에 들어온 세션은 고위험 도구 사용을 자동으로 잠그는 방식이 효과적입니다.
- ⑤ 출력·네트워크 egress 통제: 응답 속 URL·이미지 링크는 허용 도메인만 통과시키고, 에이전트 실행 환경의 아웃바운드 통신은 기본 차단합니다. 뒤에서 볼 EchoLeak·ForcedLeak 모두 '밖으로 나가는 길'이 열려 있어서 성립한 공격입니다.
- ⑥ 위험 기반 사람 승인(HITL): 금액·대상·되돌릴 수 있는지 여부로 위험도를 매기고, 기준 이상은 담당자 승인 큐로 넘깁니다. 승인 화면에는 에이전트의 '요약'이 아니라 실제 실행될 파라미터 원본을 보여줘야 승인자가 속지 않습니다.
- ⑦ 위변조 불가 감사 로그 + 킬스위치: 프롬프트, 참조한 데이터 출처, 도구 호출, 정책 판단 결과를 해시 체인 등으로 무결성 있게 남기고, 이상 징후 시 에이전트 단위로 즉시 정지할 수 있는 스위치와 호출량 제한(rate limit)을 둡니다.
💡 실전 팁: 7가지를 한 번에 다 하려다 PoC가 멈추는 경우를 자주 봤습니다. 우선순위를 정하라면 ③ 정책 게이트웨이 → ⑤ egress 차단 → ⑦ 감사 로그 순서를 권합니다. 이 세 가지만 있어도 '속은 에이전트가 실제 피해를 내는 경로'의 대부분이 끊깁니다.
 |
| 에이전트의 호출 제안은 권한과 위험도 검사를 거치며, 승인 대기 작업은 사람의 검토 후 처리합니다. |
4. 실전 사례 5선 — 실제 사고와 국내 금융사 대응에서 배우는 교훈
"원칙은 알겠는데 정말 그런 일이 일어나나요?" 강의 때마다 받는 질문입니다. 의외로 이미 많이 일어났습니다. 아래 세 건은 해외에서 실제 공개된 사고·취약점이고, 두 건은 국내 금융사가 공개한 대응 사례입니다. 각 사례마다 '아키텍처 교훈'을 하나씩 뽑아 보겠습니다.
사례 ① EchoLeak — 메일 한 통으로 Copilot이 사내 데이터를 내보낸 제로클릭 공격
2025년 6월 공개된 CVE-2025-32711(CVSS 9.3)은 Aim Security가 Microsoft 365 Copilot에서 찾아낸 취약점입니다. 공격자는 평범해 보이는 메일 안에 악성 지시문을 마크다운으로 숨겨 보내기만 합니다. 이후 직원이 Copilot에게 업무 질문을 하면, RAG 엔진이 그 메일과 사내 민감 데이터를 같은 컨텍스트에 함께 불러오고, 데이터가 신뢰받는 Microsoft 도메인 URL을 경유해 외부로 새어나가는 구조였습니다. 사용자는 아무것도 클릭하지 않았습니다.
Microsoft가 서버 측에서 패치했고 실제 악용 정황은 보고되지 않았지만, 연구진은 이를 'LLM 스코프 위반'이라 불렀습니다. 외부의 비신뢰 입력이 내부 권한 범위의 데이터에 접근하게 된 것이죠.
🏛️ 아키텍처 교훈: 외부 메일·문서를 읽는 에이전트는 비신뢰 데이터가 섞인 순간 민감 데이터 접근과 외부 링크 생성을 함께 잠가야 합니다(원칙 ④⑤).
사례 ② ForcedLeak — 5달러짜리 만료 도메인이 CRM 고객정보 유출 통로가 되다
2025년 9월 Noma Security가 공개한 Salesforce Agentforce 취약점(CVSS v4.0 기준 9.4)은 금융권 CRM 담당자라면 꼭 아셔야 합니다. 공격자는 외부인이 잠재고객 정보를 남기는 Web-to-Lead 양식을 노렸습니다. 다른 필드는 글자 수 제한이 짧았지만 설명 필드는 4만 2천 자까지 허용돼, 여러 단계의 숨은 지시문을 넣기에 충분했습니다.
나중에 직원이 에이전트에게 해당 리드를 물어보면, 에이전트가 숨은 지시대로 리드 이메일 주소들을 이미지 URL에 붙여 외부 서버로 전송했습니다. 그 서버 도메인은 Salesforce의 콘텐츠 보안 정책(CSP)이 신뢰 목록에 올려두었다가 만료된 도메인이었고, 연구진은 이를 단돈 5달러에 사들였습니다. Salesforce는 이후 신뢰 URL 허용 목록 강제 적용과 해당 도메인 재확보로 대응했습니다.
🏛️ 아키텍처 교훈: 고객이 직접 입력하는 모든 필드는 공격 입력면입니다. 허용 도메인 목록 자체도 자산으로 관리해 만료·소유권 변경을 정기 점검해야 합니다(원칙 ④⑤).
사례 ③ Arup 딥페이크 화상회의 — 사람 승인(HITL)만으로는 부족한 이유
2024년 1월, 글로벌 엔지니어링 기업 Arup의 홍콩 직원은 CFO를 비롯한 임원들이 참석한 것처럼 보이는 화상회의에 들어갔습니다. 회의 참석자는 모두 딥페이크였고, 직원은 지시에 따라 여러 차례에 걸쳐 총 2억 홍콩달러(약 2,500만 달러)를 송금했습니다.
이 사건은 AI 에이전트 사고는 아니지만, 에이전트 설계에서 'HITL'을 어떻게 만들어야 하는지 정확히 보여줍니다. 승인자가 확인하는 정보 자체가 조작될 수 있다면, 사람 승인은 형식적 절차가 되어버립니다. 에이전트가 만든 요약 화면만 보고 승인 버튼을 누르는 구조도 똑같은 함정에 빠질 수 있습니다.
🏛️ 아키텍처 교훈: 고액·고위험 승인은 에이전트·요청 채널과 분리된 별도 경로(콜백, 별도 단말 인증)로 원본 파라미터를 재확인해야 합니다(원칙 ⑥).
사례 ④ 카카오뱅크 — 자체 AI 레드팀과 AI 취약점 버그바운티
2026년 5월 금융보안원 'AI 활용 및 안전성·신뢰성 강화 세미나'에서 카카오뱅크는 자체 AI 레드팀 운영, 제3자 모의해킹, AI 취약점 대상 버그바운티를 병행하고 있다고 소개했습니다. 앞서 본 은행권 통계에서도 인터넷은행 3사가 AI 에이전트 활용 모의해킹 비중이 가장 높았던 것과 맥을 같이합니다.
제가 주목하는 부분은 '내부 + 외부 + 크라우드' 3중 검증 구조입니다. 프롬프트 인젝션은 공격 문장의 변형이 무한에 가까워 내부 인력만으로는 커버리지가 나오지 않습니다. 외부 시선을 상시로 끌어들이는 구조 자체가 방어 아키텍처의 일부인 셈이죠.
🏛️ 아키텍처 교훈: 레드팀이 '실행 수준'까지 점검할 수 있도록 운영과 동일한 정책 게이트웨이·도구 구성을 갖춘 스테이징 환경을 별도로 설계해야 합니다.
사례 ⑤ 삼성생명 — 가드레일·마이크로세그멘테이션·제로트러스트 전환
같은 세미나에서 삼성생명은 가드레일 설정과 임직원 교육에 더해, 마이크로세그멘테이션과 제로트러스트 기반 업무 프로세스 전환을 대응 방향으로 제시했습니다. 모델 앞단의 필터(가드레일)와 네트워크 뒷단의 분할(마이크로세그멘테이션)을 함께 가져간다는 점이 핵심입니다.
가드레일은 뚫릴 수 있습니다. 하지만 에이전트가 올라간 세그먼트에서 핵심계 DB나 외부 인터넷으로 가는 경로가 애초에 없다면, 뚫려도 피해 반경(blast radius)이 제한됩니다. 이게 바로 금융권이 망분리에서 쌓아온 노하우를 AI 시대에 살리는 방법이라고 봅니다.
🏛️ 아키텍처 교훈: 모델 레벨 방어(가드레일)와 인프라 레벨 방어(세그멘테이션)는 대체 관계가 아니라 반드시 함께 가는 다층 방어입니다(원칙 ⑤).
⚠️ 주의: 사례 ①②는 모두 벤더가 패치를 완료했지만, 같은 패턴(비신뢰 입력 + 민감 데이터 접근 + 외부 전송 경로)은 자체 구축 에이전트에서도 그대로 재현될 수 있습니다. SaaS 패치 소식만 보고 안심하지 마시고, 사내 에이전트에도 동일 시나리오로 레드팀 테스트를 수행하세요.
5. 계층별 레퍼런스 아키텍처 비교표 — 어디에 어떤 통제를 둘까
설계 리뷰를 해보면 통제 자체는 다 있는데 '위치'가 잘못된 경우가 많습니다. 예를 들어 민감정보 마스킹을 LLM 프롬프트로만 처리하거나, 권한 검사를 에이전트 프레임워크 내부 함수로만 구현해 두는 식이죠. 둘 다 LLM이 속으면 함께 무너지는 위치입니다.
아래는 제가 금융권 에이전트 설계 리뷰 때 기준선으로 쓰는 6계층 레퍼런스 구조입니다. 요청이 위에서 아래로 흐르고, 각 계층은 아래 계층을 신뢰하지 않는다는 전제로 읽으시면 됩니다.
| 계층 | 핵심 통제 | 막는 위협 |
|---|---|---|
| L1 채널·인증 | 고객·직원 강한 인증, 세션 바인딩, 위임 토큰 발급 | 계정 탈취, 타인 명의 요청 |
| L2 입력 가드레일 | 인젝션 탐지, 비신뢰 데이터 태깅, 컨텍스트 출처 기록 | 직접·간접 프롬프트 인젝션 |
| L3 에이전트 런타임 | 격리 컨테이너, 에이전트 전용 ID, 단기 토큰, 반복 횟수·비용 상한 | 무한 루프, 자원 고갈, 자격증명 탈취 |
| L4 정책 게이트웨이 | 도구 허용 목록, 권한 범위 검사, 금액 기반 HITL, 해시 체인 감사 로그 | 과도한 위임, 도구 오남용, 무단 거래 |
| L5 데이터·출력 | 가명처리, 행 단위 접근통제, 출력 DLP, URL·이미지 허용 목록 | 개인신용정보 유출, 0-click 데이터 반출 |
| L6 네트워크·관제 | egress 기본 차단, 마이크로세그멘테이션, SIEM 연동, 킬스위치 | 외부 C2 통신, 측면 이동, 사고 확산 |
특히 L4 정책 게이트웨이와 L6 egress 차단은 LLM이 아무리 정교하게 속아도 우회할 수 없는 '결정론적 방어선'이라는 점에서 가장 투자 효율이 높습니다. 2024년 8월 금융위원회가 발표한 망분리 개선 로드맵 역시 열거식 규칙에서 '목표·원칙 중심' 규제로 전환하고 금융회사가 자체 리스크 평가로 세부 통제를 정하도록 방향을 잡았는데, 이 6계층 구조가 바로 그 '자체 통제 설계'의 뼈대가 될 수 있습니다.
결론: 통제의 개수보다 '위치'가 중요합니다. LLM 바깥에 놓인 통제만이 진짜 통제입니다.
6. 도입 단계별 보안 체크리스트 (주의사항 포함)
"그래서 다음 주 회의에 뭘 들고 가면 되나요?" 이 질문에 답하기 위해 기획부터 운영까지 단계별로 꼭 확인할 항목을 정리했습니다. 금융분야 AI 가이드라인의 경영진 책임·인간 관여 원칙과 금융보안원 평가기준이 보는 실행 통제 관점을 함께 반영했습니다.
특히 6단계는 한 번 하고 끝나는 게 아닙니다. 에이전트에 도구가 하나 추가될 때마다 1단계로 돌아가 위험도를 다시 매겨야 합니다.
- ☑ 1단계 기획 — 고영향 여부·업무 위험도 분류: 신용평가·여신 심사처럼 인공지능기본법상 고영향 AI에 해당할 수 있는 업무인지 법무팀과 먼저 판단하고, 에이전트가 수행할 업무를 조회·안내·변경·거래로 등급화합니다.
- ☑ 2단계 설계 — 위협 모델링과 도구 명세서: 에이전트가 읽는 모든 데이터 출처와 호출하는 모든 도구를 목록화하고, 비신뢰 입력 경로를 표시합니다. 도구별 권한·HITL 기준·롤백 가능 여부를 명세서로 남깁니다.
- ☑ 3단계 구축 — 결정론적 통제 우선 구현: 정책 게이트웨이, egress 차단, 출력 DLP, 감사 로그를 에이전트 기능보다 먼저 만듭니다. 아래 실전 코드 섹션이 그 출발점입니다.
- ☑ 4단계 검증 — 실행 수준 레드팀: 탈옥 테스트에 그치지 말고 EchoLeak·ForcedLeak형 간접 인젝션 시나리오, 권한 상승, 도구 연쇄 호출, 승인 화면 조작까지 점검합니다. 외부 모델·라이브러리의 공급망 검증도 포함합니다.
- ☑ 5단계 승인 — 경영진 보고와 책임자 지정: 잔여 위험과 수용 근거를 CEO·이사회 보고 체계에 올리고, 에이전트별 업무 책임자(사람)를 지정합니다. 가이드라인이 강조하는 '최종 판단·책임은 사람' 원칙의 실체가 여기서 만들어집니다.
- ☑ 6단계 운영 — 상시 관제와 킬스위치 훈련: 정책 거부율·승인 대기 건수·외부 링크 차단 건수를 SIEM 지표로 관제하고, 분기 1회 이상 에이전트 긴급 정지 모의훈련을 실시합니다.
⚠️ 주의: 금융보안원 AI 에이전트 보안 평가기준은 2026년 10월 현재 초안·시범 적용 단계로, 2027년 정식 기준에서 항목이 바뀔 수 있습니다. 체크리스트를 특정 항목 번호에 맞추기보다 '실행 수준 통제'라는 방향에 맞춰 설계해 두는 편이 재작업을 줄입니다.
이제 체크리스트 3단계의 핵심 통제를 실제 코드로 구현해 보겠습니다. 그 다음 FAQ에서 자주 헷갈리는 부분을 정리했어요.
💻 실전 코드 — 바로 쓰는 금융 AI 에이전트 보안 통제 3종
아래 세 코드는 앞서 강조한 '결정론적 방어선' 세 가지, 즉 정책 게이트웨이(L4), 출력 DLP(L5), 네트워크 egress 차단(L6)을 Python과 Kubernetes YAML로 구현한 것입니다. 모두 직접 실행해 동작을 확인한 코드이며, REPLACE_THIS 표시 부분만 환경에 맞게 바꾸면 됩니다.
▶ 실전 코드 ① — 도구 호출 정책 게이트웨이 + 해시 체인 감사 로그 (Python)
LLM이 "이체 도구를 호출하겠다"고 요청하면, 이 게이트웨이가 허용 목록·권한 범위·금액 기준을 차례로 검사해 허용(ALLOW), 거부(DENY), 사람 승인 대기(PENDING) 중 하나로 판정합니다. 모든 판정은 직전 로그의 해시를 물고 있는 JSONL 감사 로그로 남아, 중간 한 줄만 수정해도 위변조가 드러납니다.
# 금융 AI 에이전트 도구 호출 정책 게이트웨이 (PEP)
# 핵심: LLM은 '요청'만 하고, 실행 여부는 결정론적 코드가 판단한다
import hashlib, json, os, time
# 도구 허용 목록 — 권한 범위(scope)와 사람 승인(HITL) 기준 금액(원)
TOOL_POLICY = {
"account_lookup": {"scope": "read", "hitl_over": None},
"transfer_funds": {"scope": "write", "hitl_over": 1_000_000},
"update_customer": {"scope": "write", "hitl_over": 0}, # 항상 사람 승인
}
AUDIT_FILE = os.getenv("AGENT_AUDIT_LOG", "agent_audit.jsonl")
_prev_hash = "GENESIS"
def audit(event: dict) -> None:
"""해시 체인 감사 로그 — 한 줄이라도 수정되면 이후 체인이 모두 깨진다"""
global _prev_hash
event.update(prev=_prev_hash, ts=time.time())
body = json.dumps(event, ensure_ascii=False, sort_keys=True)
_prev_hash = event["hash"] = hashlib.sha256(body.encode()).hexdigest()
with open(AUDIT_FILE, "a", encoding="utf-8") as f:
f.write(json.dumps(event, ensure_ascii=False) + "\n")
def authorize(agent_id: str, granted: set, tool: str, args: dict) -> str:
policy = TOOL_POLICY.get(tool)
if policy is None: # 허용 목록 밖의 도구는 무조건 차단
decision = "DENY:unknown_tool"
elif policy["scope"] not in granted: # 에이전트에 부여된 권한 초과
decision = "DENY:scope"
elif policy["hitl_over"] is not None and args.get("amount", 0) >= policy["hitl_over"]:
decision = "PENDING:human_approval" # 고위험 → 담당자 승인 큐로 이관
else:
decision = "ALLOW"
audit({"agent": agent_id, "tool": tool, "args": args, "decision": decision})
return decision
if __name__ == "__main__":
print(authorize("loan-agent-01", {"read"}, "transfer_funds", {"amount": 5_000_000}))
print(authorize("cs-agent-02", {"read", "write"}, "transfer_funds", {"amount": 3_000_000}))
print(authorize("cs-agent-02", {"read", "write"}, "transfer_funds", {"amount": 50_000}))
print(authorize("cs-agent-02", {"read"}, "delete_all_logs", {}))실행하면 순서대로 DENY:scope(조회 권한만 가진 여신 에이전트의 이체 시도), PENDING:human_approval(100만 원 이상 이체), ALLOW(5만 원 이체), DENY:unknown_tool(허용 목록에 없는 도구)이 출력됩니다. 운영 환경에서는 이 함수를 별도 서비스(예: FastAPI)로 띄우고, 에이전트 런타임이 실제 업무 API에 직접 접근할 수 없도록 네트워크를 막는 것이 전제입니다. 그래야 LLM이 게이트웨이를 '건너뛰는' 경로가 사라집니다.
💡 실전 팁: 감사 로그 파일은 에이전트 계정이 쓰기만 하고 수정·삭제는 못 하도록 WORM 스토리지나 객체 잠금(Object Lock)이 걸린 버킷으로 주기적으로 넘기세요. 해시 체인의 마지막 값만 별도 시스템에 하루 한 번 기록해도 위변조 탐지력이 크게 올라갑니다.
 |
| 전용 신원부터 감사 로그와 긴급 정지까지, 금융 AI 에이전트의 실행 권한을 통제하는 설계 원칙입니다. |
▶ 실전 코드 ② — 에이전트 응답 출력 DLP 필터: URL·이미지 차단 + 개인정보 마스킹 (Python)
EchoLeak·ForcedLeak의 공통 유출 경로였던 '자동 로딩 이미지'와 '외부 URL'을 응답 단계에서 차단하고, 주민등록번호·카드번호를 마스킹하는 필터입니다. 표준 라이브러리만 쓰기 때문에 어떤 에이전트 프레임워크 뒤에도 바로 붙일 수 있습니다.
# 에이전트 응답 출력 필터 — 유출 경로(URL·이미지) 차단 + 민감정보 마스킹
import re
from urllib.parse import urlparse
ALLOWED_DOMAINS = {"www.mybank.co.kr", "help.mybank.co.kr"} # REPLACE_THIS
MD_IMAGE_RE = re.compile(r"!\[[^\]]*\]\([^)]*\)") # 자동 로딩되는 이미지 비컨
URL_RE = re.compile(r"https?://[^\s)\]\"'<>]+")
RRN_RE = re.compile(r"\b(\d{6})-?([1-4])\d{6}\b") # 주민등록번호
CARD_RE = re.compile(r"\b(\d{4})[- ]?\d{4}[- ]?\d{4}[- ]?(\d{4})\b") # 카드번호
def sanitize(text: str) -> tuple[str, list]:
findings = []
# 1) 마크다운 이미지는 도메인과 무관하게 전부 제거 (EchoLeak·ForcedLeak형 0-click 유출 차단)
text, n = MD_IMAGE_RE.subn("[이미지 제거됨]", text)
if n:
findings.append(f"image_removed:{n}")
# 2) 허용 목록 밖 URL은 링크 자체를 제거
def _check_url(m: re.Match) -> str:
host = urlparse(m.group(0)).hostname or ""
if host in ALLOWED_DOMAINS:
return m.group(0)
findings.append(f"blocked_url:{host}")
return "[외부 링크 차단]"
text = URL_RE.sub(_check_url, text)
# 3) 민감정보 마스킹 — 앞자리만 남겨 상담 맥락은 유지
text, n1 = RRN_RE.subn(r"\1-\2******", text)
text, n2 = CARD_RE.subn(r"\1-****-****-\2", text)
if n1 or n2:
findings.append(f"pii_masked:{n1 + n2}")
return text, findings
if __name__ == "__main__":
reply = ("고객님 주민번호 900101-1234567, 카드 1234-5678-9012-3456 확인했습니다. "
" 자세한 내용은 https://help.mybank.co.kr/faq "
"또는 https://my-bank-cms.com/x?q=leak 참고")
safe, log = sanitize(reply)
print(safe)
print(log) # SIEM 전송 대상예제를 실행하면 주민번호는 뒷자리 첫 숫자만 남기고, 카드번호는 앞 4자리·뒤 4자리만 남깁니다. 공격용 이미지 비컨과 허용 목록 밖의 유사 도메인 링크는 제거되고, 자사 고객센터 링크만 살아남습니다. 반환되는 findings 목록은 SIEM으로 보내 '어떤 세션에서 유출 시도가 있었는지'를 관제 지표로 쓰시면 됩니다. 정규식 기반 마스킹은 1차 방어선이므로, 운영 환경에서는 계좌번호 형식 등 자사 데이터 패턴을 추가해 확장하세요.
💡 실전 팁: 허용 도메인 목록에는 반드시 '정확한 호스트명'만 넣고, 와일드카드(*.example.com)는 피하세요. 하위 도메인 탈취(Subdomain Takeover) 한 번이면 허용 목록이 그대로 유출 통로가 됩니다. ForcedLeak 사례처럼 도메인 만료일도 자산 관리 대상에 포함하세요.
▶ 실전 코드 ③ — 에이전트 파드 egress 기본 차단 NetworkPolicy (YAML)
에이전트가 Kubernetes 위에서 돈다면, 아웃바운드 통신을 기본 차단하고 정책 게이트웨이·내부 LLM 엔드포인트·DNS만 열어주는 것이 가장 강력한 마지막 방어선입니다. 응답 필터가 뚫려도 '나갈 길'이 없으면 유출은 성립하지 않습니다.
# AI 에이전트 파드: 아웃바운드(egress) 기본 차단 + 허용 대상만 개방
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: ai-agent-egress-lockdown
namespace: ai-agents # REPLACE_THIS
spec:
podSelector:
matchLabels:
app: loan-agent # 대상 에이전트 파드
policyTypes:
- Egress # 명시한 대상 외 모든 외부 통신 차단
egress:
# ① 도구 호출은 반드시 정책 게이트웨이를 거치도록 강제
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: agent-gateway
podSelector:
matchLabels:
app: tool-policy-gateway
ports:
- protocol: TCP
port: 8443
# ② 사내(또는 전용선) LLM 추론 엔드포인트
- to:
- ipBlock:
cidr: 10.20.30.0/24 # REPLACE_THIS: LLM 서빙 대역
ports:
- protocol: TCP
port: 443
# ③ DNS 조회 (kube-dns)만 허용
- to:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: kube-system
podSelector:
matchLabels:
k8s-app: kube-dns
ports:
- protocol: UDP
port: 53
- protocol: TCP
port: 53policyTypes에 Egress를 지정하는 순간, 아래 egress 목록에 없는 모든 아웃바운드는 차단됩니다. ①은 에이전트가 업무 API에 직접 붙지 못하고 반드시 정책 게이트웨이를 거치게 만들고, ②는 사내 또는 전용선으로 연결된 LLM 추론 대역만 허용합니다. 적용 후 kubectl exec로 에이전트 파드에서 외부 사이트 접속이 실패하는지 꼭 확인하세요. 참고로 NetworkPolicy는 Calico·Cilium처럼 이를 지원하는 CNI가 설치돼 있어야 실제로 동작합니다.
⚠️ 주의: 외부 SaaS LLM API를 써야 하는 경우 ② 대신 egress 프록시를 경유하도록 구성하고, 프록시에서 해당 API 도메인만 허용하세요. IP 대역으로 퍼블릭 클라우드 전체를 열어주면 공격자가 같은 클라우드에 띄운 수신 서버로도 데이터가 나갈 수 있습니다. 망분리 예외는 혁신금융서비스 지정 조건의 보안대책 범위 안에서만 적용해야 합니다.
7. 자주 묻는 질문 (FAQ)
가이드라인 자체는 자율규제 성격이라 적용 수준을 회사가 정할 수 있습니다. 다만 인공지능기본법상 고영향 AI에 해당하면 별도의 법적 의무가 생기고, 금융보안원 레드팀 평가도 실행 수준 통제를 보기 시작했기 때문에 사실상 기준선으로 작동한다고 보는 게 현실적입니다. 규제 흐름은 1번 섹션에 정리했습니다.
시스템 프롬프트는 피해 확률을 낮추는 보조 수단일 뿐, 100% 차단은 불가능하다고 가정해야 합니다. EchoLeak처럼 사용자가 아무것도 하지 않아도 외부 메일 한 통으로 공격이 성립하기도 했습니다. 그래서 LLM 바깥의 정책 게이트웨이와 egress 차단이 필요하며, 3번 섹션의 7대 원칙을 참고하세요.
2024년 망분리 개선 로드맵 이후 혁신금융서비스(규제 샌드박스) 지정을 통해 생성형 AI 활용이 허용되고 있으며, 지정 시 보안대책이 조건으로 붙습니다. 2026년 6월 발표에서도 일부 망분리 규제의 한시적 완화가 언급됐습니다. 어떤 경로든 egress 프록시와 허용 도메인 통제는 기본이니 실전 코드 ③을 함께 보세요.
정답은 없고, 기존 비대면 거래의 추가 인증 기준이나 내부 결재 전결 기준과 맞추는 것이 가장 설득력 있습니다. 금액 외에도 신규 수취인, 되돌릴 수 없는 작업, 고객정보 변경은 금액과 무관하게 승인 대상으로 두는 것을 권합니다. Arup 사례처럼 승인 화면 자체가 조작될 수 있으니 4번 사례 ③의 교훈도 꼭 반영하세요.
에이전트에 쓰기 권한을 주지 않는 '조회 전용' 단계부터 시작하고, 정책 게이트웨이·egress 차단·감사 로그 세 가지를 먼저 갖추세요. 셋 다 오픈소스와 기존 인프라로 구현 가능하며, 5번 비교표의 L4·L6 계층이 여기에 해당합니다. 더 궁금한 점은 댓글로 남겨주세요!
 |
| 금융 AI 에이전트에는 업무 수행 능력과 함께 권한 및 데이터 보호를 위한 통제가 필요합니다. |
8. 마무리 요약
✅ 금융권 AI 에이전트 보안 — LLM은 속는다, 그래서 아키텍처가 지킨다
2026년 금융분야 AI 가이드라인 개정과 금융보안원 AI 에이전트 보안 평가기준 초안으로, 금융권 AI 보안의 기준선은 '모델이 무슨 말을 하느냐'에서 '에이전트가 무엇을 실행할 수 있느냐'로 옮겨갔습니다. EchoLeak과 ForcedLeak은 비신뢰 입력과 열린 외부 전송 경로가 만나면 클릭 한 번 없이도 데이터가 빠져나간다는 걸 보여줬고, Arup 사건은 사람 승인조차 조작될 수 있음을 증명했습니다.
해법은 에이전트 전용 신원, 도구 허용 목록과 최소권한, LLM 바깥의 정책 게이트웨이, 비신뢰 데이터 분리, egress 통제, 위험 기반 HITL, 위변조 불가 감사 로그라는 7대 원칙에 있습니다. 카카오뱅크와 삼성생명의 사례처럼 레드팀과 네트워크 세그멘테이션을 함께 가져가는 다층 방어가 금융권다운 답입니다.
기억할 문장은 하나입니다. 통제는 LLM 바깥에 있을 때만 통제입니다.
오늘 당장 할 수 있는 첫 행동을 제안드리면, 지금 운영 중이거나 PoC 중인 에이전트의 '도구 목록'을 뽑아 각 도구에 조회·변경·거래 등급을 붙여보세요. 30분이면 끝나는 작업인데, 대부분 이 단계에서 "이게 왜 여기 붙어 있지?" 싶은 도구가 하나쯤 나옵니다.
여러분 조직에서는 AI 에이전트 보안 검토를 어느 부서가 주관하고 있나요? 보안팀, IT기획, 아니면 AI 전담 조직인가요? 댓글로 현황을 나눠주시면 함께 고민해 보겠습니다. 다음 포스팅에서는 금융권 AI 레드팀 실전 시나리오 — 간접 프롬프트 인젝션 테스트 케이스 설계법을 다룰 예정이니 기대해 주세요!
ℹ️ 참고 자료
· 파이낸셜뉴스 — 금융보안원 AI 에이전트 보안 평가기준 초안(2026.10)
· 금융위 '금융분야 AI 가이드라인' 개정 발표(2026.6)
· 법무법인 세종 뉴스레터 — 금융분야 AI 가이드라인 개정안 해설
· 데일리안 — 금융보안원 AI 안전성·신뢰성 강화 세미나(2026.5)
· 금융위원회 — 금융분야 망분리 개선 로드맵(2024.8)
· The Hacker News — EchoLeak(CVE-2025-32711)
· The Register — Salesforce Agentforce ForcedLeak
· Construction Briefing — Arup 딥페이크 화상회의 사기
댓글
댓글 쓰기