기계 번역입니다. 영어 원문이 기준입니다. English

적대적 감사

한 번의 감사가 아닙니다. 하나의 규율입니다.

누구나 보안 점검을 한 번 돌리고 초록색 결과를 스크린샷으로 남길 수 있습니다. 더 어려운 건 시스템이 커지는 동안 자기 시스템을 계속 다시 공격하고, 매번 같은 답을 얻는 것입니다. 최근 라운드: 50-에이전트 감사를 하고 그 수정 사항을 배포한 뒤, 별도의 14-렌즈 적대적 재감사를 진행했습니다. 모든 발견 사항은 회의론자의 검증을 통과해야만 인정됐습니다. 유지되는 것은 유지됩니다.

최신 감사가 다룬 범위

범위, 방법, 한계가 먼저. 에이전트 수는 그다음.

2026년 9월 25일자 최신 코어 감사에서 발췌했습니다. 에이전트 수는 감사가 얼마나 바빴는지를 말해 줄 뿐 얼마나 좋았는지는 말해 주지 않습니다. 그래서 이번 감사가 실제로 한 일을 여기에 적습니다.

코드
고정된 커밋 하나 기준의 코어 패키지(파일 162개, 17,362줄)와, 각 경로가 실제로 동작 중인지 판단하는 데 필요한 게이트웨이 코드.
접근
전체 소스와, 마이그레이션으로 새로 구축한 데이터베이스. 프로덕션 데이터베이스는 아닙니다. 프로덕션 전용 설정은 미검증으로 표시했고, 이후 제가 직접 확인했습니다.
방법
리뷰어 4명이 각자 한 계층씩 전부 읽었습니다. 리드는 모든 발견 사항을 해당 파일과 대조해 다시 읽고, 타이밍이나 패턴에 관한 주장은 모두 직접 실행해 본 뒤에야 인정했습니다.
심각도
HIGH는 실제 운영 경로에서 위기 신호를 놓치거나 서비스 거부가 발생하는 경우, 테넌트 간 유출, 또는 금전 손실을 뜻합니다. Medium은 실패 시 열려 버리는 가드, 근거 없이 생성되는 크레딧, 또는 조용히 누락되는 데이터를 뜻합니다. 모든 발견 사항은 live 또는 latent로도 표시됩니다: 지금 프로덕션에서 도달 가능한지 여부입니다.
이견
리드가 재현하지 못한 발견 사항은 평균에 섞지 않고 제외하거나 미검증으로 표시했습니다.
결과
HIGH 2건, medium 13건. 모두 당일에 수정했고, 각각 이전 코드에서 실패하던 테스트가 있으며, 전체 테스트 스위트를 CI에서 다시 실행했습니다.
다루지 않은 범위
약 7,000줄에 이르는 번역된 안전 문자열의 정확도, 프로덕션 데이터베이스, 웹 서버 설정, 그리고 아직 미해결인 low 등급 발견 사항 17건.

제가 지휘한 AI 리뷰어가 자체 수행한 것이며, 독립적인 제3자 보증이 아닙니다.

주기

라운드마다 거듭 다시 공격했습니다. 아래의 모든 테넌트 간 발견 사항은 고객 신고가 아니라 감사에서 발견되었고, 수정되었습니다.

최신
14-렌즈 재감사: 직전 수정 작업을 대상으로, 수정마다 잔여 우회 및 회귀 탐색, 각 발견 사항은 독립 에이전트의 반박 검증을 거침. 저위험 엣지 케이스 2건이 남았고 둘 다 수정됨. 테넌트 간 문제 없음, 금전 또는 거버넌스 결함 없음.
그 이전
50-에이전트 감사 → 스토어 경계 전반(캘린더, 채널, 자율 레지던트, 테넌트 경제, GDPR/PECR)에 걸친 최소한의 9-PR 수정: 모두 출시, 테스트, 재배포 완료.
그 이전
44-에이전트 감사, 발견 9건, 그중 high 3건(테넌트 간 대화 유출 포함): 모두 수정됨. 그리고 30-에이전트 확장 분석에서는 그라운딩의 부수 효과로 실제 버그들이 드러났습니다.
2026년 7월
80개 에이전트, 14개 관점 감사: 가장 초기의 전체 점검으로, 반박 규칙을 적용해 실행했습니다: 별도의 에이전트가 반박에 실패하기 전까지는 어떤 발견 사항도 인정되지 않았습니다. 이를 통해 세 가지 수정이 배포되었으며, 여기에는 이차 시간 복잡도의 웹사이트 임포터를 제한된 선형 스캔으로 재작성한 것이 포함됩니다. 위의 50개 에이전트 점검과는 별개이며, 그보다 앞서 진행되었습니다.
및 이전
플랫폼 전체와 Studio 전체에 대한 적대적 점검, 대표 점검, 그리고 그 이전의 여러 점검: git에 이어지는 기록으로 남아 있습니다.

