제가 작성한 ATC(Agent Trust Card)와 8계층 보안 파이프라인에 대한 지난 게시물은 실제 대화를 불러일으켰습니다. 몇몇 댓글 작성자들은 간단한 답변 이상의 논점을 제기했기에, 여기에서 제대로 된 답변을 드립니다.

1. 캐노니컬라이제이션 버그 ([@anp2network])

캐노니컬라이제이션 라인에 커버리지 버그가 있습니다: JSON.stringify(payload, Object.keys(payload).sort())

맞습니다. JSON.stringify(obj, replacer)는 최상위 키만 정렬합니다. 중첩된 객체(예: payload.trust, payload.identity, payload.payment)는 원래의 키 순서를 유지합니다. 서명자(signer)와 검증자(verifier)가 중첩된 객체를 다르게 직렬화하면, 서명이 검증되지 않습니다.

수정 방법:

function canonicalJson(obj) {
  if (obj === null || typeof obj !== 'object') return obj;
  if (Array.isArray(obj)) return obj.map(canonicalJson);
...

이 코드는 모든 깊이에서 키를 재귀적으로 정렬합니다. 다음 배포에 이 수정 사항을 반영할 예정입니다. 발견해 주셔서 감사합니다. 바로 이런 종류의 검토가 신뢰 시스템을 신뢰할 수 있게 만듭니다.

2. CA 키 로테이션 ([@jkming])

CA 키 자체가 손상된다면 어떻게 되는지 고려해 보셨나요? 고가치 에이전트를 위한 키 로테이션 및 멀티시그에 대한 후속 내용을 보고 싶습니다.

훌륭한 질문입니다. 계획은 다음과 같습니다:

현재 상태: 단일 Ed25519 CA 키. 비공개 키는 Vercel 환경 변수에 저장되어 있습니다. 만약 이 키가 손상되면, 키를 로테이션할 때까지 모든 ATC는 신뢰할 수 없게 됩니다.

로테이션 계획 (현재 구현 중):

1. 키 버전 관리(Key versioning): 각 ATC는 ca_key_id (예: ca-key-001)를 포함합니다. 검증자(Verifiers)는 어떤 키가 서명했는지 확인합니다.
2. 로테이션 흐름(Rotation flow):
   • 새 CA 키 쌍(ca-key-002)을 생성합니다.
   • 모든 활성 ATC를 새 키로 재서명합니다.
   • 이전 키를 CA 키 레지스트리에서 폐기됨(revoked)으로 게시합니다.
   • 검증자는 폐기된 CA 키로 서명된 모든 ATC를 거부합니다.
3. 고가치 에이전트를 위한 다중 서명(Multi-sig for high-value agents): 하나의 ATC는 2개 이상의 CA로부터의 서명을 요구할 수 있습니다 (예: MarketNow Sentinel CA + 독립적인 제3자 CA). 이는 확장 검증 SSL 인증서와 동일한 패턴입니다.

일정(Timeline): 키 버전 관리는 다음 2주에 구현될 예정입니다. 다중 서명은 로드맵에 있지만, 먼저 두 번째 CA 파트너가 필요합니다.

3. 런타임 신뢰 격차 (Runtime trust gap) (@wrencalloway)

레이어 1부터 8까지는 모든 아티팩트를 임포트 시점에 검사하지만, MCP 스킬은 사용자가 제어하지 않는 서버와 통신하는 라이브 코드입니다. 가장 어려운 것은 깨끗하게 배포된 후 런타임에 페이로드를 가져오는 스킬입니다.

이것이 제기된 가장 중요한 지점입니다. 귀하가 설명하는 것은

• L3 — 지속적인 런타임 모니터링: 스킬이 설치된 후, 에이전트 런타임은 주기적으로 해당 스킬을 샌드박스에서 재실행하고 동작을 비교합니다. 만약 설치 당시에는 깨끗했던 스킬이 다른 네트워크 호출을 시작한다면, 이는 플래그(flag)로 간주됩니다.

• 도구 카탈로그 차분 분석 (Tool catalog diffing): 설치 후, 스킬이 선언한 도구 목록을 기록합니다. 만약 도구 목록이 변경되면(새로운 도구가 나타나거나, 기존 도구가 inputSchema를 변경하는 경우), 사용자에게 경고합니다. 이는 @mads_hansen이 설명한 내용(

• 레포지토리 소유자 검증 (Repo owner verification): github.com/X/some-mcp에서 가져올 때, X가 정식(canonical) 소유자인지 확인해야 합니다 (npm 레지스트리, awesome-mcp-servers 유지 관리자 목록과 교차 참조).

• 불변 릴리스 다이제스트 (Immutable release digests): 변경 가능한(mutable) main 브랜치에서 가져오는 대신, 특정 git 커밋 SHA에서 가져와야 합니다. 이 SHA는 스킬의 source.commit_sha 필드에 기록됩니다. 레포지토리가 임포트된 후 변경되더라도, 우리는 그 변화(drift)를 감지할 수 있습니다.

• README 링크 신뢰성 (README link trust): 리포지토리 자체 릴리스 페이지 외부로 다운로드되는 README의 모든 링크는 기본적으로 신뢰하지 않습니다.

5. 더 큰 그림 (The bigger picture)

커뮤니티로부터 듣고 있는 내용은 다음과 같습니다:

1. 패키지 안전성 ≠ 런타임 안전성. 우리는 둘 다 필요합니다. L1.5-L1.8은 패키지 안전성을 처리합니다. L2는 격리된 환경에서의 런타임 동작을 처리합니다. L3 (출시 예정)는 지속적인 런타임 모니터링을 처리합니다.
2. 신뢰는 이분법적이지 않다. CrewAI 이슈에서 @0xbrainkid가 잘 말해주었습니다:

— Edison Flores, AliceLabs LLC