AI 에이전트 샌드박스용 감사 로그는 명령 및 프로세스 실행, 파일 읽기 및 쓰기, 아웃바운드 네트워크 호출 및 이그레스 대상, 패키지 설치 이벤트, 도구 호출, 세션 수준의 모델 입력 및 출력 요약, 리소스 한계 도달, 세션 수명 주기 이벤트를 반드시 캡처해야 합니다. 이러한 범위가 없으면 보안 팀은 에이전트가 수행한 작업을 재구성하거나, 침해를 추적하거나, 사후 검토를 만족시킬 수 없습니다. 이러한 범주 중 어느 하나라도 누락되면 사후에 수정하기 어렵거나 불가능한 사각지대가 발생합니다.
AI 에이전트 샌드박스에 다른 감사 로깅이 필요한 이유
기존 서버 감사 로그는 사람이나 결정론적 애플리케이션 프로세스가 각 작업을 트리거했다고 가정합니다. AI 에이전트는 그 가정을 깨뜨립니다. 단일 프롬프트로 세션이 패키지를 설치하고, 파일을 쓰고, 셸 명령을 실행하고, 외부 API를 호출하고, 하위 프로세스를 생성할 수 있습니다. 모든 것이 몇 초 내에 이루어지며, 개별 단계에 대한 사람의 승인 없이 진행됩니다.
이것은 감사 로그가 답해야 하는 질문을 바꿉니다. 기존 서버의 경우 일반적으로 "권한 있는 사용자가 이 파일을 변경했는가?"라는 질문입니다. 에이전트 샌드박스의 경우 질문은 다음과 같습니다:
- 모델이 무엇을 실행하기로 결정했고, 어떤 순서로 실행했는가?
- 어떤 셸 명령이 실행되었으며, 어떤 프로세스로 실행되었는가?
- 에이전트가 예상치 못한 파일에 접근했는가?
- 네트워크를 통해 샌드박스 밖으로 나간 것은 무엇이며, 어디로 갔는가?
- 패키지 설치로 예상치 못한 코드가 도입되었는가?
- 리소스 한계에 도달하거나 종료되었을 때 에이전트는 무엇을 하고 있었는가?
이러한 질문에 답할 수 있는 로그 시스템은 보안 팀에 필요한 재구성 능력을 제공합니다. 그렇지 못한 로그 시스템은 사고 대응을 추측에 의존하게 만듭니다.
명령 및 프로세스 실행 로그
프로세스 실행은 가장 우선순위가 높은 범주입니다. 에이전트가 직접 또는 셸 하위 프로세스를 통해 실행하는 모든 명령은 다음을 포함하는 로그 항목을 생성해야 합니다: 프로세스 이름 및 전체 인수 목록, 부모 프로세스 및 PID, 사용자 및 유효 UID, 작업 디렉토리, 밀리초 미만 정밀도의 타임스탬프, 종료 코드.
인수 목록이 없으면 python, curl 또는 bash와 같은 명령은 사고 후 추적에서 거의 의미가 없습니다. UID가 없으면 에이전트가 상승된 권한으로 실행되었는지 알 수 없습니다. 부모 PID 체인이 없으면 중첩된 하위 프로세스를 재구성하거나 명령이 어떻게 호출되었는지 이해할 수 없습니다.
execve, execveat과 같은 적절한 syscall 규칙을 사용하는 auditd와 같은 Linux 감사 하위 시스템은 마이크로VM 게스트 내에서 커널 수준에서 이를 캡처할 수 있습니다. 컨테이너 기반 샌드박스는 대안으로 eBPF 기반 추적 또는 seccomp 로깅을 사용할 수 있으며, 각 접근 방식은 서로 다른 범위와 성능 트레이드오프가 있습니다. 보안 팀의 관점에서 핵심 요구 사항은 로그가 애플리케이션 계층 아래에서 생성된다는 것입니다. 자신의 로깅을 제어하는 에이전트 프로세스는 자신의 동작을 정확하게 보고하는 것을 신뢰할 수 없습니다.
파일 시스템 접근 이벤트
파일 시스템 감사 범위는 읽기, 쓰기, 삭제, 이름 변경 및 마운트 작업을 로깅해야 합니다. 각 이벤트에 대해 로그에는 다음이 포함되어야 합니다: 작업 유형, 전체 경로, 담당 프로세스 및 PID, UID, 타임스탬프.
실제로 바쁜 샌드박스에서 모든 파일 읽기를 로깅하면 많은 양이 생성될 수 있습니다. 보안 팀은 종종 이를 민감한 경로로 좁힙니다. 예를 들어 /etc, /root, 에이전트의 작업 공간 디렉토리, 자격 증명 파일 위치, 마운트된 비밀 아래의 모든 경로입니다. 대부분의 위협 모델에서 쓰기와 삭제는 읽기보다 우선순위가 높지만, 자격 증명 또는 구성 파일의 읽기는 캡처할 가치가 있습니다.
파일 시스템 이벤트는 특히 데이터 유출 시도(큰 읽기 후 아웃바운드 네트워크 호출), 예상치 못한 구성 변경(에이전트가 건드리면 안 되는 파일에 쓰기), 정리 동작(세션 종료 시 실행된 삭제는 활동을 숨기려는 시도를 나타낼 수 있음)을 식별하는 데 유용합니다.
아웃바운드 네트워크 호출 및 이그레스 로깅
이그레스 로깅은 에이전트 샌드박스 배포에서 가장 흔히 간과되는 영역 중 하나입니다. 많은 샌드박스가 네트워크 연결이 시도되었다고 로깅하지만, 어디로 갔는지, 어떤 프로토콜이 사용되었는지, 성공했는지 여부를 로깅하는 경우는 훨씬 적습니다.
완전한 이그레스 로그 항목에는 다음이 포함되어야 합니다: 대상 IP 주소 및 포트, 확인된 도메인 이름(DNS 쿼리 및 응답), 프로토콜(TCP, UDP, HTTP 등), 각 방향으로 전송된 바이트 수, 연결을 연 프로세스, UID, 타임스탬프.
DNS 쿼리 로깅은 별도로 중요합니다. 나중에 연결이 차단되더라도 예상치 못한 도메인을 쿼리하는 에이전트는 캡처할 가치가 있는 신호입니다. DNS over HTTPS는 샌드박스가 이를 가로채는 수준에서 네트워크 정책을 시행하지 않으면 쿼리 로깅을 우회할 수 있습니다.
허용 목록 기반 이그레스 제어를 제공하는 샌드박스는 허용된 연결 시도와 차단된 연결 시도를 모두 로깅해야 합니다. 예상치 못한 대상에 대한 차단된 시도의 높은 볼륨은 그 자체로 의미 있는 보안 신호입니다.
패키지 설치 이벤트
패키지 설치는 세션 기간 동안 지속되고 잠재적으로 다운스트림 작업에 영향을 미치는 방식으로 런타임 환경을 변경하기 때문에 높은 가치의 감사 대상입니다. 각 설치 이벤트는 다음을 캡처해야 합니다: 호출된 패키지 관리자(pip, npm, apt, cargo 등), 패키지 이름, 요청된 버전, 확인된 버전, 소스 URL 또는 레지스트리, 패키지 해시 또는 체크섬, 프로세스 및 UID, 타임스탬프.
소스 URL이 중요합니다. 개인 레지스트리, 직접 URL 또는 비정상적인 미러에서 설치된 패키지는 기본 공용 레지스트리에서 설치된 것과 다른 위험 프로필을 가집니다. 해시는 사고 후 확인을 위해 중요합니다. 나중에 패키지가 악성으로 밝혀진 경우 해당 세션에서 정확한 버전이 설치되었는지 알고 싶을 것입니다.
패키지 설치를 완전히 차단하는 샌드박스는 이 위험 범주를 제거하지만 에이전트가 할 수 있는 작업을 상당히 제한합니다. 대부분의 프로덕션 배포는 중간 경로가 필요합니다: 모든 것을 로깅하고, 승인된 소스 목록에서 설치를 허용하며, 알 수 없는 소스에서의 설치는 플래그 지정 또는 차단합니다.
도구 호출 및 결과
AI 에이전트는 일반적으로 모델이 명명된 작업(코드 실행, 파일 읽기, API 호출, 웹 검색)을 요청하고 오케스트레이션 계층이 이를 실행하는 도구 호출 메커니즘을 통해 작동합니다. 이러한 도구 호출은 OS 수준 위에 있으며 애플리케이션 계층 이벤트이지만, 시스템 수준의 결과뿐만 아니라 모델의 의도를 나타내기 때문에 로깅하는 것이 중요합니다.
도구 호출 로그는 다음을 캡처해야 합니다: 도구 이름, 입력 매개변수 요약(비밀 또는 사용자 PII가 포함된 경우 전체 내용 제외), 결과 상태 요약(성공, 오류, 시간 초과), 세션 ID, 타임스탬프.
모든 도구 호출의 전체 입력 및 출력을 로깅하는 것은 디버깅에 유용하지만 개인정보 보호 및 비밀 유출 위험을 만듭니다. 실용적인 접근 방식은 도구 이름과 상태를 조건 없이 로깅하고, 구성 가능한 상세 수준에서 입력/출력 요약을 로깅하며, 조사 중에 특정 세션에 대한 전체 세부 정보를 적절한 액세스 제어로 검색할 수 있는 방법을 제공하는 것입니다.
목표는 로그 저장소 자체가 고가치 대상이 되지 않으면서 에이전트의 행동 순서를 재구성할 수 있는 충분한 신호를 제공하는 것입니다.
세션 수명 주기 이벤트
세션 수명 주기 이벤트는 다른 모든 로그 항목의 기준점 역할을 합니다. 모든 이벤트 유형에 나타나는 세션 ID는 범주 간 로그를 결합하고 "이 특정 실행에서 무슨 일이 일어났는가?"에 답할 수 있게 합니다.
로깅할 수명 주기 이벤트:
| 이벤트 | 주요 필드 |
|---|---|
| 세션 생성 | 세션 ID, 사용자/테넌트 ID, 템플릿 또는 이미지 이름, 리소스 구성, 타임스탬프 |
| 세션 시작 | 세션 ID, 호스트 식별자, 할당된 리소스 한계, 타임스탬프 |
| 세션 일시 중지 | 세션 ID, 이유(API 호출, 시간 초과, 자동 일시 중지), 타임스탬프 |
| 세션 재개 | 세션 ID, 재개한 주체, 타임스탬프 |
| 세션 종료 | 세션 ID, 종료 이유(정상, 시간 초과, OOM, API 호출, 정책 위반), 종료 상태, 타임스탬프 |
| 세션 정리 | 세션 ID, 정리 시 파일 시스템 상태(보존됨, 삭제됨, 스냅샷 저장됨), 타임스탬프 |
종료 이유는 사고 후에 특히 유용합니다. 정책 위반, OOM 종료 또는 예상치 못한 신호로 인해 정상 종료가 아닌 방식으로 종료된 세션은 더 면밀히 조사할 가치가 있습니다. 일시 중지된 후 재개된 세션은 상태 연속성에 대해 조사할 가치가 있습니다. 일시 중지와 재개 사이에 환경에서 변경된 사항이 있는가?
리소스 한계 이벤트
리소스 한계 이벤트는 세션이 구성된 한계에 도달하고 시스템이 조치를 취한 순간을 캡처합니다. 이러한 이벤트는 정상적인 높은 부하 동작 또는 더 우려되는 무언가(폭주 프로세스, 예상치 못한 계산 버스트 또는 리소스 소진을 위한 의도적인 시도)를 나타냅니다.
리소스 한계 이벤트의 로그 항목에는 다음이 포함되어야 합니다: 한계 유형(CPU 스로틀, 메모리 OOM, 디스크 할당량, 네트워크 속도 제한, 시간 초과), 이벤트 당시 측정된 값, 구성된 한계, 취해진 조치(스로틀, 종료, 경고), 영향을 받은 프로세스 또는 세션, 타임스탬프.
OOM 종료는 특히 조사할 가치가 있습니다. 에이전트가 예상되지 않은 대규모 계산을 시도했거나, 예상치 못하게 큰 데이터를 로드한 패키지가 있거나, 메모리 누수가 있을 수 있습니다. 경량 LLM 호출만 수행해야 하는 세션에서 CPU 스로틀 이벤트가 발생하면 샌드박스 내부에서 다른 것이 실행되고 있음을 나타낼 수 있습니다.
구조화된 로그 형식과 비구조화된 로그 형식
비구조화된 로그(2026-06-29 10:04:00 INFO: process python started와 같은 자유 텍스트 줄)는 읽을 수 있지만 쿼리, 집계 또는 SIEM이나 알림 파이프라인과 통합하기 어렵습니다. 감사 목적의 경우 로그 형식이 변경될 때 중단되는 구문 분석이 필요합니다.
구조화된 로그(일반적으로 JSON 또는 CEF, OCSF와 같은 공통 스키마 형식)는 모든 필드를 직접 인덱싱, 쿼리 및 알림할 수 있습니다. {"ts": "2026-06-29T10:04:00.123Z", "event": "process.exec", "session_id": "...", "pid": 1234, "ppid": 1, "uid": 0, "cmd": "curl", "args": ["-s", "https://..."], "exit_code": 0}를 포함하는 구조화된 execve 이벤트는 해당 필드 중 하나로 즉시 쿼리할 수 있습니다.
샌드박스 제공자를 평가하는 보안 팀의 핵심 질문은 다음과 같습니다:
- 로그가 구조화되어 있습니까, 비구조화되어 있습니까?
- 어떤 스키마 또는 형식이 사용되며, 문서화되어 있습니까?
- 로그를 실시간으로 외부 SIEM 또는 로그 집계 시스템으로 스트리밍할 수 있습니까?
- 이벤트와 로그 스트림에서 사용 가능한 시점 사이의 지연 시간은 얼마입니까?
실시간 또는 거의 실시간 스트리밍은 탐지 사용 사례에 중요합니다. 세션이 종료된 후 몇 시간 후에만 사용 가능한 로그는 사고 재구성에는 유용하지만 실시간 알림에는 적합하지 않습니다.
로그 무결성 및 변조 증거
에이전트가 수정할 수 있는 감사 로그는 감사 로그가 아닙니다. 이것이 변조 증거 요구 사항입니다. 로그는 에이전트 프로세스가 자체 항목을 변경, 삭제 또는 억제할 수 없는 방식으로 생성 및 저장되어야 합니다.
구현 수준에서 이는 일반적으로 다음을 의미합니다:
- 샌드박스 내부의 애플리케이션 수준 로깅이 아닌 커널 수준 로그 생성(감사 하위 시스템, eBPF)
- 샌드박스 프로세스가 도달할 수 없는 외부 대상으로 로그 전송
- 샌드박스 네트워크에서 접근 가능한 삭제 API가 없는 쓰기 전용 또는 추가 전용 로그 저장소
- 생성 시 로그 항목에 서명 또는 체크섬을 적용하여 사후에 변조 또는 잘림 감지 가능
관리형 샌드박스 제공자의 경우 관련 질문은 에이전트의 프로세스가 로그 전달을 수정할 수 있는 경로가 있는지 여부입니다. 로그가 샌드박스 내부의 파일에 기록된 다음 전송되는 경우, 충분히 권한이 있는 에이전트 프로세스가 전송을 방해할 수 있습니다. 로그가 하이퍼바이저 또는 호스트 수준에서 생성되어 대역 외로 전송되는 경우 에이전트는 접근할 수 없습니다.
로그 데이터의 관리 체인(특히 규정 준수 또는 법적 검토에 중요)은 로그 수집 경로, 저장소 액세스 제어 및 원시 이벤트에 적용된 모든 변환이 문서화되고 감사 가능해야 함을 요구합니다.
AI 에이전트 샌드박스의 감사 로그 보존 정책
AI 에이전트 샌드박스의 감사 로그 보존 요구 사항은 규제 환경, 워크로드의 위험 프로필 및 보안 팀이 지원해야 하는 사고 대응 타임라인에 따라 다릅니다.
보안 팀이 평가할 수 있는 실용적인 시작점:
| 사용 사례 | 권장 최소 보존 기간 |
|---|---|
| 활성 사고 조사 | 최소 90일 동안 핫/쿼리 가능 |
| 사고 후 포렌식 | 12~24개월 동안 콜드 스토리지에서 사용 가능 |
| 규정 준수 검토(SOC 2, ISO 27001) | 해당 프레임워크 요구 사항에 따름 |
| 법적 보존 | 명시적으로 해제될 때까지 |
AI 에이전트 워크로드의 경우 90일의 핫 스토리지는 의미 있는 기준입니다. 자율 에이전트의 침해 패턴은 즉시 발견되지 않을 수 있기 때문입니다. 3주 전 세션 중에 데이터를 유출한 에이전트는 다운스트림 이상 현상이 발견될 때까지 식별되지 않을 수 있습니다.
볼륨은 실제 비용 요소입니다. 하루에 수천 개의 세션을 실행하고 전체 execve 및 네트워크 로깅을 수행하는 샌드박스는 상당한 데이터를 생성할 수 있습니다. 계층형 스토리지(최근 데이터용 핫, 중기용 웜, 아카이브용 콜드)는 일반적인 접근 방식입니다. 압축 및 필드 수준 필터링(높은 우선순위 이벤트 유형만 전체 충실도로 로깅)도 고려할 가치가 있지만, 필터링된 로그는 예상치 못한 이벤트 유형을 놓칠 수 있는 트레이드오프가 있습니다.
사고 대응을 위한 로그 표면화
로그를 수집하는 것은 필요하지만 충분하지 않습니다. 아무도 쿼리하지 않는 버킷에 있는 로그는 보호 기능을 제공하지 않습니다. 보안 팀의 운영 요구 사항은 특정 질문에 신속하게 답할 수 있는 능력입니다:
- 세션 X가 T1과 T2 시간 사이에 무엇을 했는가?
- 경로 P에 접근한 세션은 무엇인가?
- 도메인 D로 아웃바운드 연결을 한 세션은 무엇인가?
- 패키지 V를 설치한 세션은 무엇인가?
- R 이유로 종료된 세션은 무엇인가?
이를 위해서는 세션 ID, 이벤트 유형, 타임스탬프 범위, 경로, 도메인 및 기타 주요 필드가 인덱싱되고 검색 가능한 쿼리 인터페이스(SIEM 통합, 로그 분석 플랫폼 또는 제공자가 제공하는 API)가 필요합니다.
특정 패턴에 대한 알림은 두 번째 계층입니다. AI 에이전트 샌드박스의 높은 우선순위 신호는 다음과 같습니다: 알려진 위험한 명령 실행(curl | bash, wget -O - | sh, base64 -d | sh), 예상치 못한 또는 새로 등록된 도메인으로의 아웃바운드 연결, 레지스트리가 아닌 URL에서의 패키지 설치, 자격 증명 파일 경로에 대한 쓰기 이벤트, 정책 위반 또는 OOM 종료로 종료되는 세션, 에이전트가 루트로 실행되지 않아야 할 때 UID 0에서 발생하는 모든 이벤트.
에이전트 샌드박스 동작 패턴에 맞게 조정된 사전 구축된 탐지 규칙은 새로운 활동에 대한 첫 알림까지의 시간을 줄여줍니다. 샌드박스 제공자를 평가하는 보안 팀은 제공자가 탐지 규칙, 로그 스키마 문서 및 샘플 SIEM 통합을 제공하는지, 아니면 해당 계층을 전적으로 고객에게 맡기는지 물어봐야 합니다.
샌드박스 제공자에게 물어볼 사항
감사 로그 범위에 대해 AI 에이전트 샌드박스를 평가할 때 제공자에게 물어볼 구체적인 질문은 다음과 같습니다:
- 기본적으로 로깅되는 이벤트 범주는 무엇이며, 구성이 필요한 것은 무엇인가요?
- 로그가 커널/하이퍼바이저 수준에서 생성됩니까, 아니면 샌드박스 프로세스 내부에서 생성됩니까?
- 어떤 구조화된 로그 형식이 사용되며, 스키마가 공개적으로 문서화되어 있습니까?
- 로그를 실시간으로 외부 대상으로 스트리밍할 수 있습니까?
- 데이터 보존 정책은 무엇이며, 연장할 수 있습니까?
- 샌드박스 프로세스가 자체 로그 항목을 수정하거나 억제할 수 있는 경로가 있습니까?
- 로그 항목에 서명되거나 변조 증거가 있습니까?
- 쿼리 API 또는 SIEM 통합이 제공됩니까?
- 일반적인 샌드박스 위협 패턴에 대한 사전 구축된 탐지 규칙 또는 알림 템플릿이 있습니까?
기본적으로 로깅이 완벽한 샌드박스 배포는 없습니다. 제공자가 수집하는 것과 보안 팀이 사고를 재구성하는 데 필요한 것 사이의 격차는 일반적입니다. 사고 후가 아닌 배포 전에 이러한 격차를 식별하는 것이 이러한 평가의 실질적인 이점입니다.
Novita Agent Sandbox는 세션 수명 주기 이벤트, 실행 로그 및 리소스 메트릭을 API를 통해 제공합니다. Novita Agent Sandbox를 평가하는 보안 팀은 아키텍처 결정을 내리기 전에 제품 문서에서 현재 로그 범위, 내보내기 옵션 및 보존 구성을 확인해야 합니다.
결론
AI 에이전트 샌드박스용 감사 로깅은 사고 후에 추가할 수 있는 기능이 아닙니다. 중요한 이벤트 범주(프로세스 실행, 파일 시스템 접근, 이그레스 트래픽, 패키지 설치, 도구 호출, 세션 수명 주기, 리소스 한계)는 워크로드가 프로덕션에 들어가기 전에 범위에 포함되어야 하며, 로그 수집 경로는 에이전트가 접근할 수 없는 외부에 있어야 합니다.
보안 팀을 위한 실용적인 체크리스트는 간단합니다: 샌드박스 제공자가 기본적으로 캡처하는 이벤트 범주를 식별하고, 로그가 에이전트 프로세스 내부가 아닌 커널 또는 하이퍼바이저 수준에서 생성되는지 확인하고, SIEM 통합을 위해 구조화된 출력을 사용할 수 있는지 확인하고, 조사에 필요하기 전에 보존 정책을 수립하십시오.
이러한 영역 중 어느 하나라도 격차가 있다면 "이 에이전트가 무엇을 했는가?"라는 질문에 답할 수 있는 능력에 격차가 있는 것입니다. 그리고 규모에 따라 운영되는 자율 에이전트의 경우, 그 질문은 결국 답이 필요해질 것입니다.
FAQ
AI 에이전트 샌드박스 감사 로그는 어떤 이벤트를 캡처해야 하나요?
최소한: 명령 및 프로세스 실행(전체 인수 목록 포함), 파일 시스템 읽기/쓰기/삭제, 아웃바운드 네트워크 연결 및 DNS 쿼리, 소스 URL 및 해시가 포함된 패키지 설치 이벤트, 도구 호출 및 결과 상태, 세션 수명 주기 이벤트(생성, 일시 중지, 재개, 종료, 정리), 리소스 한계 이벤트(CPU 스로틀, OOM 종료, 시간 초과). 이러한 범주 중 하나라도 누락되면 사후에 재구성할 수 없는 사각지대가 남습니다.
샌드박스 내부의 애플리케이션 수준 로깅에 의존할 수 없는 이유는 무엇인가요?
자체 로깅을 제어하는 에이전트 프로세스는 의도적으로 또는 버그를 통해 자신의 동작에 대한 항목을 억제하거나 수정할 수 있습니다. 커널 수준 수집(auditd, eBPF 또는 하이퍼바이저 계측을 통해)은 에이전트가 쓰기 액세스 권한이 없는 애플리케이션 계층 아래에서 로그 항목을 생성합니다. 이것이 변조 증거 요구 사항입니다: 로그는 에이전트가 도달할 수 없는 위치에서 생성되어야 합니다.
AI 에이전트 샌드박스 감사 로그는 얼마나 오래 보관해야 하나요?
실용적인 기준: 활성 조사를 위해 핫 쿼리 가능 스토리지에 90일, 사고 후 포렌식을 위해 콜드 스토리지에 12~24개월. SOC 2 및 ISO 27001과 같은 규정 준수 프레임워크는 이러한 기준을 대체할 수 있는 자체 요구 사항이 있습니다. 법적 보존의 경우 법무 부서에서 명시적으로 해제할 때까지 보존을 계속해야 합니다.
구조화된 감사 로그와 비구조화된 감사 로그의 차이점은 무엇인가요?
비구조화된 로그는 쿼리하기 위해 구문 분석이 필요한 자유 텍스트 줄입니다. 구조화된 로그는 모든 필드가 직접 인덱싱되고 쿼리 가능한 일관된 스키마(JSON, CEF, OCSF)를 사용합니다. 보안 운영의 경우 구조화된 로그는 SIEM 플랫폼과 통합하고, 탐지 규칙을 작성하고, 사고 대응 중에 쿼리하기가 훨씬 쉽습니다.
AI 에이전트가 자신의 감사 로그를 변조할 수 있나요?
로그가 생성되고 저장되는 위치에 따라 다릅니다. 로그가 샌드박스 내부의 파일에 기록된 다음 외부로 전송되는 경우, 권한 있는 에이전트 프로세스가 전송 파이프라인을 방해할 수 있습니다. 로그가 하이퍼바이저 또는 호스트 수준에서 생성되어 샌드박스 네트워크가 도달할 수 없는 외부 대상에 직접 기록되는 경우, 에이전트가 이를 수정할 경로가 없습니다. 로그 형식뿐만 아니라 로그 수집 아키텍처를 항상 확인하십시오.
샌드박스 제공자의 감사 로그 문서에서 무엇을 찾아야 하나요?
확인: 기본적으로 로깅되는 이벤트 범주와 구성을 요구하는 이벤트 범주; 로그가 커널/하이퍼바이저 수준에서 생성되는지 또는 샌드박스 프로세스 내부에서 생성되는지; 사용되는 구조화된 형식 및 스키마; 외부 시스템으로의 실시간 스트리밍 지원 여부; 기본 보존 정책 및 연장 가능 여부; 사전 구축된 탐지 규칙 또는 SIEM 통합 제공 여부.
