메인 콘텐츠로 건너뛰기
컴플라이언스 보고서는 감사인이 당신이 생성한 이후 편집되지 않았음을 신뢰할 수 있을 때만 유용합니다. OrcaRouter가 생성하는 모든 보고서는 어떤 계정 접근 없이도 그 검사를 가능하게 하는 두 가지를 담고 있습니다: 정규 증거의 SHA-256 콘텐츠 해시와 그 해시에 대한 Ed25519 서명. 이 페이지는 컴플라이언스 보고서를 검증하는 방법을 보여줍니다 — 공개 키를 가져오고, 해시를 확인하고, 서명을 확인 — 공개 엔드포인트만 사용하여. 유스케이스는 구체적입니다: 감사인에게 서명된 보고서(또는 공유 포털 링크)를 건네면, 그들은 의존하기 전에 그것이 진본이고 변조되지 않았음을 증명해야 합니다. 그들은 당신의 워크스페이스, 키, 또는 콘솔을 결코 건드리지 않습니다.

​
1. 보고서와 함께 이동하는 것

세 가지 값이 보고서를 자기 검증 가능하게 만듭니다. 그것들은 보고서 아티팩트와 링크에 대한 공개 공유 포털 메타데이터에 나타납니다.
보고서의 정규 증거 JSON의 소문자 hex SHA-256 다이제스트. 바이트는 주어진 보고서에 대해 결정론적이므로, 동일한 증거를 가진 누구나 동일한 해시를 재계산합니다. 증거에 대한 모든 편집은 이 값을 바꿉니다.
hex content_hash에 대해 계산된 base64 Ed25519 서명. 그것은 해시가 OrcaRouter의 서명 키에 의해 서명되었고 위조되지 않았음을 증명합니다.
활성 공개 키에 대한 짧고 안정적인 식별자(예: orca- 다음에 hex 조각). 검증자는 그것을 사용하여 보고서가 현재 게시된 키에 의해 서명되었음을 확인합니다 — 알 수 없는 키 id로 서명된 보고서는 페일 클로즈됩니다.
서명은 렌더링된 PDF, CSV, 또는 JSON 바이트가 아니라 콘텐츠 해시를 직접 커버합니다. 동일한 증거가 하나의 해시에서 세 가지 형식 모두로 렌더링되므로, 무결성 보장은 기저 증거에 있습니다 — 주어진 보고서의 모든 내보내기는 하나의 content_hash, signature, sig_key_id를 공유합니다.

​
2. 공개 키 가져오기

서명 공개 키는 열린 엔드포인트에 게시됩니다 — 인증 없음, 워크스페이스 컨텍스트 없음. 감사인이 직접 호출합니다. 
curl https://api.orcarouter.ai/api/public/compliance/pubkey

{
  "success": true,
  "message": "",
  "data": {
    "algo": "ed25519",
    "key_id": "orca-1a2b3c4d5e6f",
    "public_key": "base64-encoded-ed25519-public-key"
  }
}
public_key는 base64 인코딩된 32바이트 Ed25519 공개 키입니다. 여기의 key_id는 보고서의 sig_key_id와 일치해야 합니다 — 일치하지 않으면, 보고서는 다른(아마도 순환되었거나 더 오래된) 키로 서명된 것이며 이 게시된 키에 대해 검증되지 않습니다.

​
3. 서명 검증

서명을 두 가지 방법으로 검증할 수 있습니다. OrcaRouter에게 튜플을 대신 확인하도록 요청하거나, 게시된 공개 키로 완전히 오프라인으로 검증하세요.

​
호스팅된 verify 엔드포인트

보고서의 세 값을 열린 verify 엔드포인트에 POST하세요. 그것은 공개입니다 — 감사인이 자격 증명 없이 호출합니다. 
curl -X POST https://api.orcarouter.ai/api/public/compliance/verify \
  -H "Content-Type: application/json" \
  -d '{
    "content_hash": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
    "signature": "base64-ed25519-signature-from-the-report",
    "sig_key_id": "orca-1a2b3c4d5e6f"
  }'

