Give the agent an investigation mandate, not approval authority
An unknown sender is an observation that has not yet been tied to an approved business service. It is not automatically malicious, and a recognizable hosting company does not make it authorized. An agent can organize evidence and suggest next questions, but a customer-specific human decision must determine whether the service is approved, rejected or escalated.
The workflow below is proposed and unexecuted. It draws on the May 2026 DMARC specifications, OWASP's 2025 agent-security guidance and public provider documentation reviewed on 8 November 2026. No EmailAuth feature, integration, autonomous action or supported product workflow is asserted. Product capability and permission enforcement must be verified separately before implementation.
Start with a narrowly scoped observation
Create a case from the approved input: a report row, alert or relevant message observation. Preserve the report source, reporting interval, author domain, connecting IP, authentication identities and observed results where available. Keep original values separate from the agent's normalized display and label missing fields. A parser error should not be rewritten as a sender finding.
RFC 9990 describes aggregate report records with connecting IP, counts and authentication-related data. Such rows are useful clues but do not name the organization's business owner. Reports can also contain false information; retain provenance and seek corroboration rather than trusting apparent volume as authorization. RFC 9990
Set the agent's allowed scope before enrichment. In this proposed design it may read approved report extracts, relevant inventory entries, public documentation and specifically authorized configuration observations. It cannot query unrelated customer accounts, send messages, modify DNS, create or reveal credentials, approve a service, or share evidence with an external recipient.
Keep retrieved material from becoming instructions
Reports, message content, websites and provider documents are evidence inputs, not sources of authority for the agent. Text embedded in a sample that tells it to export data or “repair” a record must not change its task. OWASP describes indirect prompt injection through external content and explains why retrieval alone does not remove that risk. OWASP prompt injection
Use narrowly defined read tools and enforced permissions rather than relying only on an instruction saying “do not write.” OWASP's excessive-agency guidance supports limiting functionality, privilege and autonomy, with approval controls on consequential actions. Evaluate the actual system's enforcement and audit trail before using it with customer data. OWASP excessive agency
The agent's output should preserve which statements came from an observation, a documented provider fact or an inference. A confidence label is not a probability unless it was actually calibrated; simpler terms such as confirmed, candidate and unresolved can be clearer when their required evidence is defined.
Generate candidates without confusing identity and ownership
The agent may compare the observed identities with known services and publicly documented provider behavior. A reverse-DNS name, shared IP range or familiar DKIM domain can suggest a candidate. None proves that the relevant customer tenant, campaign or business application is authorized to use the organization's domain.
Ask the business owner for evidence connecting the specific service to the observed identity and purpose. Useful proposed inputs include an approved service record, an authorized account configuration view and a relevant message event. Do not ask for a password or private signing key to establish ownership.
Amazon SES provides a concrete scope example: its public documentation describes domain or email identities and Region-specific verification, including inherited behavior. If SES is a candidate, inspect the relevant authorized account and Region rather than assuming a generic SES match settles the case. This article neither verifies an SES tenant nor creates an identity. Amazon SES identity documentation
Correlate authentication without overclaiming
Where an approved message sample is necessary, use the receiving system's trusted authentication evidence and relevant sending logs. Merely finding an Authentication-Results header is insufficient: the trust relationship with the producing system matters. Keep untrusted forwarded or pasted assertions distinguishable from the receiver evidence being relied upon. RFC 8601
Evaluate the author domain, authenticated SPF or DKIM identity and alignment as separate fields. A pass can support a statement about domain authentication; it does not supply business approval for the application. Conversely, an authentication failure can arise on a legitimate path and is not, by itself, proof of abuse. RFC 9989
Minimize content exposure while correlating evidence. The agent should work from the approved technical subset where possible. If a restricted original or external disclosure becomes necessary, pause for a specific human decision about the data and destination. Read-only analysis does not eliminate disclosure risk when it sends inputs to another service.
Present a decision packet with unresolved alternatives
The proposed packet should name the candidate service, relevant identities, supporting artifacts, contradictions, missing owner evidence and recommended next step. Offer explicit outcomes: approve the documented service scope, keep investigating, or escalate a suspected unauthorized use. A human decision should identify who decided, on what evidence and with which limitations.
For a fictional case, a report row resembles a known campaign platform, but no current owner can connect it to a customer account. The appropriate proposed transition is from unknown to unresolved with an assigned investigator. A later owner-confirmed account and message match could support human approval; this narrative is not evidence that such a transition occurred.
Approval of the service does not automatically approve an SPF addition, DKIM change or DMARC-policy adjustment. Any recommended change needs its own exact target, current baseline, intended diff and authorized human decision. A changed target or stale baseline returns the proposal for review rather than broadening the earlier approval.
Evaluate the workflow with retained human decisions
Before operational use, define tests for ambiguous attribution, contradictory evidence, malicious embedded instructions and denied actions. The expected safe behavior should include leaving a case unresolved and stopping at the permission boundary. No such tests have been executed here, and no success rate or prevention guarantee is claimed.
Required original evidence: Demonstrate an unknown-to-approved or escalated workflow with retained evidence and human decisions. The proposed states, fictional case and security controls do not satisfy that gate. Actual evidence, human decisions and product-specific verification remain absent.