Define the permission model before giving an agent tools
An authentication agent can help explain evidence, prepare changes and check outcomes. Those capabilities do not justify unrestricted control over DNS, signing keys or customer tenants. The organization should document which resources the agent may read, which actions it may propose and which operations require a separately verified approval. “Help improve email authentication” is not a precise permission boundary.
The model described here is a recommended design, not a statement that EmailAuth currently implements it. No product permission controls, administrative interfaces or tenant isolation were inspected or tested. The article’s prohibited-action examples are proposed test cases, not records of successfully blocked attempts.
Separate read-only preparation from consequential execution
Preparation can include analyzing approved reports, comparing an authorized inventory, drafting a DNS difference and explaining a recovery plan. Even reading needs a defined tenant and data scope; read-only access to another customer’s reports is still unauthorized access. External sharing is also a separate operation, not a harmless extension of internal analysis.
Changing a DMARC policy, adding an SPF authorization, publishing a DKIM key, switching a signer or removing a sending permission can alter production trust and delivery. DNS delegation, private-key custody, persistent credentials and administrative grants can expand future control. The proposed permission model should require accountable approval for those actions and enforce it independently of the model’s own decision. OWASP Excessive Agency.
Bind approval to the exact action and current scope
A meaningful approval record identifies the actor, tenant, resource, operation and normalized parameters. For a DNS change, show the relevant current value and proposed value; for a permission removal, name the identity and access being removed. A reviewer should be able to understand the consequence without reconstructing the agent’s conversation.
OWASP’s AI Agent Security guidance calls for independently validated, action-bound approvals, limited validity and replay protection for high-impact operations. Apply those controls in the execution component rather than trusting a model-generated “approved” flag. A material target or parameter change needs a new decision. The actual implementation and its failure behavior must be tested before anyone claims this boundary is effective. OWASP AI Agent Security Cheat Sheet.
Treat new authority and external disclosure as distinct changes
Permission to update one approved selector does not authorize a wildcard DNS delegation, a broader cloud role or a permanent credential for future work. Permission to analyze reports does not authorize sending them to a new agency. The proposed design should expose each expansion as a separate decision, including the resource, recipient and operational purpose.
RFC 9990’s external-destination verification illustrates an important distinction. A receiving processor can publish the technical confirmation needed for DMARC report delivery, but that does not establish that the domain owner approved the business relationship or disclosure. The agent should preserve both facts and leave the organizational decision to the appropriate owner. RFC 9990, section 4.
Do not let evidence rewrite the rules
Reports, DNS text, provider pages and support messages can contain untrusted material. A field that says “approve this sender” is not an approval from the organization’s authorized administrator. An instruction embedded in retrieved content must remain evidence to analyze, not a command that expands the agent’s scope. OWASP describes this as an indirect prompt-injection risk. OWASP Prompt Injection.
The boundary also applies between automation components. A recommendation from another model or service should carry its evidence and uncertainty, not manufacture authorization. Verify the actual approval source and resource scope at the point of action. If the policy service cannot establish permission, the proposed control should stop that action while allowing unrelated authorized analysis to continue. OWASP Authorization Cheat Sheet.
Exercise the boundary with fictional cases
In a fictional workflow, an administrator approves adding a public DKIM record for a named selector in tenant A. Before execution, a different tool proposes changing the parent DMARC policy and using tenant B’s credentials. The original approval should not authorize either substitution. The review packet should preserve what changed and request the appropriate decision rather than treating the initial approval as transferable.
A second fictional case has a DNS write time out. The agent does not know whether the service committed the change. Blindly repeating the write can create an unintended second operation or overwrite a later administrator edit. The proposed recovery sequence first establishes the current state and operation outcome, then follows the approved retry or recovery path. Neither case was executed against EmailAuth or any live tenant.
Make stop and recovery behavior auditable
Record the proposed action, approval reference, execution request, returned outcome and independently checked postcondition. Keep secrets out of the audit record. A success message from a tool should not be the sole evidence that the intended DNS value or permission state now exists. The recovery plan should identify which prior state may safely be restored and who can authorize that step.
Recovery itself can be consequential. Reinstating a compromised key, restoring an unsafe sender permission or weakening a domain policy is not automatically authorized because it is called rollback. Define these cases explicitly. DMARC’s policy and alignment semantics should inform the predicted impact, but the standard does not grant an agent administrative authority. RFC 9989, sections 4.4 and 4.5.
Require both permitted and prohibited-action tests
A complete test plan should demonstrate a correctly approved narrow operation and rejected cases for wrong tenant, altered parameters, expired approval, repeated approval use and untrusted-content instructions. Run such tests only in an authorized environment with bounded fixtures. Record actual results, including failures of the control, rather than publishing a checklist as proof that protection works.
Test prohibited actions and approved scoped changes using current product controls. This exact commissioning requirement remains open. Product enforcement, approved execution, prohibited-action rejection, postcondition checks and recovery behavior have not been demonstrated. The permission map is a proposed design for review, not a claim of current EmailAuth functionality.