본문으로 건너뛰기

Recurrent state는 새로운 공격 표면인가?

· 약 6분
p4r4d0xb0x
p4r4d0xb0x
Rustacean, AI, OSS Enthusiast

cover placeholder

Transformer 시스템에서 보안 논의는 프롬프트, 툴 인자, 검색 문서, 출력 필터를 중심으로 전개되어 왔다. recurrent 또는 SSM 계열을 운영하면 여기에 하나의 질문이 추가된다. 모델이 다음 입력으로 넘기는 hidden state를 누가 만들고, 얼마나 오래 유지하며, 어떤 경계를 넘어 재사용하는가?

이 질문은 “recurrent state가 곧 취약하다”는 뜻이 아니다. 상태가 있다는 사실만으로 공격이 성립하지는 않는다. 다만 상태가 세션 간에 유지되거나, 신뢰 수준이 다른 입력을 섞어 업데이트하거나, 도구 호출의 권한 판단에 영향을 준다면 새로운 보안 자산이자 공격 표면으로 취급해야 한다. 아래의 논문·프로젝트는 서로 다른 층을 다루므로 직접적인 동일시를 피한다.

상태 오염을 위협 모델로 바꾸기​

용어 해설: state poisoning

공격자가 입력이나 저장된 기록을 통해 내부 상태에 악의적·오해를 부르는 정보를 심고, 이후 정상 입력에서 모델의 행동을 원하는 방향으로 유도하려는 위협이다.

용어 해설: provenance

데이터가 어디에서 왔고 어떤 변환을 거쳤는지 추적하는 정보다. 보안에서는 출처가 다른 데이터가 같은 권한으로 취급되지 않게 하는 데 중요하다.

일반적인 recurrent 업데이트를 h_t = f(h_{t-1}, x_t)라 하면 공격 가능 지점은 세 군데다. 첫째, 악의적인 x_t가 상태에 기록되는 순간. 둘째, 오염된 h_t가 다음 단계의 판단에 사용되는 순간. 셋째, 상태가 다른 사용자·세션·도구로 넘어가는 순간이다. 이 모델은 공격을 수식으로 증명하지 않지만, 설계 검토의 체크리스트를 제공한다.

Mamba가 말하는 선택성과 보안상의 함의​

Mamba는 입력에 따라 상태공간 파라미터를 선택적으로 조절해 정보를 선택적으로 전파·망각하는 selective SSM을 제안한다. 논문 초록의 주장은 효율적 시퀀스 모델링과 내용 의존적 상태 업데이트에 관한 것이지, 보안 메커니즘에 관한 것은 아니다.

출처가 말하는 것: Mamba는 긴 시퀀스에서 선형 스케일링과 입력 선택성을 목표로 하며, 여러 작업에서 성능을 보고한다.

보안적 해석: 선택적 업데이트는 유용한 정보와 공격자가 심은 정보를 구별하는 인증 장치가 아니다. 오히려 상태에 무엇을 남길지 결정하는 함수가 생겼다는 의미에서, 상태 업데이트를 감사·검증해야 할 이유가 커진다. 어떤 토큰이 상태를 크게 바꾸는지, 상태가 민감한 도구 호출을 제어하는지, 세션 경계에서 초기화되는지 확인해야 한다. Mamba 논문만으로 특정 poisoning 공격의 성공을 주장할 수는 없으며, 그 부분은 unverified다.

Hidden State Poisoning: 직접 확인이 필요한 증거​

“Hidden State Poisoning”은 이 글의 위협 모델과 직접 맞닿은 지정 출처다. arXiv의 초록은 Mamba 계열 모델에서 짧은 트리거가 은닉 상태를 오염시켜 정보 검색을 약화시키는 HiSPA와 RoBench-25 평가를 보고한다. 다만 공격 절차, 성공률, 특정 모델의 취약성 범위 같은 세부는 원문 본문과 실험 절을 추가로 확인해야 하므로 이 글에서는 제한적으로 다룬다.

검증 가능한 범위 밖에서 안전하게 말할 수 있는 것은 개념적 질문뿐이다. 만약 외부 입력이 hidden state에 누적되고 이후의 의사결정에 영향을 준다면, 입력 필터만으로는 충분하지 않을 수 있다. 상태 자체를 신뢰하는 순간 공격자는 한 번의 입력이 아니라 이후 여러 단계에 영향을 미치는 지속성을 얻을 수 있기 때문이다. 이것은 논문 결과의 재현이 아니라, 제목이 지시하는 위협을 recurrent 시스템에 적용한 분석적 가설이다.

정확한 출처가 추가되면 확인해야 할 항목은 상태 접근 방식, 공격자가 관찰 가능한 출력, 상태 초기화 여부, 공격 지속 시간, 방어 실험의 기준선이다.