{
  "success": true,
  "message": "",
  "data": {
    "valid": true,
    "key_id": "orca-1a2b3c4d5e6f"
  }
}
valid: true는 그 키 id에 대한 활성 키에 대해 서명이 확인됨을 의미합니다. valid: false는 서명이 해시와 일치하지 않거나, 해시가 비어 있거나, sig_key_id가 현재 게시된 키와 일치하지 않음을 의미합니다.
verify 엔드포인트는 활성 key_id를 에코백합니다. 당신이 제출한 sig_key_id와 비교하세요: 다르다면, 보고서는 더 이상 활성이 아닌 키로 서명된 것이며, 그것이 검증에 실패한 이유입니다.

​
공개 키로 오프라인 검증

회의적인 감사인은 verify 엔드포인트를 전혀 신뢰할 필요가 없습니다. 알고리즘이 hex 콘텐츠 해시에 대한 표준 Ed25519이기 때문에, 서명은 어떤 암호 라이브러리로든 확인 가능합니다: 
import base64
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

# public_key from GET /api/public/compliance/pubkey
pub = Ed25519PublicKey.from_public_bytes(base64.b64decode(PUBLIC_KEY_B64))

# content_hash + signature from the report
message = CONTENT_HASH.encode()            # the hex hash string, as bytes
signature = base64.b64decode(SIGNATURE_B64)

pub.verify(signature, message)             # raises if invalid; returns None if valid
서명된 메시지는 해시가 디코드되는 원시 32바이트가 아니라 ASCII 바이트로 인코딩된 hex 해시 문자열 자체입니다. 서명 검증 전에 content_hash 값을 있는 그대로 통과시키세요, 그렇지 않으면 올바른 보고서에서 검사가 실패합니다.

​
4. 서명이 커버하는 것

서명은 보고서의 content_hash가 OrcaRouter에 의해 서명되었음을 증명하고, 해시는 증거가 편집되지 않았음을 증명합니다. 한 가지 미묘함: 해시는 JSON이나 PDF 파일의 원시 바이트가 아니라 게이트웨이가 구축하는 증거의 정규 형식에 대해 계산됩니다. 그래서 다운로드한 아티팩트를 직접 다시 해시해도 content_hash를 재현하지 못합니다. 정규 해시를 재계산하고 Ed25519 서명을 대신 확인하는 verify 엔드포인트(§2/§3)를 사용하세요:
검사의미
signature_valid: truecontent_hash가 OrcaRouter의 키로 서명됨 — 증거가 진본이고 편집되지 않음.
키 id 일치보고서 sig_key_id == 게시된 키 id → 활성 키로 서명됨.
둘 다 통과하면 보고서가 진본이고 변조되지 않았음을 의미합니다. 실패한 서명은 해시, 증거, 또는 키 id가 OrcaRouter의 서명 키에 속하지 않음을 의미합니다.

​
5. 공유된 보고서 검증

감사인에게 파일 대신 공유 포털 링크를 보낼 때, 포털 메타데이터는 이미 content_hash, signature, sig_key_id, 그리고 서버가 계산한 signature_valid 플래그를 담고 있습니다. 감사인은 그 플래그를 신뢰하고 동시에 위의 검사를 공개 키에 대해 독립적으로 다시 실행할 수 있습니다 — 공유 포털은 로그인이 필요 없고, 검증 경로는 동일합니다.
공유된 아티팩트는 그 스탬프된 리전이 여전히 워크스페이스의 선언된 데이터 레지던시 리전과 일치하는 동안에만 제공됩니다. 리전이 변경되었으면, 서명 메타데이터가 검증 가능하게 유지되더라도 다운로드가 보류됩니다. 이는 설계에 의한 것입니다 — 크로스 리전 읽기를 참조하세요.

​
6. 다음으로 갈 곳

서명된 보고서

서명된 보고서가 어떻게 생성되는지, 어떤 증거를 캡처하는지, 그리고 감사인 공유 링크를 발행하는 방법.

증거 내보내기

감사인의 작업 서류를 위해 보고서 증거를 PDF, CSV, 또는 JSON으로 가져오세요.

데이터 레지던시

보고서의 리전 스탬프가 그것이 저장되고 제공되는 곳을 어떻게 관장하는지.

책임 범위

OrcaRouter가 게이트웨이 경로에서 보장하는 것과 당신의 몫으로 남는 것.
서명 키는 OrcaRouter의 것입니다; 검증은 누구나의 것입니다. 그 분리가 전체 요점입니다 — 감사인은 보고서를 생성한 워크스페이스에 접근할 필요 없이 보고서가 진본임을 증명합니다.