AI 에이전트 기반의 침투 테스트(Pentesting) 플랫폼은 실제 보안 테스트를 수행하기 위해 민감한 정보에 접근할 수 있어야 합니다.
예를 들어 다음과 같은 정보가 필요할 수 있습니다.
테스트용 계정의 아이디와 비밀번호
세션 쿠키
API에서 발견한 인증 토큰
API 키
테스트 과정에서 발견된 개인정보
그렇다면 고객 입장에서 이런 질문이 생기는 것은 당연합니다.
펜테스트 에이전트가 테스트 중 비밀번호나 세션 토큰,
고객 정보를 발견했다면, 그 민감한 정보가 LLM에게도 전달되어야 할까?
결론부터 말하면 그럴 필요가 없습니다.
이 문제를 해결하는 핵심은 단순히 민감한 정보를 필터링하는 것이 아닙니다. 처음부터 민감한 정보가 LLM에 전달되지 않도록 시스템의 아키텍처를 설계하는 것이 중요합니다.
이 글에서는 이러한 구조를 **Security Harness(보안 하니스)**라고 부르겠습니다.
간단한 예제로 살펴보는 API 보안 테스트
구조를 이해하기 위해 실제 침투 테스트 상황을 하나 가정해 보겠습니다.
고객이 승인한 API 침투 테스트를 수행한다고 생각해 봅시다.
고객이 테스트용 사용자 이름과 비밀번호를 제공합니다.
에이전트가 로그인하고 세션 쿠키를 받습니다.
에이전트가 계정 API에 접근합니다.
API가 예상과 달리 다른 사용자의 이메일 주소와 액세스 토큰을 반환합니다.
에이전트는 해당 토큰이 관리자용 API에도 접근할 수 있는지 테스트하려고 합니다.
일반적인 AI 에이전트 구조라면 다음과 같은 흐름이 됩니다.
Tool → 원본 결과 → LLM → 다음 행동
API의 응답이 그대로 에이전트에게 전달되고, 대화 컨텍스트에 포함된 뒤 LLM에게 다음과 같은 질문과 함께 전달됩니다.
"다음에는 무엇을 해야 할까요?"
문제는 이 과정에서 실제 이메일 주소와 액세스 토큰까지 LLM에 전달될 수 있다는 것입니다.
하지만 사실 LLM이 실제 값을 알고 있을 필요는 없습니다.
LLM에게 필요한 것은 무슨 일이 발생했는지 이해하고 다음 행동을 결정할 수 있는 정보뿐입니다.
예를 들어 다음과 같은 실제 인증 결과가 있다고 해봅시다.
Authentication succeeded with eyJhbGciOi…
이를 LLM에게 그대로 보내는 대신 Security Harness가 다음처럼 바꿔 전달할 수 있습니다.
Authentication succeeded with <CREDENTIAL_01>.
또한 API가 다음과 같은 정보를 반환했다고 가정해 보겠습니다.
Email: alice@example.com
Access token: eyJhbGciOi…
LLM에게는 다음과 같이 전달합니다.
응답에 다음 정보가 포함되어 있습니다.
이메일 주소: <EMAIL_02>
액세스 토큰: <ACCESS_TOKEN_03>
이제 LLM은 토큰이 발견되었고, 관리자 API와 관련이 있을 수 있다는 사실을 알 수 있습니다.
하지만 실제 토큰 값 자체는 알 필요가 없습니다.
즉, LLM은 실제 비밀번호나 토큰을 보지 않고도 충분히 추론하고 다음 행동을 결정할 수 있습니다.
그렇다면 에이전트는 실제 자격 증명을 어떻게 사용하는가?
여기서 중요한 질문이 하나 생깁니다.
LLM이 <ACCESS_TOKEN_03>이라는 참조값만 알고 있다면, 실제 토큰은 어떻게 서버에 전달될까요?
바로 이 지점에서 Security Harness가 중요한 역할을 합니다.
예를 들어 LLM이 발견된 토큰을 관리자 API에 사용해 테스트하기로 결정했다고 해봅시다.
LLM은 다음과 같은 요청을 생성할 수 있습니다.
{
"name": "send_http_request",
"arguments": {
"method": "GET",
"url": "https://target.example/api/admin/profile",
"credential": "<ACCESS_TOKEN_03>"
}
}
이 요청을 받은 Harness는 <ACCESS_TOKEN_03>이 실제로 어떤 자격 증명을 의미하는지 확인합니다.
그리고 신뢰할 수 있는 내부 환경에 저장되어 있는 실제 토큰을 가져와, 권한이 있는 도구에 전달합니다.
결과적으로 대상 서버에는 실제 토큰이 전달됩니다.
하지만 LLM에는 전달되지 않습니다.
간단하게 표현하면 다음과 같습니다.
Target → Tool → Harness → LLM
민감한 정보는 신뢰할 수 있는 영역 내부에 계속 머물고, LLM은 실제 비밀값이 아닌 **안전한 참조값(reference)**을 사용해 추론합니다.
이것이 Security Harness의 핵심 개념입니다.
에이전트는 비밀 정보를 사용할 수 있지만, LLM이 그 비밀 자체를 볼 필요는 없습니다.
Security Harness는 정확히 무엇을 하는가?
단순히 참조값을 실제 값으로 변환하는 것은 Harness가 하는 일의 일부에 불과합니다.
Security Harness는 에이전트를 둘러싼 보안 경계(Security Boundary)라고 생각할 수 있습니다.
목적은 단순히 "비밀번호를 제거하는 것"이 아닙니다.
테스트 환경, 에이전트, 도구, LLM 사이에서 민감한 정보가 어떻게 이동하고 어떻게 사용되는지를 통제하는 것이 핵심입니다.
이를 크게 5가지 기능으로 나눌 수 있습니다.
1. 민감한 정보 탐지
침투 테스트 도구는 다양한 형태의 민감한 정보를 반환할 수 있습니다.
비밀번호와 API 키
세션 쿠키와 액세스 토큰
인증 헤더
이메일 주소와 개인정보
데이터베이스 연결 문자열
JSON이나 XML 안에 포함된 비밀값
터미널 출력
오류 메시지
스크린샷
스캐너 결과
따라서 가장 먼저 해야 할 일은 무엇을 보호해야 하는지 정확하게 식별하는 것입니다.
2. 실제 값을 안전한 참조값으로 교체
민감한 정보가 식별되었다면 원본 값이 그대로 LLM의 컨텍스트에 들어가서는 안 됩니다.
Harness는 이를 다음과 같은 안전한 참조값으로 교체합니다.
<ACCESS_TOKEN_03>
원래 값은 신뢰할 수 있는 환경 내부에 안전하게 보관합니다.
LLM은 <ACCESS_TOKEN_03>이라는 참조값을 통해 "어떤 토큰이 발견되었다"는 사실을 이해할 수 있지만, 실제 토큰 값 자체에는 접근하지 못합니다.
3. 참조값과 실제 비밀값의 관계 유지
이 부분은 단순한 **마스킹(Redaction)**과 중요한 차이가 있습니다.
만약 토큰을 단순히 [REDACTED]로 바꿔버린다면 에이전트는 무언가가 삭제되었다는 사실만 알 뿐, 나중에 그 값을 다시 사용할 수 없습니다.
반면 <ACCESS_TOKEN_03>과 같은 참조값은 다릅니다.
Harness는 이 참조값 뒤에 어떤 실제 값이 있는지 알고 있습니다.
즉,
<ACCESS_TOKEN_03> → 테스트 중 발견된 실제 액세스 토큰
이라는 관계를 유지할 수 있습니다.
따라서 해당 참조값은 에이전트의 작업이 진행되는 동안 계속 사용할 수 있습니다.
4. 이후 사용을 승인하고 통제
하지만 참조값을 계속 유지한다고 해서 모든 에이전트가 언제든 실제 값을 사용할 수 있다는 뜻은 아닙니다.
Harness는 에이전트가 요청한다고 해서 모든 비밀값을 자동으로 제공해서는 안 됩니다.
대신 다음을 확인해야 합니다.
어떤 에이전트가 요청했는가?
어떤 도구가 사용되는가?
어떤 작업을 수행하려는가?
해당 작업에 해당 자격 증명을 사용할 권한이 있는가?
전체 흐름은 다음과 같습니다.
에이전트가 자격 증명 발견 → Harness가 저장 → LLM이 참조값 요청 → Harness가 정책 확인 → 승인된 도구에 실제 자격 증명 전달
즉, 자격 증명 접근은 단순한 "정보 노출"이 아니라 통제된 보안 작업이 됩니다.
5. 다른 데이터 경로에서도 비밀값 보호
여기에는 한 가지 더 미묘한 문제가 있습니다.
LLM의 프롬프트에서 비밀번호를 제거했다고 해서 보안 문제가 모두 해결되는 것은 아닙니다.
민감한 정보는 다음과 같은 다른 경로를 통해 노출될 수도 있습니다.
디버그 로그
트레이스
재시도 과정
캐시
저장된 결과물
오류 보고서
대화 기록
이후 생성되는 리포트
따라서 LLM 프롬프트만 보호하는 것으로는 충분하지 않습니다.
Harness는 민감한 정보가 시스템 전체의 데이터 경로를 통해 어디로 이동할 수 있는지를 함께 관리해야 합니다.
LLM에게 민감한 정보를 찾게 하면 안 될까?
여기서 많은 사람들이 가장 먼저 떠올리는 방법이 있습니다.
"LLM이 비밀번호나 토큰을 찾아내도록 하면 되지 않을까?"
실제로 LLM은 비밀번호, 토큰, 이메일 주소, 개인정보 등을 식별하는 데 상당히 유용할 수 있습니다.
하지만 근본적인 문제가 있습니다.
만약 시스템의 원칙이
"민감한 정보는 LLM에 보내지 않는다."
라면,
먼저 민감한 정보를 LLM에 보내고
"이 정보가 민감한 정보인가요?"
라고 물어보는 것은 논리적으로 맞지 않습니다.
따라서 민감한 정보인지 판단하는 작업은 신뢰할 수 있는 환경 내부에서 먼저 이루어져야 합니다.
이를 위해 다양한 방법을 사용할 수 있습니다.
정규식 및 규칙 기반 탐지
결정론적 필터
로컬 개인정보 보호 모델
로컬에서 실행되는 LLM
전문적인 Secret Detection 도구
여러 방식의 조합
여기서 중요한 것은 AI를 탐지에 사용하느냐가 아닙니다.
원본 민감 정보가 승인된 환경 밖으로 나가기 전에 보호 여부를 판단할 수 있느냐가 핵심입니다.
단순한 필터만으로 충분하지 않은 이유
그렇다면 다음과 같은 해결책을 생각할 수 있습니다.
"좋은 마스킹 필터를 하나 만들면 되지 않을까?"
하지만 실제로는 그렇게 간단하지 않습니다.
침투 테스트에서 발생하는 데이터는 매우 복잡합니다.
하나의 보안 결과 안에도 다음과 같은 정보가 함께 포함될 수 있습니다.
IP 주소
UUID
해시
파일 경로
명령어
CVE 번호
특이한 문자열
기타 기술 정보
이 가운데 일부는 민감해 보이지만 실제로는 테스트를 수행하는 데 반드시 필요한 정보일 수 있습니다.
모든 의심스러운 문자열을 제거하면 에이전트의 성능과 유용성이 떨어집니다.
반대로 필터가 너무 느슨하면 정작 보호해야 할 비밀번호나 토큰을 놓칠 수 있습니다.
더 중요한 문제도 있습니다.
단순한 마스킹만으로는 나중에 해당 자격 증명을 다시 사용해야 하는 상황을 해결할 수 없습니다.
침투 테스트 에이전트는 어떤 자격 증명을 발견한 후 몇 단계가 지난 뒤 해당 자격 증명을 다시 사용해야 할 수도 있습니다.
따라서 Harness는 단순히 정보를 숨기는 역할을 넘어 다음 전체 과정을 관리해야 합니다.
탐지 → 보호 → 참조 → 승인 → 사용
현재 활용할 수 있는 기술은 무엇인가?
다행히 이 문제를 처음부터 모두 개발해야 하는 것은 아닙니다.
이미 다양한 오픈소스 및 상용 기술이 이 문제의 일부를 해결하고 있습니다.
Presidio
개인정보를 식별하고 익명화할 수 있는 도구입니다.
OpenAI Privacy Filter
텍스트가 외부 환경으로 전달되기 전에 로컬 환경에서 민감한 정보를 식별할 수 있습니다.
LangChain PIIMiddleware
에이전트 환경에서 개인정보를 차단하거나, 마스킹·삭제·해싱하는 기능을 제공합니다.
Private AI
민감한 정보를 탐지하고, 다른 값으로 대체하거나 필요할 때 복원하는 기능을 제공합니다.
Skyflow
Vault 기반 토큰화와 통제된 정보 공개 기능을 제공합니다.
Gitleaks / TruffleHog
소스 코드나 파일 등에서 자격 증명과 비밀값을 탐지하는 데 초점을 둔 도구입니다.
이외에도 Amazon Bedrock Guardrails, Google Sensitive Data Protection, Cloudflare AI Gateway DLP, LangSmith Gateway 등의 서비스가 관련된 기능을 제공합니다.
이러한 기술들은 각각 문제의 일부를 해결합니다.
그리고 여기서 중요한 차이가 드러납니다.
비밀값을 찾아 숨기는 것과, 에이전트의 전체 생명주기 동안 비밀값을 안전하게 관리하는 것은 서로 다른 문제입니다.
완전한 Agent Security Harness라면 다음 과정을 하나의 체계로 연결해야 합니다.
민감한 정보를 탐지한다.
안전한 참조값으로 교체한다.
원본 값을 안전하게 저장한다.
어떤 에이전트 또는 도구가 사용할 수 있는지 통제한다.
승인된 작업에 실제 값이 필요한 순간에만 원본을 가져온다.
다른 데이터 경로를 통해 원본 값이 노출되지 않도록 한다.
기존 보안 벤치마크는 무엇을 알려주는가?
그렇다면 Security Harness가 실제로 제대로 작동하는지 어떻게 평가할 수 있을까요?
최근에는 개인정보 보호, Secret Detection, 데이터 마스킹, 에이전트 보안과 관련된 다양한 연구와 벤치마크가 등장하고 있습니다.
예를 들어 다음과 같은 프로젝트들이 있습니다.
RedactionBench
SecretBench
CredData
Text Anonymization Benchmark
AgentDAM
CI-Work
AgentDojo
InjecAgent
ToolPrivacyBench
PrivacyPeek
AgentLeak
PIIBench
이러한 벤치마크는 각각 문제의 서로 다른 부분을 검증합니다.
예를 들어 다음과 같은 질문에 답할 수 있습니다.
시스템이 민감한 정보를 제대로 식별하는가?
자격 증명을 탐지할 수 있는가?
에이전트가 필요하지 않은 정보를 수집하는가?
프롬프트 인젝션을 통해 개인정보가 유출될 수 있는가?
기업용 AI 에이전트가 정보를 적절하게 공유하는가?
모두 중요한 테스트입니다.
하지만 우리가 실제로 검증하고 싶은 전체 흐름과는 차이가 있습니다.
우리가 필요한 것은 다음과 같은 완전한 시나리오입니다.
도구가 민감한 정보를 반환한다
↓
Harness가 원본 값을 LLM으로부터 차단한다
↓
LLM에는 올바른 추론에 필요한 정보만 전달한다
↓
에이전트가 승인된 작업을 요청한다
↓
Harness가 권한을 확인하고 실제 값을 가져온다
↓
신뢰할 수 있는 도구가 원본 자격 증명을 사용한다
이 전체 과정이 바로 우리가 평가해야 할 실질적인 보안 경계입니다.
권한과 노출은 다르다
지금까지의 이야기는 침투 테스트에 초점을 맞추고 있지만, 그 원칙 자체는 훨씬 광범위하게 적용될 수 있습니다.
AI 에이전트가 어떤 작업을 수행하기 위해 민감한 정보에 접근할 권한을 가질 수 있습니다.
하지만 그렇다고 해서 시스템에 참여하는 모든 구성 요소가 원본 정보를 받아야 하는 것은 아닙니다.
이를 사람의 업무에 비유하면 쉽게 이해할 수 있습니다.
침투 테스트 담당자가 고객의 자격 증명을 사용할 권한이 있다고 해서, 그 자격 증명을 자신이 사용하는 모든 문서나 채팅창, 로그 시스템, 외부 서비스에 그대로 입력해야 하는 것은 아닙니다.
AI 에이전트도 마찬가지입니다.
비밀값을 사용할 권한이 있다는 것은, 시스템의 모든 구성 요소에 그 비밀값을 보여줄 권한이 있다는 의미가 아닙니다.
바로 이 차이를 기술적으로 강제하는 것이 Security Harness의 목적입니다.
결론: 에이전트에게 필요한 능력은 주되, 비밀까지 보여줄 필요는 없다
AI 기반 보안 에이전트는 실제 환경에서 테스트를 수행하기 위해 자격 증명을 사용할 수 있어야 합니다.
하지만 그렇다고 해서 LLM이 그 자격 증명의 실제 값을 알아야 하는 것은 아닙니다.
에이전트는 다음과 같은 작업을 수행할 수 있습니다.
자격 증명을 발견하고
해당 자격 증명을 안전하게 보관하고
자격 증명이 어떤 권한을 제공할 수 있는지 추론하고
승인을 받은 테스트에서 해당 자격 증명을 사용할 수 있습니다.
그 과정에서 LLM은 실제 비밀번호나 토큰을 볼 필요가 없습니다.
핵심은 능력(Capability)과 정보 노출(Exposure)을 분리하는 것입니다.
AI 에이전트에게 작업을 수행하는 데 필요한 능력은 제공하되, 그 과정에서 발생하는 민감한 원본 데이터까지 불필요하게 LLM에 노출하지 않는 것입니다.
이것이 바로 에이전트 기반 보안 플랫폼이 구축해야 할 Security Harness의 핵심이라고 볼 수 있습니다.
에이전트에게 필요한 능력은 제공하되, 그 능력을 위해 사용되는 비밀정보까지 모델에게 공개할 필요는 없습니다.
RIdgebot에 대한 소개자료 및 데모요청은 소프트와이드시큐리티로 연락바랍니다.
AI 에이전트 기반의 침투 테스트(Pentesting) 플랫폼은 실제 보안 테스트를 수행하기 위해 민감한 정보에 접근할 수 있어야 합니다.
예를 들어 다음과 같은 정보가 필요할 수 있습니다.
테스트용 계정의 아이디와 비밀번호
세션 쿠키
API에서 발견한 인증 토큰
API 키
테스트 과정에서 발견된 개인정보
그렇다면 고객 입장에서 이런 질문이 생기는 것은 당연합니다.
펜테스트 에이전트가 테스트 중 비밀번호나 세션 토큰,
고객 정보를 발견했다면, 그 민감한 정보가 LLM에게도 전달되어야 할까?
결론부터 말하면 그럴 필요가 없습니다.
이 문제를 해결하는 핵심은 단순히 민감한 정보를 필터링하는 것이 아닙니다. 처음부터 민감한 정보가 LLM에 전달되지 않도록 시스템의 아키텍처를 설계하는 것이 중요합니다.
이 글에서는 이러한 구조를 **Security Harness(보안 하니스)**라고 부르겠습니다.
간단한 예제로 살펴보는 API 보안 테스트
구조를 이해하기 위해 실제 침투 테스트 상황을 하나 가정해 보겠습니다.
고객이 승인한 API 침투 테스트를 수행한다고 생각해 봅시다.
고객이 테스트용 사용자 이름과 비밀번호를 제공합니다.
에이전트가 로그인하고 세션 쿠키를 받습니다.
에이전트가 계정 API에 접근합니다.
API가 예상과 달리 다른 사용자의 이메일 주소와 액세스 토큰을 반환합니다.
에이전트는 해당 토큰이 관리자용 API에도 접근할 수 있는지 테스트하려고 합니다.
일반적인 AI 에이전트 구조라면 다음과 같은 흐름이 됩니다.
Tool → 원본 결과 → LLM → 다음 행동
API의 응답이 그대로 에이전트에게 전달되고, 대화 컨텍스트에 포함된 뒤 LLM에게 다음과 같은 질문과 함께 전달됩니다.
"다음에는 무엇을 해야 할까요?"
문제는 이 과정에서 실제 이메일 주소와 액세스 토큰까지 LLM에 전달될 수 있다는 것입니다.
하지만 사실 LLM이 실제 값을 알고 있을 필요는 없습니다.
LLM에게 필요한 것은 무슨 일이 발생했는지 이해하고 다음 행동을 결정할 수 있는 정보뿐입니다.
예를 들어 다음과 같은 실제 인증 결과가 있다고 해봅시다.
Authentication succeeded with eyJhbGciOi…
이를 LLM에게 그대로 보내는 대신 Security Harness가 다음처럼 바꿔 전달할 수 있습니다.
Authentication succeeded with <CREDENTIAL_01>.
또한 API가 다음과 같은 정보를 반환했다고 가정해 보겠습니다.
Email: alice@example.com
Access token: eyJhbGciOi…
LLM에게는 다음과 같이 전달합니다.
응답에 다음 정보가 포함되어 있습니다.
이메일 주소: <EMAIL_02>
액세스 토큰: <ACCESS_TOKEN_03>
이제 LLM은 토큰이 발견되었고, 관리자 API와 관련이 있을 수 있다는 사실을 알 수 있습니다.
하지만 실제 토큰 값 자체는 알 필요가 없습니다.
즉, LLM은 실제 비밀번호나 토큰을 보지 않고도 충분히 추론하고 다음 행동을 결정할 수 있습니다.
그렇다면 에이전트는 실제 자격 증명을 어떻게 사용하는가?
여기서 중요한 질문이 하나 생깁니다.
LLM이 <ACCESS_TOKEN_03>이라는 참조값만 알고 있다면, 실제 토큰은 어떻게 서버에 전달될까요?
바로 이 지점에서 Security Harness가 중요한 역할을 합니다.
예를 들어 LLM이 발견된 토큰을 관리자 API에 사용해 테스트하기로 결정했다고 해봅시다.
LLM은 다음과 같은 요청을 생성할 수 있습니다.
{
"name": "send_http_request",
"arguments": {
"method": "GET",
"url": "https://target.example/api/admin/profile",
"credential": "<ACCESS_TOKEN_03>"
}
}
이 요청을 받은 Harness는 <ACCESS_TOKEN_03>이 실제로 어떤 자격 증명을 의미하는지 확인합니다.
그리고 신뢰할 수 있는 내부 환경에 저장되어 있는 실제 토큰을 가져와, 권한이 있는 도구에 전달합니다.
결과적으로 대상 서버에는 실제 토큰이 전달됩니다.
하지만 LLM에는 전달되지 않습니다.
간단하게 표현하면 다음과 같습니다.
Target → Tool → Harness → LLM
민감한 정보는 신뢰할 수 있는 영역 내부에 계속 머물고, LLM은 실제 비밀값이 아닌 **안전한 참조값(reference)**을 사용해 추론합니다.
이것이 Security Harness의 핵심 개념입니다.
에이전트는 비밀 정보를 사용할 수 있지만, LLM이 그 비밀 자체를 볼 필요는 없습니다.
Security Harness는 정확히 무엇을 하는가?
단순히 참조값을 실제 값으로 변환하는 것은 Harness가 하는 일의 일부에 불과합니다.
Security Harness는 에이전트를 둘러싼 보안 경계(Security Boundary)라고 생각할 수 있습니다.
목적은 단순히 "비밀번호를 제거하는 것"이 아닙니다.
테스트 환경, 에이전트, 도구, LLM 사이에서 민감한 정보가 어떻게 이동하고 어떻게 사용되는지를 통제하는 것이 핵심입니다.
이를 크게 5가지 기능으로 나눌 수 있습니다.
1. 민감한 정보 탐지
침투 테스트 도구는 다양한 형태의 민감한 정보를 반환할 수 있습니다.
비밀번호와 API 키
세션 쿠키와 액세스 토큰
인증 헤더
이메일 주소와 개인정보
데이터베이스 연결 문자열
JSON이나 XML 안에 포함된 비밀값
터미널 출력
오류 메시지
스크린샷
스캐너 결과
따라서 가장 먼저 해야 할 일은 무엇을 보호해야 하는지 정확하게 식별하는 것입니다.
2. 실제 값을 안전한 참조값으로 교체
민감한 정보가 식별되었다면 원본 값이 그대로 LLM의 컨텍스트에 들어가서는 안 됩니다.
Harness는 이를 다음과 같은 안전한 참조값으로 교체합니다.
<ACCESS_TOKEN_03>
원래 값은 신뢰할 수 있는 환경 내부에 안전하게 보관합니다.
LLM은 <ACCESS_TOKEN_03>이라는 참조값을 통해 "어떤 토큰이 발견되었다"는 사실을 이해할 수 있지만, 실제 토큰 값 자체에는 접근하지 못합니다.
3. 참조값과 실제 비밀값의 관계 유지
이 부분은 단순한 **마스킹(Redaction)**과 중요한 차이가 있습니다.
만약 토큰을 단순히 [REDACTED]로 바꿔버린다면 에이전트는 무언가가 삭제되었다는 사실만 알 뿐, 나중에 그 값을 다시 사용할 수 없습니다.
반면 <ACCESS_TOKEN_03>과 같은 참조값은 다릅니다.
Harness는 이 참조값 뒤에 어떤 실제 값이 있는지 알고 있습니다.
즉,
<ACCESS_TOKEN_03> → 테스트 중 발견된 실제 액세스 토큰
이라는 관계를 유지할 수 있습니다.
따라서 해당 참조값은 에이전트의 작업이 진행되는 동안 계속 사용할 수 있습니다.
4. 이후 사용을 승인하고 통제
하지만 참조값을 계속 유지한다고 해서 모든 에이전트가 언제든 실제 값을 사용할 수 있다는 뜻은 아닙니다.
Harness는 에이전트가 요청한다고 해서 모든 비밀값을 자동으로 제공해서는 안 됩니다.
대신 다음을 확인해야 합니다.
어떤 에이전트가 요청했는가?
어떤 도구가 사용되는가?
어떤 작업을 수행하려는가?
해당 작업에 해당 자격 증명을 사용할 권한이 있는가?
전체 흐름은 다음과 같습니다.
에이전트가 자격 증명 발견 → Harness가 저장 → LLM이 참조값 요청 → Harness가 정책 확인 → 승인된 도구에 실제 자격 증명 전달
즉, 자격 증명 접근은 단순한 "정보 노출"이 아니라 통제된 보안 작업이 됩니다.
5. 다른 데이터 경로에서도 비밀값 보호
여기에는 한 가지 더 미묘한 문제가 있습니다.
LLM의 프롬프트에서 비밀번호를 제거했다고 해서 보안 문제가 모두 해결되는 것은 아닙니다.
민감한 정보는 다음과 같은 다른 경로를 통해 노출될 수도 있습니다.
디버그 로그
트레이스
재시도 과정
캐시
저장된 결과물
오류 보고서
대화 기록
이후 생성되는 리포트
따라서 LLM 프롬프트만 보호하는 것으로는 충분하지 않습니다.
Harness는 민감한 정보가 시스템 전체의 데이터 경로를 통해 어디로 이동할 수 있는지를 함께 관리해야 합니다.
LLM에게 민감한 정보를 찾게 하면 안 될까?
여기서 많은 사람들이 가장 먼저 떠올리는 방법이 있습니다.
"LLM이 비밀번호나 토큰을 찾아내도록 하면 되지 않을까?"
실제로 LLM은 비밀번호, 토큰, 이메일 주소, 개인정보 등을 식별하는 데 상당히 유용할 수 있습니다.
하지만 근본적인 문제가 있습니다.
만약 시스템의 원칙이
"민감한 정보는 LLM에 보내지 않는다."
라면,
먼저 민감한 정보를 LLM에 보내고
"이 정보가 민감한 정보인가요?"
라고 물어보는 것은 논리적으로 맞지 않습니다.
따라서 민감한 정보인지 판단하는 작업은 신뢰할 수 있는 환경 내부에서 먼저 이루어져야 합니다.
이를 위해 다양한 방법을 사용할 수 있습니다.
정규식 및 규칙 기반 탐지
결정론적 필터
로컬 개인정보 보호 모델
로컬에서 실행되는 LLM
전문적인 Secret Detection 도구
여러 방식의 조합
여기서 중요한 것은 AI를 탐지에 사용하느냐가 아닙니다.
원본 민감 정보가 승인된 환경 밖으로 나가기 전에 보호 여부를 판단할 수 있느냐가 핵심입니다.
단순한 필터만으로 충분하지 않은 이유
그렇다면 다음과 같은 해결책을 생각할 수 있습니다.
"좋은 마스킹 필터를 하나 만들면 되지 않을까?"
하지만 실제로는 그렇게 간단하지 않습니다.
침투 테스트에서 발생하는 데이터는 매우 복잡합니다.
하나의 보안 결과 안에도 다음과 같은 정보가 함께 포함될 수 있습니다.
IP 주소
UUID
해시
파일 경로
명령어
CVE 번호
특이한 문자열
기타 기술 정보
이 가운데 일부는 민감해 보이지만 실제로는 테스트를 수행하는 데 반드시 필요한 정보일 수 있습니다.
모든 의심스러운 문자열을 제거하면 에이전트의 성능과 유용성이 떨어집니다.
반대로 필터가 너무 느슨하면 정작 보호해야 할 비밀번호나 토큰을 놓칠 수 있습니다.
더 중요한 문제도 있습니다.
단순한 마스킹만으로는 나중에 해당 자격 증명을 다시 사용해야 하는 상황을 해결할 수 없습니다.
침투 테스트 에이전트는 어떤 자격 증명을 발견한 후 몇 단계가 지난 뒤 해당 자격 증명을 다시 사용해야 할 수도 있습니다.
따라서 Harness는 단순히 정보를 숨기는 역할을 넘어 다음 전체 과정을 관리해야 합니다.
탐지 → 보호 → 참조 → 승인 → 사용
현재 활용할 수 있는 기술은 무엇인가?
다행히 이 문제를 처음부터 모두 개발해야 하는 것은 아닙니다.
이미 다양한 오픈소스 및 상용 기술이 이 문제의 일부를 해결하고 있습니다.
Presidio
개인정보를 식별하고 익명화할 수 있는 도구입니다.
OpenAI Privacy Filter
텍스트가 외부 환경으로 전달되기 전에 로컬 환경에서 민감한 정보를 식별할 수 있습니다.
LangChain PIIMiddleware
에이전트 환경에서 개인정보를 차단하거나, 마스킹·삭제·해싱하는 기능을 제공합니다.
Private AI
민감한 정보를 탐지하고, 다른 값으로 대체하거나 필요할 때 복원하는 기능을 제공합니다.
Skyflow
Vault 기반 토큰화와 통제된 정보 공개 기능을 제공합니다.
Gitleaks / TruffleHog
소스 코드나 파일 등에서 자격 증명과 비밀값을 탐지하는 데 초점을 둔 도구입니다.
이외에도 Amazon Bedrock Guardrails, Google Sensitive Data Protection, Cloudflare AI Gateway DLP, LangSmith Gateway 등의 서비스가 관련된 기능을 제공합니다.
이러한 기술들은 각각 문제의 일부를 해결합니다.
그리고 여기서 중요한 차이가 드러납니다.
비밀값을 찾아 숨기는 것과, 에이전트의 전체 생명주기 동안 비밀값을 안전하게 관리하는 것은 서로 다른 문제입니다.
완전한 Agent Security Harness라면 다음 과정을 하나의 체계로 연결해야 합니다.
민감한 정보를 탐지한다.
안전한 참조값으로 교체한다.
원본 값을 안전하게 저장한다.
어떤 에이전트 또는 도구가 사용할 수 있는지 통제한다.
승인된 작업에 실제 값이 필요한 순간에만 원본을 가져온다.
다른 데이터 경로를 통해 원본 값이 노출되지 않도록 한다.
기존 보안 벤치마크는 무엇을 알려주는가?
그렇다면 Security Harness가 실제로 제대로 작동하는지 어떻게 평가할 수 있을까요?
최근에는 개인정보 보호, Secret Detection, 데이터 마스킹, 에이전트 보안과 관련된 다양한 연구와 벤치마크가 등장하고 있습니다.
예를 들어 다음과 같은 프로젝트들이 있습니다.
RedactionBench
SecretBench
CredData
Text Anonymization Benchmark
AgentDAM
CI-Work
AgentDojo
InjecAgent
ToolPrivacyBench
PrivacyPeek
AgentLeak
PIIBench
이러한 벤치마크는 각각 문제의 서로 다른 부분을 검증합니다.
예를 들어 다음과 같은 질문에 답할 수 있습니다.
시스템이 민감한 정보를 제대로 식별하는가?
자격 증명을 탐지할 수 있는가?
에이전트가 필요하지 않은 정보를 수집하는가?
프롬프트 인젝션을 통해 개인정보가 유출될 수 있는가?
기업용 AI 에이전트가 정보를 적절하게 공유하는가?
모두 중요한 테스트입니다.
하지만 우리가 실제로 검증하고 싶은 전체 흐름과는 차이가 있습니다.
우리가 필요한 것은 다음과 같은 완전한 시나리오입니다.
도구가 민감한 정보를 반환한다
↓
Harness가 원본 값을 LLM으로부터 차단한다
↓
LLM에는 올바른 추론에 필요한 정보만 전달한다
↓
에이전트가 승인된 작업을 요청한다
↓
Harness가 권한을 확인하고 실제 값을 가져온다
↓
신뢰할 수 있는 도구가 원본 자격 증명을 사용한다
이 전체 과정이 바로 우리가 평가해야 할 실질적인 보안 경계입니다.
권한과 노출은 다르다
지금까지의 이야기는 침투 테스트에 초점을 맞추고 있지만, 그 원칙 자체는 훨씬 광범위하게 적용될 수 있습니다.
AI 에이전트가 어떤 작업을 수행하기 위해 민감한 정보에 접근할 권한을 가질 수 있습니다.
하지만 그렇다고 해서 시스템에 참여하는 모든 구성 요소가 원본 정보를 받아야 하는 것은 아닙니다.
이를 사람의 업무에 비유하면 쉽게 이해할 수 있습니다.
침투 테스트 담당자가 고객의 자격 증명을 사용할 권한이 있다고 해서, 그 자격 증명을 자신이 사용하는 모든 문서나 채팅창, 로그 시스템, 외부 서비스에 그대로 입력해야 하는 것은 아닙니다.
AI 에이전트도 마찬가지입니다.
비밀값을 사용할 권한이 있다는 것은, 시스템의 모든 구성 요소에 그 비밀값을 보여줄 권한이 있다는 의미가 아닙니다.
바로 이 차이를 기술적으로 강제하는 것이 Security Harness의 목적입니다.
결론: 에이전트에게 필요한 능력은 주되, 비밀까지 보여줄 필요는 없다
AI 기반 보안 에이전트는 실제 환경에서 테스트를 수행하기 위해 자격 증명을 사용할 수 있어야 합니다.
하지만 그렇다고 해서 LLM이 그 자격 증명의 실제 값을 알아야 하는 것은 아닙니다.
에이전트는 다음과 같은 작업을 수행할 수 있습니다.
자격 증명을 발견하고
해당 자격 증명을 안전하게 보관하고
자격 증명이 어떤 권한을 제공할 수 있는지 추론하고
승인을 받은 테스트에서 해당 자격 증명을 사용할 수 있습니다.
그 과정에서 LLM은 실제 비밀번호나 토큰을 볼 필요가 없습니다.
핵심은 능력(Capability)과 정보 노출(Exposure)을 분리하는 것입니다.
AI 에이전트에게 작업을 수행하는 데 필요한 능력은 제공하되, 그 과정에서 발생하는 민감한 원본 데이터까지 불필요하게 LLM에 노출하지 않는 것입니다.
이것이 바로 에이전트 기반 보안 플랫폼이 구축해야 할 Security Harness의 핵심이라고 볼 수 있습니다.
에이전트에게 필요한 능력은 제공하되, 그 능력을 위해 사용되는 비밀정보까지 모델에게 공개할 필요는 없습니다.
RIdgebot에 대한 소개자료 및 데모요청은 소프트와이드시큐리티로 연락바랍니다.