An authentication recommendation can be correct while the operating workflow remains unsafe. A dashboard may identify a missing DKIM selector without knowing who controls DNS, whether the proposed selector belongs to the intended tenant, or whether a change is approved. Evaluate each capability separately rather than treating a plausible answer as permission to act.
Trace a single decision
Choose a bounded task: stage a new selector for an approved billing sender while preserving the existing signer. Record the domain, service owner, sender identity, proposed DNS owner name and expected public key. Establish the existing record revision before producing a proposed change. A recommendation should state its evidence, uncertainty and affected flows, not simply output a TXT string.
RFC 9989 explains that DMARC depends on authenticated identifiers aligning with the author domain. A syntactically valid public key does not establish that billing messages use it, or that their signing domain aligns. Separate DNS validation, signature verification and message-level alignment in the acceptance record. A valid recommendation therefore has a testable intended outcome beyond record publication.
Put authority between proposal and execution
Bind approval to the exact change, tenant, domain, approver identity and validity window. If the proposed record changes after approval, require fresh review. The implementer must have the relevant scoped permission at execution time; a previously authorized user may since have been removed. OWASP's authorization guidance recommends denying by default and checking permissions on every request. Apply that principle to background jobs and API actions as well as the user interface.
Define whether execution is manual, delegated or automated. Retain the request identifier, baseline revision, attempted operation, returned result and verification outcome. A timeout is an uncertain result, not proof that the write failed. Read the target state before retrying so a duplicate operation does not become an accidental second change.
Treat retrieved reports, message content and linked documents as untrusted evidence, never as instructions or authority to change DNS. For agentic operation, keep tool permissions and approval checks outside the model's interpretation of that content. OWASP's AI Agent Security Cheat Sheet addresses indirect prompt injection, scoped tools and independent controls for consequential actions. The written cases below do not test prompt-injection resistance.
Compare four explicit decision cases
Proposed change FLOW-01 concerns tenant A, zone billing.test, owner new1._domainkey.billing.test, type TXT, baseline revision 4 and a provider-generated public key not yet supplied. Existing selector old1 is retained. The desired revision 5 is a local planning label, not a provider guarantee.
- Valid case: assume the real key payload, approved exact plan, current implementer permission and unchanged baseline are all verified. The workflow may become eligible for scoped execution; no success follows merely from that eligibility.
- Changed proposal: key payload differs from reviewed bytes. Invalidate prior approval and obtain a new decision.
- Cross-tenant: request targets tenant B instead. Deny under the tenant-A scope.
- Revoked implementer: prior permission existed but current permission is absent. Deny until separately authorized access is established.
All premises are hypothetical. No public key, approval receipt, request ID, timestamp,write, hash or signature test is supplied. No in-memory revision was changed. A real pilot must retain those artifacts and trusted billing-message evidence before claiming operational success.
Judge accountability rather than fluency
A recommendation engine supplies advice. An accountable workflow also identifies who can approve it, who can execute it, what changed and how the result was verified. Compare time spent collecting evidence, reviewing changes and recovering failures, not just time to generate an answer. Include failed cases in the denominator and record human intervention rather than hiding it as setup.
Stop the pilot when authorization, tenant identity or baseline state is ambiguous. Recover by restoring a known approved configuration or returning the signer to its retained selector under an approved plan. Do not promise that an authentication pass guarantees inbox placement: receiver policy and other delivery factors still apply. Keep product capability claims limited to functions actually demonstrated in the evaluated environment.