An agent can produce a sound authentication recommendation and still execute an unsafe change. The failure may be a wrong tenant, a record that changed after review, or a successful API response followed by failed mail authentication. Design approval gates around those transitions rather than a general instruction to be careful.
Build a reviewable proposal
Identify the customer, tenant, zone, fully qualified owner name, record type, complete before and after values, and purpose. Explain affected sending services and the evidence supporting the change. A proposed DKIM selector publication should name the service that will sign with it; a proposed SPF change should explain the resulting authorization. A digest can bind these bytes, but it cannot establish the approver's identity or authority.
OWASP's excessive-agency guidance recommends restricting functionality, permissions and autonomy. Apply that principle by keeping recommendation and execution interfaces separate. The fields and decision examples here are original implementation recommendations, not an OWASP-defined approval protocol.
Revalidate immediately before execution
Check the authenticated actor's authority for the target tenant, the approval expiry, the proposal digest and the current baseline. Any mismatch returns the request to review. The same visible domain name in a different customer account must not inherit an approval. Use the provider's conditional-update facility where available; otherwise recognize that a read followed by a write leaves a race window and design locking or reconciliation accordingly.
Suppose a proposal is approved for a selector publication in tenant A. At execution time, the request targets tenant B with the same domain label. Stop on the target mismatch; a matching payload digest cannot extend the approver’s scope. This is a hypothetical refusal condition, not a tested identity system or provider gate.
Separate permission from completion
Approval permits only the specified action. The execution log records attempted work, provider result, resulting configuration and postcondition evidence separately. A timeout creates an uncertain outcome, not permission to repeat a potentially completed mutation. Read the target state before deciding whether a retry is necessary.
Suppose a provider reports success but an authorized postcheck finds the wrong effective value. Record verification failed, not completed. This assumed case illustrates a status distinction; no write or postcheck was performed here. Real verification should compare authoritative DNS with the approved record and exercise the intended sending route. DMARC requires an authenticated aligned identifier; a DNS record's presence is not proof of that outcome. See RFC 9989 on identifier alignment.
Provide a stop and recovery path
Define who can halt the workflow and who approves recovery. Rollback is a separate consequential change unless its exact scope was already approved. Preserve the failed result, notify the owner and avoid weakening a domain-wide policy as a generic repair. Keep approvals and evidence in access-controlled history with an appropriate retention period. This design is vendor-neutral and does not assert that EmailAuth implements these gates.
Primary reading: OWASP LLM06 2025 Excessive Agency, RFC 9989 DMARC.