AI 에이전트 삭제 재검증

1. 01

   재쿼리 범위를 시스템이 보유할 수 있는 모든 것이 아닌 원본 삭제가 대상으로 한 것으로 제한하십시오

   원본 삭제 계획 또는 티켓을 가져와 명명된 모든 저장소를 나열하십시오 — 프로덕션 테이블, 삭제 시점에 범위에 있던 백업, 캐시, 인덱스 및 나열된 기타 파생 복사본. 범위를 암묵적으로 확장하는 재쿼리는 실제로 무엇이 약속되었는지에 대한 자체적인 분쟁을 초래합니다.

2. 02

   실패한 아티팩트를 생성한 것과 독립적인 접근 경로를 통해 확인을 실행하십시오

   손상된 봉인을 생성한 동일한 파이프라인은 자체 수정을 인증하는 도구가 되어서는 안 됩니다. 다른 자격증명, 다른 쿼리 경로, 또는 독립 접근 권한을 가진 두 번째 검토자를 사용하고, 어느 것을 사용했는지 기록하십시오.

3. 03

   확인된 모든 저장소를 부재, 존재 또는 도달 불가로 분류하십시오 — 절대로 조용히 "추정"으로 처리하지 마십시오

   도달할 수 없는 저장소(권한 필터링, 현재 접근 불가, 서드파티 처리자가 보유)는 나머지 확인이 통과하더라도 기록에서 도달 불가로 유지됩니다. 부재로 반올림하지 마십시오.

4. 04

   재쿼리가 존재를 확인한 것만 재삭제하고, 그 범위에 대해 다시 재쿼리하십시오

   범위 재삭제 후 자체 확인 확인을 통해 루프가 닫힙니다. 두 번째 확인을 건너뛰면 독립적으로 결과를 확인하지 않고 조치를 신뢰했던 원래 실수가 반복됩니다.

5. 05

   아카이브 및 설명하는 파이프라인과 분리된 보관 구조로 새 기록을 봉인하십시오

   새 검증 기록(무엇을, 어떤 경로로, 누가, 결과는)을 원본 삭제 파이프라인이 수정할 수 없는 곳에 저장하십시오. 그래야 해당 파이프라인의 결함이 첫 번째 것을 무효화한 것처럼 새로운 증거를 조용히 무효화할 수 없습니다.

6. 06

   새 기록에 대해 영구적으로 유효하다고 가정하지 말고 검토 트리거를 설정하십시오

   재검증 기록은 당시 확인한 시스템 및 접근 경로에 대해 유효합니다. 영원히 해결된 것으로 처리하기보다는 다시 확인이 필요한 상황(플랫폼 마이그레이션, 접근 제어 변경, 새 백업 대상)을 명시하십시오.

재계산된 매니페스트 해시를 재검증으로 처리하면 라이브 데이터가 아닌 동일한 저장된 주장을 확인하기 때문에 아무것도 해결되지 않습니다. 독립적인 확인에서 이미 부재를 보여줄 때도 모든 재검증을 새로운 삭제의 근거로 처리하면, 존재하지 않는 문제에 파괴적 조치의 승인 및 감사 추적 비용을 소비하게 됩니다.