AI/AI Security4 10-4. [AI Security]: 마킹에서 드롭으로 지난 글에서 외부 API 응답에 _sanitize_external_content()를 붙였다. 인젝션 패턴이 감지되면 [SANITIZED: ...] 마킹을 앞에 붙이고 원문 앞 30자를 잘라 컨텍스트에 넣는 방식이었다. 그리고 그때 이미 글에 이렇게 적어뒀다."해당 '마킹 후 유지' 기법은 현재와 같은 위험한 외부 컨텍스트 주입을 감지하고자 하는 상황에선 가급적 이후 진행을 차단하거나 AI Agent 동작을 중지하는 것이 권장된다. 일단 알아만 두고 추후에 고도화한다." 이번 주는 그 "추후"를 실제로 했다. 멘토님의 피드백이 정확히 이 지점을 짚었기 때문이다. 현재 상황 파악 코드를 다시 열어 확인한다.def _sanitize_external_content(text: str) -> str: .. 2026. 6. 17. 10-3. [AI Security]: 취약점을 데이터로 확인 10주차 프리뷰 글에서 이 에이전트의 잠재적 취약점을 구조적으로 정리했다. "HackerNews/GitHub/meme-api.com 응답이 간접 인젝션 벡터가 될 수 있는가? force_similar, force_youtube_fail 파라미터가 Tool description을 통해 LLM에게 노출되어 있다. 공격자가 이를 악용할 수 있는가?" 이 주에는 그 가설을 코드로 확인했다. 추측이 맞는지 틀리는지를 Before 결과 JSON으로 확인하고, 틀린 지점에 방어를 붙이고, After 결과로 검증했다. 이 에이전트가 구조적으로 왜 특수한가 일반 챗봇과 개발 중인 agent의 차이를 먼저 짚고 가야 한다. 일반 챗봇은 사용자 입력과 시스템 프롬프트가 LLM에 들어가는 두 소스를 다룬다. 개발 중인.. 2026. 6. 17. 10-2. [AI Security]: 현재 상태 파악 7~9주차에 이미 있던 것들 현재 상태를 파악하는 것이 먼저다. 보안 점검의 기본 순서는 이렇다.현재 상태 파악 (Baseline)→ 취약점 식별→ 보완새 방어를 추가하기 전에 기존 방어가 무엇인지 모르면, 무엇이 부족한지 설명할 수 없다. 그래서 7~9주차에 구현한 코드를 보안 관점으로 다시 읽었다. 레이어 1: AI Governance (8주차에 만든 것) 8주차에서 LangSmith 연동과 로컬 JSON trace를 구축했다. 당시의 목적은 비용 분석과 디버깅이었다. 에이전트가 어떤 Tool을 어떤 순서로 호출했는지, 각 step에서 무슨 데이터가 들어오고 나갔는지를 기록하는 것이었다. 그런데 이것이 보안 관점에서는 감사(Audit) 기능이다.{ "tool_trace": [ { .. 2026. 6. 17. 10-1. [AI Security]: AI 시스템의 보안 같은 구조를, 보안 관점으로본다. 8주차에서 Observability를 붙이고, 9주차에서 비용 병목을 찾아 최적화했다. 같은 에이전트를 이번에는 다른 시야로 본다. 보안이다.지금까지 에이전트를 "잘 동작하게" 만드는 데 집중했다면, 10주차는 "잘못 동작하게 만들려고 시도하는 입력"을 다룬다. 그리고 이미 구현된 코드 안에 어떤 취약점이 있는지, 어떤 방어선을 추가해야 하는지를 정리한다. 순서가 의미 있다. Observability가 없었다면 어디서 문제가 생기는지 추적하기 어렵다. trace가 쌓이지 않았다면 공격 시도를 로그로 남기고 사후 분석하는 것도 불가능하다. 8주차에서 만든 관측 체계가 보안 점검의 기반이 된다. AI 시스템의 보안 문제는 모델 하나에서만 생기지 않는다 LLM 보안을.. 2026. 6. 17. 이전 1 다음