✓ 모든 라운드에서 핵심 자산 유지, 격리 · 금전 · 거버넌스 · SSRF · 토큰 도메인

실제 사례 중 세 가지

HIGH 테넌트 간 대화 유출

채팅 메모리가 테넌트가 아니라 발신자를 키로 저장되어 있었기 때문에, 플랫폼을 통해 두 사업체에 메시지를 보낸 게스트의 경우 한 사업체와의 대화가 다른 사업체의 프롬프트 안에 나타날 수 있었습니다. 수정됨: 기록은 스토리지 계층에서 사업체를 키로 저장되며, 이전 키가 다시 나타나면 실패하는 테스트가 있습니다. 고객이 신고한 것이 아니라 감사에서 발견되었습니다.

HIGH 호출자를 고갈시키는 프로바이더

테넌트 간 도구 경제에서, 호출자가 허가된 도구를 쓰기 시작한 후에 제공자가 그 가격을 올려 호출자의 잔액을 소진시킬 수 있었습니다. 수정: 호출자가 호출당 가격에 동의하며, fail-closed 방식이라 동의가 없으면 과금도 없고, 이는 크레딧이 하나라도 이동하기 전에 강제됩니다.

HIGH 계측 뒤에 놓인 위기 대응

과금 확인이 위기 확인보다 먼저 실행되어, 크레딧이 소진된 비즈니스에 메시지를 보낸 곤경에 처한 고객이 위기 상담 번호 대신 "이용 불가"를 받았습니다. 수정됨: 위기 대응은 모든 한도와 과금보다 앞서, 모든 고객 접점에서 무료로 제공됩니다.

검토 관점은 격리 · 인증 · 인젝션 · 금전 · 거버넌스 · 예약 · 채널 · 자율 레지던트 · 데이터 권리(GDPR/PECR) · 사이트 생성기 · 프런트엔드 · 운영에 걸쳐 있습니다. 매 라운드의 결론: 미해결 critical 0건, 테넌트 격리와 XSS 표면은 이상 없음, 실제로 작동하는 인증 우회 없음: 확인된 모든 엣지 케이스는 수정 후 재배포했습니다.

정직한 수치

모든 수치에 단서가 이미 붙어 있습니다.

대부분의 개발자는 부풀립니다. 저는 실제가 아닌 부분으로 감탄을 사기보다, 실제인 부분을 신뢰받는 편을 택하겠습니다.

1빌더* 팀이 아님
3,389테스트 통과* CI, 2026-10-01, 형식적 증명은 아님
6 → 0감사 · 미해결 치명적 결함* 제3자가 아닌 자체 수행, 2026-09-25 기준 critical 0건, 코어 패키지
0프로덕션에서 알려진 테넌트 간 침해* 신고된 건 없음. 감사에서 유출 한 건이 발견되어 수정됨, 아래 참조
1프로덕션 인스턴스* 의도적 선택, 규모는 아직 핵심 교훈이 아님

이 시스템이 정직한 이유는 설계한 사람이 정직하기 때문입니다. 처음부터 그렇게 되도록 했습니다. 나중에 덧붙인 것이 아니라 설계에 내장했습니다.

초대

수치는 유효합니다. 단서도 함께 붙어 있습니다.

누가 요청하기 전에 자기 작업을 이만큼 공격하고, 시스템이 커져도 계속 그렇게 하는 개발자를 원하신다면, 이야기 나눠요.