블로그 · 가이드 · 2026년 10월 28일
AEGIS 실행 로그 읽기: 봉인된 도구 호출이 기록하는 것
공개: AEGIS는 100monkeys.ai가 만들고 있으므로 이 가이드는 만든 쪽의 설명으로 읽어 주세요. 이 가이드는 저희 AI 에이전트 하나가 공개 AEGIS 문서(영어), 주로 Deploying & Running Agents, CLI Reference, SEAL Protocol 페이지, 게이트웨이의 Observability 페이지를 바탕으로 초안을 쓰고 회사가 검토했으며, 이 한국어판은 영어 원문 가이드의 번역입니다. 아래의 로그 줄, 필드, 코드는 이 가이드를 위해 저희가 캡처한 출력이 아니라 문서 자체의 예시이며, 인용은 영어 원문 옆에 번역을 붙였습니다.
AEGIS by 100monkeys.ai, in beta는 각 에이전트를 자기만의 격리된 런타임에서 실행하고, 그 도구 호출을 SEAL이라는 서명된 프로토콜로 보냅니다. 이 가이드는 실행 하나를 바깥에서 안으로 읽습니다. 실행 기록, 반복 로그, 그리고 SEAL 계층이 허용되거나 거부된 도구 호출 하나에 대해 기록하는 것입니다.
왜 실행이 단위인가
Executions 페이지는 분명하게 말합니다. "Each execution is the unit of observability and replay in AEGIS. Logs, tool calls, blackboard snapshots, and refinement trajectories are all anchored to an execution ID."(각 실행은 AEGIS에서 관측과 재현의 단위입니다. 로그, 도구 호출, blackboard 스냅숏, 개선 궤적이 모두 실행 ID에 고정됩니다.) 아래의 모든 단계는 그 ID에서 시작합니다. 실행은 "Execute, Evaluate, Refine"(실행, 평가, 개선) 루프를 돌고, "when the agent produces output that satisfies its evaluation criteria, when the iteration budget is exhausted, or when an unrecoverable failure occurs."(에이전트가 평가 기준을 만족하는 출력을 낼 때, 반복 예산이 바닥날 때, 또는 복구할 수 없는 실패가 일어날 때) 끝납니다.
1단계. 실행 ID 찾기
aegis task execute는 시작할 때 그것을 출력합니다(Execution started: <id>). 직접 시작하지 않은 실행은 나열하세요.
aegis task list
aegis task list --agent-id <AGENT_ID>
aegis task list --limit 20
예약 실행은 그 스케줄의 runs 목록에 실행 ID를 담고 있고, 워크플로 실행은 aegis workflow executions list로 나열됩니다.
2단계. 실행 기록 읽기
aegis task status <EXECUTION_ID> --output json
문서에 따르면 이것은 "returns the execution record, including status, start/end timestamps, total iterations, and each iteration's status and validation scores."(상태, 시작과 종료 시각, 전체 반복 수, 각 반복의 상태와 검증 점수를 포함한 실행 기록을 돌려줍니다.) 반복 수를 먼저 읽으세요. 통과한 반복 하나는 깔끔한 실행입니다. 반복이 여러 번이면 출력이 검증에 실패해 개선되었다는 뜻이고, 로그가 그 이유를 보여 줍니다.
3단계. 반복 로그 읽기
aegis task logs <EXECUTION_ID>
실행이 출력하는 내용에 대한 문서의 예시, 한 줄 한 줄 그대로:
[2026-02-23T10:00:01Z] Execution a1b2c3d4-1111-... Started
[2026-02-23T10:00:01Z] Iteration 1 Started
[2026-02-23T10:00:03Z] Tool: fs.write /workspace/solution.py (234 bytes)
[2026-02-23T10:00:04Z] Tool: cmd.run python /workspace/solution.py
[2026-02-23T10:00:05Z] Tool: fs.write /workspace/result.json (89 bytes)
[2026-02-23T10:00:06Z] Iteration 1 Completed
[2026-02-23T10:00:06Z] Validation: exit_code=PASS json_schema=PASS (score=1.0)
[2026-02-23T10:00:06Z] Execution a1b2c3d4-1111-... Completed (1 iteration, 5.2s)
세 종류의 줄로 읽으세요. 생애 주기(started, completed), 에이전트가 한 호출마다 하나씩인 Tool: 줄, 그리고 각 검증기의 판정과 점수가 담긴 Validation: 줄입니다. 실패만 보려면 --errors-only, 더 자세히 보려면 --verbose, 진행 중인 실행을 지켜보려면 --follow를 추가하세요. 워크플로의 경우 aegis workflow logs <EXECUTION_ID> --transitions는 상태 변화만 보여 줍니다.
4단계. 각 Tool 줄 뒤에 무엇이 있는지 알기
각 Tool: 줄은 SEAL을 거친 호출 하나입니다. "Every tool call is wrapped in a SealEnvelope"(모든 도구 호출은 SealEnvelope에 담깁니다). 프로토콜(seal/v1), security_token(attestation 때 발급된 JWT), Ed25519 signature, payload(MCP 방식 호출이면 JSON-RPC tools/call), container_id, 정수 timestamp입니다.
호출을 여러분의 실행에 묶는 것은 토큰의 클레임입니다. sub(호출자), scp(보안 컨텍스트의 이름), wid(워크로드), 그리고 "ties every call in a session to one audit chain"(세션의 모든 호출을 하나의 감사 체인에 묶는) exec_id입니다. 그러니 1단계의 실행 ID가 로그 줄과 그 봉투를 잇는 키입니다.
5단계. 호출이 허용된 이유 읽기
게이트웨이는 호출을 전달하기 전에 아홉 가지 검사를 합니다. 프로토콜 필드, 토큰의 서명과 만료, 호출자의 등록된 키, 정규화된 메시지에 대한 봉투 서명, 30초 이내의 타임스탬프, 그리고 마지막으로 scp에 지정된 보안 컨텍스트입니다. 마지막 검사는 거부 목록에 있는 것은 무엇이든 거부하고, 도구, 경로, 도메인 또는 하위 명령과 속도 제한에 맞는 capability가 있을 때만 호출을 허용하며, 그 밖에는 "(default deny)"(기본 거부)로 거부합니다. 컨텍스트는 세션 도중에 바뀔 수 없습니다. "callers cannot widen their context, switch contexts, or impersonate a different one."(호출자는 자기 컨텍스트를 넓히거나, 컨텍스트를 바꾸거나, 다른 컨텍스트를 사칭할 수 없습니다.)
6단계. 거부 읽기
거부된 호출은 로그 속의 조용한 빈틈이 아닙니다. SEAL Gateway에서는 숫자 코드로 답합니다. 가장 자주 만날 코드는 다음과 같습니다.
2000부터2006까지: 정책. 부여되지 않은 도구, 거부 목록에 있는 도구,path_allowlist밖의 경로,command_allowlist밖의 명령,domain_allowlist밖의 도메인, 속도 제한 도달, 맞는 capability 없음.1003TOKEN_EXPIRED: 토큰이 만료되었거나, 타임스탬프가 30초 범위 밖이거나,jti를 이미 본 경우입니다. 재전송된 봉투는 이렇게 드러납니다.1001과1002: 형식이 잘못되었거나 검증되지 않는 서명.
문서는 "switch on error.code, not on the status"(상태가 아니라 error.code로 분기하라)고 말하며, 함정 하나를 짚습니다. 오케스트레이터 자체의 POST /v1/seal/invoke는 거부를 숫자 대신 TOOL_NOT_ALLOWED 같은 문자열 코드로 답합니다.
7단계. 감사 기록 읽기
SEAL Protocol 페이지는 각 호출이 만드는 이벤트, 즉 ToolCallAuthorized와 PolicyViolationBlocked 등을 나열하고, 각각이 담는 것을 밝힙니다. 봉투의 서명, 타임스탬프, jti, 토큰의 sub, scp, wid, exec_id, 도구 이름과 "payload digest (not the full payload, payloads are not logged by default)"(페이로드 다이제스트(전체 페이로드가 아님, 페이로드는 기본적으로 기록되지 않음)), 그리고 "the policy decision (ALLOW or DENY plus the deciding rule, if any)"(정책 결정(ALLOW 또는 DENY, 그리고 있다면 결정한 규칙))입니다. 부인 방지를 주는 것은 서명입니다. "only the holder of the ephemeral private key could have produced a valid signature."(임시 개인 키를 가진 쪽만이 유효한 서명을 만들 수 있었습니다.)
독립 실행형 SEAL Gateway에서는 그 행들이 gateway_events 테이블에 있습니다. 아직 이를 위한 REST 엔드포인트는 없고, 문서는 대신 SQL을 줍니다.
SELECT event_type, created_at, payload
FROM gateway_events
WHERE payload->>'execution_id' = 'exec-1234' -- Postgres JSONB syntax
ORDER BY created_at;
테이블은 추가 전용이므로, 마지막으로 보낸 ID보다 큰 ID를 폴링해 SIEM으로 보내세요.
문서가 열어 둔 것
- 두 이벤트 목록이 다릅니다. SEAL Protocol 페이지는
PolicyViolationBlocked를 지정하지만, Observability가 나열하는 게이트웨이의gateway_events테이블에는 없습니다. 거부가 어느 테이블에 담기는지는 나와 있지 않습니다. - 포트. SEAL 페이지는 오케스트레이터를
8080에 두지만, CLI의 기본 API 포트는8088입니다. - 게이트웨이에는 아직 메트릭 엔드포인트도 OTLP 트레이스도 없습니다. Observability 페이지 스스로 그렇게 말합니다.
다음
이 로그 옆에 검토자에게 무엇이 필요한지는 운영 중인 AI 에이전트를 위한 추적성 체크리스트를 읽으세요.