AI 에이전트가 자신의 가드레일을 이해하면 어떻게 될까?
Source: Dev.to
번역할 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다.
에이전트를 신뢰하기 – 가드레일만으로는 부족한 이유
시리즈 Part 1에서 나는 모든 주요 AI‑에이전트 프레임워크가 에이전트를 신뢰한다는 점을 주장했다.
그들은 출력물을 검증하고, 응답을 필터링하며, 도구의 범위를 제한한다.
하지만 그들 중 어느 것도 실제 질문에 답하지 못한다:
이 에이전트가 행동하도록 허가한 사람은 누구인가?
숨겨진 문제: 에이전트가 가드레일을 읽을 수 있다
오늘날 대부분의 AI 가드레일은 다음과 같이 작동한다:
| 가드레일 | 강제 방식 |
|---|---|
| 시스템 프롬프트 | “X를 하지 마라” |
| 출력 필터 | X와 일치하는 패턴을 검사 |
| 도구 허용 목록 | 에이전트가 호출할 수 있는 함수들을 제한한다 |
충분히 능력 있는 에이전트는 다음을 안다:
- 시스템 프롬프트를 읽거나(추론) 할 수 있다.
- 출력 필터가 잡아내는 패턴을 테스트할 수 있다.
- 사용 가능한 도구와 그 매개변수를 열거할 수 있다.
- 의도된 것과 강제된 것 사이의 차이를 추론할 수 있다.
이것은 이론적인 것이 아니다. 다단계 계획이 가능한 모델은 자신의 제약을 모델링할 수 있다.
문제는 가드레일을 이해할지가 아니라 언제 이해하느냐이다.
AI 에이전트를 위한 케르크호프스 원칙
1883년, 오귀스트 케르크호프스는 모든 암호학자가 절대적인 원칙으로 여기는 원칙을 제시했다:
시스템은 키를 제외한 모든 것이 알려져 있어도 안전해야 한다.
AI 에이전트에 적용하면: 여러분의 인증 시스템은 에이전트가 작동 방식을 완벽히 알고 있더라도 안전해야 한다.
주요 프레임워크가 Kerckhoffs 원칙에 어떻게 부합하는가
| Framework | Agent knows the rules? | Still secure? |
|---|---|---|
| System‑prompt restrictions | Yes (it receives the prompt) | No – can craft edge cases |
| Output filtering (Guardrails AI) | Can probe by trial‑and‑error | Partially – oracle attacks degrade it |
| Tool allowlists | Yes (it sees available tools) | No – can chain allowed tools into unintended outcomes |
| Rate limiting | Can observe its own throughput | No – maximizes damage within the limit |
| K‑of‑N threshold authorization | Yes (understands the protocol) | Yes – knowledge doesn’t help forge K independent approvals |
핵심 통찰: 임계값 인증은 Kerckhoffs 원칙 하에서도 안전을 유지하는 유일한 메커니즘이다.
에이전트는 Shamir Secret Sharing이 어떻게 동작하는지 정확히 이해하고, K‑of‑N 프로토콜을 공부하며 코드를 암기할 수 있다. 그러나 이것이 에이전트가 제어하지 않는 K개의 독립적인 승인을 위조하는 데는 도움이 되지 않는다.
논리적 제약 vs. 구조적 제약
| Type | Example |
|---|---|
| Logical constraint | if "transfer" in action and amount > 10000: block() |
| Structural constraint | “Requires 3‑of‑5 threshold signatures from independent nodes.” |
논리적 제약은 전송을 분할하거나 동의어를 사용하거나 예상치 못한 경계 상황을 찾아 우회할 수 있다.
구조적 제약은 필요한 독립 노드를 손상시키지 않으면 우회할 수 없으며, 규칙을 이해하는 것만으로는 무의미하다.
IC‑AGI: 네 (실제로는 다섯) 개의 구조적 방어
각 레이어는 에이전트가 방어 메커니즘을 완전히 알고 있더라도 효과를 유지하도록 설계되었습니다.
레이어 1 – 임계값 승인
중요한 작업은 K‑of‑N 독립 승인(K ≥ 2)이 필요합니다. 임계값은 초기화 시점에 강제됩니다:
if threshold = 2 (no unilateral authority)
에이전트는 자신의 요청을 스스로 승인할 수 없으며, K개의 독립 승인자를 손상시켜야 합니다. 이는 서로 다른 조직이나 관할 구역에 걸쳐 있을 수 있습니다. 이는 조정 문제이며, 지능 문제가 아닙니다.
레이어 2 – 안티‑오라클 탐지
시스템은 엔터티별로 슬라이딩 윈도우를 사용해 쿼리 패턴을 추적합니다. 반복되거나 체계적으로 변형된 쿼리는 의심 점수를 올리며, 점수가 임계값을 초과하면 해당 엔터티를 차단합니다.
@dataclass
class AntiOracleConfig:
window_seconds: float = 120.0
max_identical_queries: int = 5
max_similar_queries: int = 15
suspicion_threshold: float = 0.8
에이전트가 이 탐지 메커니즘을 알고 있더라도 탐색 속도를 늦출 수 있을 뿐입니다. 필요한 예산(레이어 3 참고)이 소진되면 충분한 데이터를 수집하기 전에 중단됩니다.
레이어 3 – 소모형 예산 토큰
각 기능 토큰은 유한 예산을 가지고 있으며 사용될 때마다 감소합니다 – 이는 속도 제한이 아닌 하드 캡입니다.
{
"scope": "crm.update",
"budget": 50,
"ttl": "3600s"
}
50번 사용하면 토큰은 소멸합니다. 빠른 탐색은 레이어 2에 의해 차단되고, 느린 탐색은 예산 상한에 의해 중단됩니다. 두 방어가 결합되어 전략에 관계없이 오라클 공격을 경제적으로 불가능하게 만듭니다.
레이어 4 – 회로 차단기 격리
작업자가 비정상적인 행동(높은 오류율, 예상치 못한 패턴)을 보이면 회로 차단기가 작동해 해당 작업자를 격리합니다.
CLOSED (healthy) → failure rate > threshold → OPEN (blocked)
↑
recovery timeout |
↓
CLOSED ← probe succeeds ← HALF_OPEN (one probe allowed)
회로 차단기의 동작을 이해한다고 도움이 되지 않습니다: 차단기는 행동에 반응할 뿐, 의도에는 반응하지 않기 때문입니다. 정상적인 행동은 차단기를 닫힌 상태로 유지하고, 비정상적인 행동은 격리를 유발합니다.
레이어 5 – 샌드박스 실행
에이전트 코드가 실행될 때는 AST‑레벨 화이트리스트를 적용하는 샌드박스 안에서 실행됩니다. 코드의 한 바이트가 실행되기 전에 모든 AST 노드가 화이트리스트와 대조 검토되어, 허용된 구성만 실행되도록 보장합니다.
(원본 스니펫은 일부 생략되었습니다; 샌드박스 구현은 동일한 원칙을 따릅니다.)
왜 이것이 작동하는가
이 구조적 방어는 에이전트에게 지배 전략 균형을 만듭니다:
- 에이전트에게 가장 좋은 행동은 정상적으로 동작하는 것이며, 시스템을 전복하려는 시도는 (임계값, 예산) 때문에 실패하거나 격리(회로 차단기, 샌드박스)됩니다.
- 방어 메커니즘에 대한 지식이 공격 비용을 낮추지는 않으며, 단지 방어가 견고함을 확인시켜 줄 뿐입니다.
요약
논리적 가드레일 (시스템 프롬프트, 출력 필터, 도구 허용 목록)은 지능형 에이전트가 읽고 탐색할 수 있기 때문에 취약합니다.
구조적 방어—임계값 권한 부여, 안티‑오라클 탐지, 소모 가능한 예산, 회로 차단기 격리, 그리고 샌드박스 실행—은 Kerckhoffs 원칙 하에서도 안전합니다.
이 메커니즘들을 계층화함으로써, 에이전트가 가드레일에 대해 모든 것을 알더라도 제어를 유지하는 AI‑에이전트 시스템을 구축할 수 있습니다.
# Security Architecture Overview
> This isn't a filter that can be bypassed with creative encoding. It's a whitelist.
> If it's not explicitly in the safe set, it doesn't run. Period.
```python
# Whitelisted names – no imports, no exec, no eval, no filesystem, no network.
_FORBIDDEN_NAMES = frozenset({
"import", "__import__", "exec", "eval", "compile",
"open", "input", "os", "sys", "subprocess", "socket",
"pathlib", "io", "ctypes", "signal", ...
})
## 핵심 논제 (Blog #1 재진술)
각 개별 레이어는 충분히 능력 있는 에이전트에 의해 무력화될 수 있지만, **전체 조합은 무력화될 수 없습니다**.
- 임계값 인증을 이해하는 에이전트는 시스템을 탐색하려 시도할 수 있습니다.
*anti‑oracle 탐지기가 탐색을 감지합니다.*
- 탐지를 피하기 위해 탐색 속도를 늦추는 에이전트는 예산 토큰이 소진됩니다.
*budget‑token 제한기가 이를 차단합니다.*
- 워커를 이용하려는 에이전트는 회로 차단기에 의해 잡힙니다.
*circuit‑breaker가 악용을 중단합니다.*
- 악성 코드를 실행하려는 에이전트는 AST 화이트리스트에 걸립니다.
*화이트리스트가 코드를 차단합니다.*
> 한 레이어에서 탈출하는 모든 경로는 다른 레이어의 집행 영역으로 이어집니다.
> 그것은 우연이 아니라—아키텍처입니다.
## 왜 지금 중요한가
- **현재 모델** (GPT‑4, Claude, Gemini)은 이미 코드와 게임 이론에 대해 추론하고, 모델 제약을 모델링하며, 엣지 케이스를 찾을 수 있습니다.
- **미래 모델**은 이것을 더 잘하게 될 것이며, 더 못하게 되지는 않을 것입니다.
에이전트가 자신의 작동 방식을 이해하지 *not* 못하도록 하는 **에이전트‑제어 시스템**에 의존한다면, 시간은 한정되어 있습니다. 모델 능력과 가드레일 정교함 사이의 격차는 매 분기마다 좁혀지고 있습니다.
## 행동 촉구
- 질문은 구조적 권한 부여를 **채택할지 여부**가 아니라 **언제**인지는—첫 번째 대형 사고 이전인지 이후인지입니다.
### IC‑AGI 프로젝트
- Apache 2.0 라이선스 하에 오픈소스
- **273 테스트**, **159 공식 검증**, **안전 위반 제로**
- 시스템을 완벽히 이해하는 적을 대비해 처음부터 설계됨
구성 요소가 어디서 무너지나요? **이슈를 열**거나 댓글을 남겨 주세요.
## 다음 시리즈: 사용 가능한 예산 토큰: AI 에이전트를 위한 OAuth