에이전트는 건전한 인증 권장 사항을 생성하고 여전히 안전하지 않은 변경을 실행할 수 있습니다. 실패는 잘못된 임차인일 수도 있고, 기록 검토 후 변경되었거나 API 응답이 성공한 후 메일 인증이 실패했습니다. 주의해야 할 일반적인 지침보다는 이러한 전환 주위에 승인 게이트를 설계하십시오.
검토 가능한 제안서 작성
고객, 테넌트, 구역, 정규화된 소유자 이름, 레코드 유형, 전체 전후 값 및 목적을 식별합니다. 영향을 받는 전송 서비스와 변경 사항을 뒷받침하는 증거를 설명하십시오. 제안된 DKIM 선택기 발행물은 서명할 서비스의 이름을 지정해야 합니다. 제안된 SPF 변경 사항은 결과적인 승인을 설명해야 합니다. 다이제스트는 이러한 바이트를 바인딩할 수 있지만 승인자의 신원이나 권한을 설정할 수는 없습니다.
OWASP의 과도한 기관 지침에서는 기능, 권한 및 자율성을 제한할 것을 권장합니다. 추천 인터페이스와 실행 인터페이스를 별도로 유지하여 해당 원칙을 적용하세요. 여기에 있는 필드 및 결정 예는 OWASP에서 정의한 승인 프로토콜이 아닌 원래의 구현 권장 사항입니다.
실행 직전에 재검증
대상 테넌트에 대한 인증된 행위자의 권한, 승인 만료, 제안 다이제스트 및 현재 기준을 확인하세요. 불일치가 있으면 검토 요청이 반환됩니다. 다른 고객 계정에 표시되는 동일한 도메인 이름은 승인을 상속받아서는 안 됩니다. 가능한 경우 공급자의 조건부 업데이트 기능을 사용하십시오. 그렇지 않으면 읽기와 쓰기가 경쟁 기간을 벗어나고 이에 따라 잠금 또는 조정을 설계한다는 것을 인식합니다.
테넌트 A의 선택기 게시에 대한 제안이 승인되었다고 가정합니다. 실행 시 요청은 동일한 도메인 레이블을 가진 테넌트 B를 대상으로 합니다. 목표 불일치를 중지하십시오. 일치하는 페이로드 다이제스트는 승인자의 범위를 확장할 수 없습니다. 이는 테스트된 신원 시스템이나 공급자 게이트가 아닌 가상의 거부 조건입니다.
완료와 별도의 허가
승인은 지정된 작업만 허용합니다. 실행 로그에는 시도된 작업, 공급자 결과, 결과 구성 및 사후 조건 증거가 별도로 기록됩니다. 시간 초과는 잠재적으로 완료된 변형을 반복할 수 있는 권한이 아니라 불확실한 결과를 생성합니다. 재시도가 필요한지 결정하기 전에 대상 상태를 읽어보세요.
공급자가 성공을 보고했지만 승인된 사후 확인에서 잘못된 유효 값을 발견했다고 가정합니다. 기록 확인에 실패하여 완료되지 않았습니다. 이 가정된 사례는 상태 구별을 보여줍니다. 여기서는 쓰기 또는 사후 확인이 수행되지 않았습니다. 실제 검증은 권한 있는 DNS 승인된 기록과 비교하고 의도한 전송 경로를 실행해야 합니다. DMARC 인증된 정렬 식별자가 필요합니다. DNS 레코드의 존재는 해당 결과의 증거가 아닙니다. 보다 RFC 9989 ~에 식별자 정렬.
중지 및 복구 경로 제공
워크플로를 중지할 수 있는 사람과 복구를 승인할 사람을 정의합니다. 롤백은 정확한 범위가 이미 승인되지 않은 한 별도의 결과적 변경입니다. 실패한 결과를 보존하고 소유자에게 알리고 일반 복구로 도메인 전체 정책을 약화시키지 마십시오. 승인 및 증거를 적절한 보존 기간에 따라 액세스 제어 기록으로 보관하세요. 이 디자인은 공급업체 중립적이며 EmailAuth 이러한 게이트를 구현한다고 주장하지 않습니다.
기본 독서: OWASP LLM06 2025 과도한 대행사, RFC 9989 DMARC.