에이전트 보안 맥락: trajeckt는 상태를 어떻게 다루는가​

trajeckt는 에이전트의 각 도구 호출을 독립적으로 허용하는 대신, 사전에 봉인한 허용 궤적과 실행 중 데이터 흐름을 검사하는 게이트웨이로 설명된다. 저장소 문서의 예시는 데이터베이스 읽기→요약→외부 전송 같은 다단계 흐름에서 마지막 유출을 차단하는 방식이다.

이 설계는 recurrent hidden state 자체를 검사한다고 주장하지 않는다. 그러나 중요한 보안 원칙을 제공한다. 에이전트가 보고하는 현재 문맥이나 내부 계획만 믿지 않고, 에이전트 바깥에서 궤적과 provenance를 관리하는 것이다. recurrent state가 오염되더라도 도구 호출 권한과 데이터 싱크가 외부 정책으로 제한되어 있으면 피해 반경을 줄일 수 있다.

제한: trajeckt 문서가 명시하듯 의미 기반 공격, 허용된 인과 경로 안에 숨은 공격, 기존 RBAC·인자 검증을 대체하는 문제는 남는다. 따라서 trajectory enforcement를 hidden-state 무결성 증명으로 해석해서는 안 된다.

Valmis: 격리와 프록시가 만드는 신뢰 경계​

Valmis 저장소는 컨테이너 격리, 프록시를 통한 자격증명 보호, 에이전트 메모리·임베딩과 멀티스텝 워크플로우를 강조한다. 여기서 메모리는 recurrent hidden state가 아니라 pgvector와 임베딩을 사용하는 외부 메모리 층으로 설명된다.

이 차이는 보안상 중요하다. 외부 메모리는 검색·쓰기 권한, 데이터베이스 감사 로그, 테넌트 분리, 삭제 정책을 설계할 수 있다. 반면 런타임의 hidden state는 모델 계산 그래프 내부에 있어 같은 방식의 접근제어와 포렌식이 어렵다. Valmis의 프록시는 원시 자격증명을 에이전트가 직접 보지 않게 하지만, 프록시·호스트가 새로운 신뢰 중심이 된다는 한계도 기존 글에서 확인했다.

출처와 해석의 경계: Valmis README는 보안 중심 아키텍처를 설명하지만 외부 보안 감사나 hidden-state poisoning 방어를 입증하지 않는다. 이 글은 제품 기능을 공격 방어의 증거로 과장하지 않는다.

“새 공격 표면”에 대한 운영 체크리스트​

  1. 수명: 상태가 요청·사용자·테넌트 사이에서 재사용되는가? 기본값은 세션 경계에서 초기화하는 쪽이 안전하다.
  2. 출처: 신뢰된 시스템 이벤트와 사용자 텍스트가 같은 업데이트 경로로 들어가는가? provenance를 별도로 기록해야 한다.
  3. 권한: 상태가 툴 선택, 외부 쓰기, 자격증명 사용을 직접 결정하는가? 그렇다면 상태만으로 승인하지 말고 외부 정책을 둔다.
  4. 관찰성: 상태 변화의 크기·원인·시점을 기록할 수 있는가? 원본 state를 그대로 로그에 남기면 민감 정보가 새로 유출될 수 있으므로 해시·통계·샘플링을 검토한다.
  5. 복구: 오염 의심 시 상태를 폐기하고 검증된 체크포인트에서 재생성할 수 있는가?
  6. 외부 메모리와 분리: 검색 DB의 기록과 ephemeral hidden state를 같은 신뢰도로 취급하지 않는가?

결론과 제한​

Recurrent state는 자동으로 취약점이 되는 것이 아니지만, 지속성·불투명성·권한 영향이라는 세 조건을 가질 때 새로운 공격 표면으로 모델링할 이유가 충분하다. Mamba는 선택적 상태 업데이트라는 기술적 가능성을 보여주지만 보안 보장은 제공하지 않는다. Hidden State Poisoning은 직접적인 위협 가설을 가리키지만, 이 초안에서 정확한 서지와 실험은 검증되지 않았다. trajeckt는 에이전트 바깥의 궤적·데이터 흐름 통제로 피해를 제한하는 맥락을, Valmis는 컨테이너·프록시·외부 메모리의 신뢰 경계를 보여준다.

따라서 실무 결론은 상태를 무조건 암호화하라는 단순한 처방이 아니다. 상태의 수명과 출처를 분리하고, 민감한 행동은 외부 정책으로 재검증하며, 오염 시 폐기·복구 가능한 구조를 갖추라는 것이다. 특히 이 글에 포함된 Hidden State Poisoning의 공격 세부, 모델별 재현성, Valmis의 실제 운영 보안성은 추가 원문·코드 검토 전까지 unverified로 남긴다.

Sources​

// COMMENTS

댓글