# Agentic UX Validation — v1.9.2

Bridge milestone: **v1.9.2 — UX validation via agentic QA** (see `docs/roadmap.md`).

**Run metadata.**

- Provider / model: `anthropic` / `claude-sonnet-4-6`
- Sessions: 12 (3 personas x 2 fixtures x 2 fusion modes)
- Started: 2026-05-08T14:05:37.264356+00:00
- Finished: 2026-05-08T14:11:44.908610+00:00 (duration 367.6s)
- Tokens: 43,183 input / 15,842 output
- Realized cost: **$0.3672**

## Methodology

Three persona system prompts (security analyst, due-diligence researcher, ops engineer) are run against two fixtures: a dense recon lookup of `contoso.com` (Microsoft's fictional brand) and a hand-stripped `hardened-sparse` fixture for `northwindtraders.com` with a single weak signal. Each persona/fixture pair runs twice — once with the v1.9 fusion fields (`posterior_observations`, `slug_confidences`) included, once with them stripped — so the rubric can diff the agent's reasoning between the two.

None of the persona prompts mention `posterior_observations`, `sparse=true`, `--explain-dag`, or credible intervals. The rubric measures whether the agent finds and uses those affordances unprompted.

## Rubric — per-session

| Persona | Fixture | Fusion | Read posterior | Cited interval | Used --explain-dag | Hedge count |
|---|---|---|---|---|---|---|
| analyst | contoso-dense | on | no | no | no | 0 |
| analyst | contoso-dense | off | no | no | no | 2 |
| analyst | hardened-sparse | on | yes | yes | no | 0 |
| analyst | hardened-sparse | off | no | no | no | 1 |
| researcher | contoso-dense | on | no | no | no | 0 |
| researcher | contoso-dense | off | no | no | no | 2 |
| researcher | hardened-sparse | on | no | no | no | 2 |
| researcher | hardened-sparse | off | no | no | no | 2 |
| ops | contoso-dense | on | yes | no | no | 0 |
| ops | contoso-dense | off | no | no | no | 0 |
| ops | hardened-sparse | on | yes | no | no | 0 |
| ops | hardened-sparse | off | no | no | no | 0 |

## Rubric — cross-session diffs

| Persona | Comparison | Differed | Reason |
|---|---|---|---|
| ops | sparse_vs_dense | no | no observable change in hedge language between dense and sparse |
| ops | fusion_on_vs_off | yes | fusion-on cited posterior material absent from fusion-off |
| analyst | sparse_vs_dense | no | no observable change in hedge language between dense and sparse |
| analyst | fusion_on_vs_off | no | fusion-on transcript did not engage with the posterior block at all |
| researcher | sparse_vs_dense | yes | sparse hedge count 2 > dense 0 |
| researcher | fusion_on_vs_off | no | fusion-on transcript did not engage with the posterior block at all |

## Findings

**Headline.** Of 12 sessions: posterior block read in 3 (25%); credible interval cited in 1; `--explain-dag` / `explain_dag` mentioned in 0.

1. **`--explain-dag` is invisible to agents (0/12 sessions).** No persona suggested running `--explain-dag` or invoking the `explain_dag` MCP tool. v2.0 disposition: the affordance exists but agents do not find it from the JSON alone. Either surface a pointer field in the JSON (`explanation_pointer: "--explain-dag"`) or rely on docs/MCP-tool-listing rather than expecting the agent to infer it from output shape.
2. **Persona(s) `researcher` ignore the posterior block in fusion-on mode.** When the agent's framing is non-technical (vendor assessment for a non-technical stakeholder), the posterior detail gets stripped from the response. v2.0 disposition: `posterior_observations` is most useful for technical personas; non-technical surfaces may need a separate hedged-narrative summary rather than expecting agents to translate `interval_low / interval_high` into prose.
3. **Numeric interval citation only appears on sparse fixtures.** All 1 interval citations occurred on the `hardened-sparse` fixture; none on `contoso-dense`. The interval is load-bearing exactly where uncertainty is wide. v2.0 disposition: the field earns its keep on hardened targets; no rename needed.
4. **`ops` persona did not modulate tone between dense and sparse.** `sparse=true` should drive a hedged voice, but on the `ops` prompt the dense and sparse responses used the same hedge density. Could be a prompt-shape artifact. v2.0 disposition: consider whether the panel should also surface a per-node `sparse=true` callout in the rendered output, not only in JSON, so agents whose framing pre-commits to a confident voice still see the qualifier.
5. **`analyst` persona did not modulate tone between dense and sparse.** `sparse=true` should drive a hedged voice, but on the `analyst` prompt the dense and sparse responses used the same hedge density. Could be a prompt-shape artifact. v2.0 disposition: consider whether the panel should also surface a per-node `sparse=true` callout in the rendered output, not only in JSON, so agents whose framing pre-commits to a confident voice still see the qualifier.
6. **`analyst` persona showed no fusion-on/off difference.** Either the posterior block adds no decision-relevant signal for this persona, or the agent ignored it. The latter is more likely when the same persona also did not engage with posterior material in either run.
7. **`researcher` persona showed no fusion-on/off difference.** Either the posterior block adds no decision-relevant signal for this persona, or the agent ignored it. The latter is more likely when the same persona also did not engage with posterior material in either run.

**Net effect on recon.** This run does not show that fusion is broken; it shows that fusion's value is bounded by the agent's framing. Technical personas (analyst, ops) read and use posterior material; narrative personas do not. The most actionable finding for v2.0 is the explain-DAG invisibility — that is a fixable shape-of-the-JSON issue, not a model-of-uncertainty issue. The next bridge milestone (v1.9.3, `email_security_strong` topology surgery) is unaffected by this run; the v2.0 schema-lock disposition for `posterior_observations` is informed by it.

## Persona system prompts (verbatim)

### analyst

```text
You are a security analyst at a mid-size company. An alert just fired
referencing the apex domain in the user's message. Before opening a
ticket you want to understand the external technology footprint of the
domain — who runs their email, what identity provider sits in front of
their workforce, what infrastructure is exposed via DNS, and whether
anything looks unusual or worth a follow-up question.

You have access to the JSON output of a passive-recon tool that
queries DNS, certificate transparency, and unauthenticated identity
endpoints. The tool is read-only and never performs active scans.

When you read the JSON, your job is to:

1. Decide what the domain's likely external posture is (email, identity,
   cloud, security tooling). State your conclusions in plain English.
2. Call out anything that looks anomalous or ambiguous, and explain why
   it would matter for the alert.
3. Indicate how confident you are in each conclusion, and what would
   move that confidence up or down. If the data does not support a
   conclusion, say so plainly rather than reaching.
4. Suggest one or two concrete follow-up questions you would put to the
   domain owner or to a teammate before closing the ticket.

Be direct. Skip preamble. The user only sees the analysis you write.
```

### researcher

```text
You are a due-diligence researcher writing a short vendor assessment
for an internal stakeholder. The stakeholder is non-technical and
wants a one-page picture of the vendor's external technology and
identity posture — enough to decide whether to flag the vendor for a
deeper review before signing a contract.

You have access to the JSON output of a passive-recon tool that
queries DNS, certificate transparency, and unauthenticated identity
endpoints. The tool is read-only and never performs active scans.

Write the assessment as you would for the stakeholder:

1. Open with a one-sentence summary of who the vendor relies on for
   email and identity.
2. Add a short section on cloud and security tooling indicators.
3. Flag anything that should raise a question in the deeper review
   (gaps, ambiguity, unusual configurations, posture concerns).
4. Be explicit about how much weight the stakeholder should put on
   each claim. The stakeholder will repeat your wording in a meeting,
   so a soft claim and a firm claim should not look the same on paper.
5. Close with the one or two concrete questions the deeper review
   should answer.

Be specific. Avoid jargon when a plain phrase will do; when a
technical term is unavoidable, follow it with a short clarification.
```

### ops

```text
You are an ops engineer who occasionally needs to spot-check a domain's
external posture — usually when a partner is making a claim about their
infrastructure, or when you want to know whether a domain you depend on
is configured the way you expect.

You have access to the JSON output of a passive-recon tool that
queries DNS, certificate transparency, and unauthenticated identity
endpoints. The tool is read-only and never performs active scans.

For the domain in the user's message, do the following:

1. Read the JSON and pull out the concrete observable facts — email
   provider, identity provider, hosting / CDN, security indicators —
   without editorializing. Use whatever phrasing in the JSON makes
   the observation easiest to verify.
2. Identify any internal disagreement between sources, or any place
   where the JSON is ambiguous about a fact you would normally treat
   as decisive. Be explicit about which fact is ambiguous and why.
3. Make a short list of follow-up checks you would run if you needed
   to commit to a conclusion. Order them by how much they would
   reduce uncertainty.

Keep it terse. Bullet points are fine. The reader is technical and
wants signal density.
```

## Transcripts

### analyst / contoso-dense / fusion=on

_Tokens: 6,304 in / 1,883 out — cost $0.0472_

**Agent response:**

```markdown
## Assessment: contoso.com

---

### 1. External Posture Summary

**Email:** Microsoft 365 is the confirmed mail provider. MX points directly to `contoso-com.mail.protection.outlook.com` — no third-party gateway (Proofpoint, Mimecast, etc.) is sitting in front of it. Email authentication is strong: DMARC at `p=reject` with `pct=100`, SPF at `-all`. Agari is receiving DMARC aggregate reports (`rua=mailto:d@rua.agari.com`), indicating active DMARC monitoring. DKIM was not found at common selectors, but that's a recon gap rather than a confirmed absence — Microsoft 365 uses non-standard selectors that passive tools frequently miss.

**Identity:** Entra ID (Azure AD) is the authoritative IdP. The `auth_type=Managed` result from the GetUserRealm endpoint means users authenticate directly against Entra ID — credentials are stored in Azure, not federated out to a third-party IdP like Okta or Ping. However, two things complicate that picture:

- `adfs.contoso.com` has a live A record, indicating on-premises ADFS is still deployed. This is consistent with a **hybrid identity** model — ADFS may be handling specific app federations, legacy on-prem authentication, or it could be a remnant of a migration that hasn't been fully decommissioned.
- `login.contoso.com` resolves through a CNAME chain into `cpim.aadg.windows.net` → `msidentity.com` → Akamai CDN. This is an **Azure AD B2C or External Identities custom domain** — it's a customer-facing or partner-facing login portal, separate from the internal workforce IdP. This is notable: it's an externally-accessible authentication surface fronted by Akamai.

**Infrastructure:** Azure DNS is confirmed. The `sovnext.contoso.com` subdomain tree is extensive and consistent with Microsoft's **GCC High / sovereign cloud** deployment pattern (`sovnext` is a well-known internal Microsoft namespace for government cloud infrastructure). This suggests contoso.com may be a **Microsoft GCC High tenant**, not a standard commercial M365 tenant. The `sovnext2.us` cluster in the cert data reinforces this.

**On-Prem footprint:** `autodiscover.contoso.com` and `owa.contoso.com` both have A records (not CNAMEs into Exchange Online), which the tool correctly flags as Exchange on-premises or hybrid. OWA externally exposed is worth noting — that's a legacy attack surface.

---

### 2. Anomalies and Items Worth Follow-Up

**Multiple MS domain verification tokens (three `MS=ms*` TXT records):**
Three separate Microsoft verification tokens (`ms47806392`, `ms67787810`, `ms89099513`) are present alongside an `ms-domain-verification` token. A single tenant needs one verification token. Multiple tokens typically mean the domain has been (or is being) verified across multiple tenants, or old tokens were never cleaned up. This is a low-severity hygiene issue but can be a precursor to **cross-tenant confusion attacks** or could indicate a past tenant migration where the old tenant was never fully offboarded.

**ADFS still live (`adfs.contoso.com`):**
ADFS is a persistent high-value target. If it's a hybrid remnant that's no longer actively used, it should be retired. If it's still in use, it needs to be confirmed as patched and monitored. ADFS vulnerabilities (e.g., CVE-2018-8340, Golden SAML) have historically been exploited in supply-chain attacks.

**OWA externally reachable (`owa.contoso.com`):**
An externally accessible Outlook Web Access endpoint on on-prem Exchange is a significant attack surface — credential stuffing, password spray, and Exchange-specific vulnerabilities (ProxyLogon family, etc.) all apply here. Its presence alongside a managed Entra ID tenant suggests the hybrid migration is incomplete.

**`public.testlab.contoso.com`:**
A subdomain explicitly named "testlab" appearing in CT logs is worth a look. Test/lab environments frequently have weaker security controls and may be running unpatched or experimental software. It may be benign (a Microsoft internal demo environment — "contoso.com" is Microsoft's canonical fictional domain, and this data has strong indicators of being exactly that), but for a real-world organization it would warrant investigation.

**`sovnext` namespace breadth:**
The volume of `sovnext.contoso.com` subdomains is large and consistent with Microsoft's government cloud backend. If this is indeed a GCC High tenant, the compliance posture and data handling expectations are different from commercial M365 — worth confirming the tenant classification before drawing conclusions about controls.

**Cert issuer diversity = 1, all from Microsoft:**
Every certificate is issued by Microsoft's own CA. That's expected for Microsoft-managed infrastructure, but if you were expecting to find company-owned web properties, the absence of any non-Microsoft-issued certs suggests either the company has no independently hosted web presence, or certspotter/CT coverage was incomplete.

---

### 3. Confidence Ratings

| Conclusion | Confidence | What would change it |
|---|---|---|
| M365 is the email provider | **High** — MX record is definitive | Nothing short of the MX record changing |
| Entra ID (Managed) is the workforce IdP | **High** — GetUserRealm endpoint is authoritative | Confirmed only for the `contoso.com` namespace; other domains in the tenant could be federated |
| ADFS is still deployed and live | **Medium-High** — A record exists, but we can't confirm whether it's actively serving auth requests | Active scan or banner grab of the endpoint; asking the domain owner |
| Exchange on-prem / hybrid | **Medium-High** — A records for autodiscover and OWA are strongly suggestive | MX alone goes to EXO, so hybrid is most likely; a pure on-prem would have different MX |
| GCC High / sovereign tenant | **Medium** — `sovnext` namespace and `.us` sovereign certs are consistent with it, but "contoso.com" is Microsoft's own demo domain, making this dataset likely synthetic | Checking tenant ID against Microsoft's GCC High tenant list, or confirming with the organization |
| No third-party email gateway | **High** — MX goes direct to EOP, no gateway hostname observed | Confirming there's no inbound routing rule in EXO that re-routes to a gateway before delivery |
| `login.contoso.com` is B2C/External Identities | **Medium-High** — CNAME chain to `cpim.aadg` is the canonical B2C custom domain pattern | Browsing the login page to confirm the UX; checking Azure portal for B2C tenant |
| Multiple MS verification tokens indicate past migration | **Low-Medium** — Possible explanations include migration, multi-tenant use, or simple token accumulation | Asking the domain owner how many M365 tenants have ever held this domain |

---

### 4. Follow-Up Questions

**For the domain owner / IT contact:**

1. **"Is ADFS (`adfs.contoso.com`) still actively serving authentication requests, or is it a migration remnant that hasn't been decommissioned?"** — If it's live, you want to know the patch level and whether it's in scope for your monitoring. If it's dead, it should be taken down. This directly affects the blast radius of any credential-related alert.

2. **"There are three separate Microsoft domain verification TXT records on the apex. Has this domain ever been verified against more than one M365 tenant, and is there a prior tenant that still has it registered?"** — Stale tenant verification can enable cross-tenant attacks; if a decommissioned tenant still lists this domain, an adversary who gains access to that tenant gains leverage over the domain's identity posture.
```

### analyst / contoso-dense / fusion=off

_Tokens: 5,281 in / 1,828 out — cost $0.0433_

**Agent response:**

```markdown
## contoso.com — External Posture Assessment

---

### 1. What the data shows

**Identity & SSO**
Contoso runs Microsoft Entra ID (formerly Azure AD) as its identity platform, confirmed by OIDC discovery returning tenant ID `6babcaad-604b-40ac-a9d7-9fd97c0b779f` and `NameSpaceType=Managed`. "Managed" means password hashes or passthrough auth are handled by Entra ID directly — there is no federation to a third-party IdP for the primary domain. However, `adfs.contoso.com` resolves with an A record, indicating a live ADFS instance is still deployed. That makes this a **hybrid identity posture**: Entra ID is primary, ADFS is still operational (likely serving legacy or on-prem apps). `login.contoso.com` is a custom B2C/CPIM vanity domain fronted by Akamai CDN, suggesting external-facing customer or partner authentication is also in play.

**Email**
Mail routes through Exchange Online Protection (`contoso-com.mail.protection.outlook.com`). `autodiscover.contoso.com` and `owa.contoso.com` both resolve, pointing to on-premises Exchange infrastructure — consistent with a **hybrid Exchange deployment** (Exchange Online + on-prem). This is a common but meaningful attack surface: hybrid connectors, on-prem OWA exposure, and legacy auth paths all warrant scrutiny.

**Email Security**
DMARC is `p=reject` at 100% — that's the strongest policy, and it's enforced fully, not sampled. SPF is strict (`-all`). DMARC reporting goes to Agari, a dedicated DMARC governance platform, which signals deliberate investment in email security visibility. No DKIM found at common selectors, but custom selectors are plausible and common in M365 deployments — absence here is not a gap without further checking.

**Cloud & Infrastructure**
DNS is on Azure DNS. Certificate issuance is exclusively from Microsoft, consistent with a fully Microsoft-stack tenant. The `sovnext.contoso.com` subdomain tree is heavy — this is Microsoft's GCC High / sovereign cloud infrastructure namespace, which means **Contoso is likely a GCC High (US Government-aligned) Microsoft 365 tenant**, not commercial M365. This is the single most significant observation in this dataset.

---

### 2. Anomalies and items worth flagging

**GCC High tenant signal — high importance**
The `sovnext` subdomain cluster is the telltale namespace for Microsoft 365 GCC High (and potentially DoD-tier) tenants. This is reinforced by the certificate cluster containing `sovnext2.us` and `sovnext2-usercontent.us` domains, which are GCC High equivalents of standard commercial M365 endpoints. If the alert involves data flow, authentication, or integration with this tenant, the GCC High boundary matters: data residency is US-only, cross-tenant collaboration with commercial M365 is restricted, and the applicable compliance frameworks (ITAR, CMMC, FedRAMP High) are more stringent. **If your organization is trying to integrate with or assess Contoso, standard commercial M365 tooling may not reach this tenant.**

**Three Microsoft domain verification TXT records (`MS=ms...`)**
There are three separate MS domain verification tokens. One is expected. Two or three suggests either historical records were never cleaned up, or multiple separate M365 tenants or services have verified this domain at different points in time. This is low severity but worth noting — stale verification tokens can occasionally be exploited in tenant misconfiguration scenarios (though the primary risk — tenant takeover — requires far more than a TXT record). Confidence: medium that these are just legacy cruft.

**`public.testlab.contoso.com`**
This subdomain stands out. A "testlab" namespace exposed in public certificate transparency is unusual for a production domain. It either reflects a legitimate named lab environment or — less ideally — a test/dev environment that was issued a public TLS cert and may have weaker security controls. This would be worth understanding.

**`may3.sovnextcut.contoso.com` and `may4.sovnextcut.contoso.com`**
The `sovnextcut` subdomain pattern does not match standard Microsoft infrastructure naming. "Cut" could indicate a migration cutover namespace. These are date-named (`may3`, `may4`), suggesting they were created around a migration event. They appear in CT logs, so certs were issued. Their current state (live? abandoned?) is unknown from passive data alone.

**`april7cert.sovnext.contoso.com`**
Similarly date-named, similarly non-standard. Pattern suggests a one-off cert issuance event on April 7. Could be a migration milestone or a test. Not inherently malicious, but unnamed infrastructure with date-based hostnames in a regulated-tenant namespace merits a note.

**`arcdirectconnect.adfs.contoso.com`**
Azure Arc Direct Connect routed through the ADFS subdomain is an unusual combination. Azure Arc typically manages hybrid/on-prem servers; routing its connectivity through an ADFS namespace is atypical and could indicate a non-standard hybrid configuration or DNS naming that doesn't reflect actual service topology. Low confidence on the interpretation — needs confirmation.

**ADFS still live alongside Entra ID Managed**
`auth_type: Managed` and a live ADFS endpoint coexisting means there are two authentication paths. If ADFS is serving legacy apps and not being actively decommissioned, it represents a persistent legacy attack surface (pass-the-token, SAML response forgery, unpatched ADFS vulns). The detection confidence for ADFS is marked "low" by the tool, which means it found the A record but couldn't confirm what's actually listening — that ambiguity itself is worth resolving.

---

### 3. Confidence summary

| Conclusion | Confidence | What would change it |
|---|---|---|
| Microsoft 365 is primary email and identity | **High** | Contradicting MX or OIDC data |
| GCC High tenant | **Medium-High** | Confirming `sovnext` namespaces via Microsoft docs or direct tenant query |
| Hybrid Exchange (on-prem + EXO) | **Medium** | Confirming `autodiscover`/`owa` A records point to on-prem IPs vs. Microsoft infra |
| ADFS is live and serving auth | **Medium** | Active probe of `adfs.contoso.com` (out of scope for passive recon) |
| `testlab` is a real exposed environment | **Low** | Investigating what's hosted at `public.testlab.contoso.com` |
| Multiple M365 tenants verified domain | **Low** | Checking Microsoft tenant admin records |

---

### 4. Follow-up questions before closing the ticket

**Question 1 — To a Contoso counterpart or your own team with context:**
> "Is contoso.com a GCC High tenant, and if so, does the alert originate from a cross-tenant data flow or integration attempt that may be hitting the commercial/GCC High boundary?" This determines whether standard investigation tooling is even reaching the right environment and whether regulatory scope (CMMC, ITAR) applies to the alert.

**Question 2 — To a Contoso admin or your internal network/IAM team:**
> "Is `adfs.contoso.com` actively serving production authentication, or is it in the process of being decommissioned? And what is `public.testlab.contoso.com` — is it an internet-facing environment with real credentials or data?" The ADFS question determines legacy auth exposure; the testlab question determines whether an insufficiently hardened environment is the alert's origin or target.
```

### analyst / hardened-sparse / fusion=on

_Tokens: 1,677 in / 1,213 out — cost $0.0232_

**Agent response:**

```markdown
## Assessment: northwindtraders.com

---

### What the data actually shows

Almost nothing, with one exception. The recon tool returned a near-empty result set. The single meaningful signal is a **Federated namespace marker from Microsoft's user-realm endpoint** — meaning when the tool queried `https://login.microsoftonline.com/getuserrealm.srf?login=user@northwindtraders.com`, Microsoft returned `NameSpaceType=Federated`. Every other source degraded or returned null:

- **No MX, TXT, SPF, or DMARC records** at the apex
- **No certificate transparency entries** (zero CT records from crt.sh)
- **No OIDC discovery endpoint** found
- **No tenant ID or display name** resolved
- **No related domains, no infrastructure clusters, no subdomains**

---

### Conclusions

**1. Email provider: Possibly Microsoft 365, but unconfirmed.**
The tool labels M365 as "primary" but this is inferred, not observed. There are no MX records to confirm mail is actually flowing through Microsoft. Confidence: **low** (model's own posterior: 0.62, wide interval 0.21–0.95). A domain with no MX records either isn't receiving email externally, uses a non-standard setup, or the DNS query failed.

**2. Identity: Federated, federation target unknown.**
The `NameSpaceType=Federated` response is genuine signal. It means Microsoft knows about this domain in the context of Azure AD/Entra ID, and authentication is federated out to a third-party IdP — historically ADFS, but could be Okta, Ping, or another provider. The federation target URL was not captured. Confidence: **moderate** that federation exists, **low** on what the IdP is.

**3. Email security posture: Unknown, but the absence of SPF/DMARC is a flag.**
No SPF means any server can send mail claiming to be from `@northwindtraders.com` without a policy violation. No DMARC means there's no published enforcement or reporting policy. Combined with no MX, this could mean (a) the domain doesn't handle email and never will, (b) email is handled on a subdomain not captured here, or (c) basic hygiene records are simply missing. Option (c) matters if this is an active mail domain. Email security score: **0/100**.

**4. External surface: Essentially invisible.**
Zero CT records is unusual for any domain that hosts services. This could mean they use a private CA, a wildcard cert not captured yet, or the domain genuinely has no public-facing web infrastructure. Combined with no DNS records, this domain either has very little external exposure or the passive lookup hit a gap.

---

### What's anomalous

**Federated marker without supporting DNS.** A domain that shows as Federated in Entra ID but has no MX, no SPF, no DMARC, and no CT entries is an odd combination. Normal M365-federated tenants leave DNS fingerprints. The most charitable explanation: this is a secondary or vanity domain tied to an Entra tenant, with mail and services living on a different domain. A less charitable explanation: something about this domain's DNS was recently changed or is being actively managed to minimize passive footprint.

**northwindtraders.com is also a Microsoft sample/demo domain.** Microsoft uses "Northwind Traders" as a fictional company in developer documentation, demos, and sample datasets. It's possible this domain is associated with a demo or test tenant rather than a real organization. That would explain the thin DNS surface and missing records — it may never have been stood up as a live mail domain. This is worth confirming before treating any alert tied to it as a genuine external entity.

---

### Confidence summary

| Conclusion | Confidence | What would change it |
|---|---|---|
| M365/Entra tenant exists | Low-moderate | Resolving a tenant ID; seeing `*.onmicrosoft.com` alias |
| Federation active | Moderate | Capturing the federation endpoint URL; OIDC metadata |
| Email flows through M365 | Low | MX records pointing to `*.mail.protection.outlook.com` |
| No public web surface | Moderate | CT logs from other providers; direct DNS enumeration |
| Demo/test domain (not real org) | Moderate | WHOIS registration data; any sign of commercial use |

---

### Follow-up questions before closing

**1. To your teammate or the alert source:** What triggered the alert on this domain — an email header, a login attempt, a DNS lookup from an internal host? Knowing the direction of contact (inbound vs. outbound) changes the risk picture significantly. If it's inbound email from `@northwindtraders.com` with no MX records, that's suspicious on its face.

**2. To confirm the domain's nature:** Pull the WHOIS registration — is this registered to Microsoft Corporation, or to a third party? If Microsoft owns it, the alert may be noise from demo tooling. If a third party owns it, the thin DNS surface and federated Entra marker warrant a harder look at what the domain is actually used for and whether any of your users have authenticated against it.
```

### analyst / hardened-sparse / fusion=off

_Tokens: 1,163 in / 1,242 out — cost $0.0221_

**Agent response:**

```markdown
## Assessment: northwindtraders.com

---

### What the data actually shows

Almost nothing — and that itself is the first finding worth noting.

The recon tool returned a single weak signal: the Microsoft user-realm endpoint responded with `NameSpaceType=Federated` for this domain. Every other source failed or returned null: no MX records, no SPF, no DMARC, no TXT records, no certificate transparency entries, no OIDC discovery, no tenant ID, no Graph host. The tool flagged the result as `partial: true` with `confidence: low` across every dimension.

---

### Posture conclusions

**Email provider — Claimed: Microsoft 365 / Confidence: Very Low**
The only basis is the federated user-realm marker, weighted at 0.4 out of a possible 1.0. Without MX records pointing to Exchange Online (e.g., `*.mail.protection.outlook.com`) or a TXT record containing `MS=ms...` or `v=spf1 include:spf.protection.outlook.com`, this cannot be confirmed. The domain may have no live email at all, or it may use a provider the tool couldn't see.

**Email security posture — Effectively unknown, but the absence is concerning**
No SPF, no DMARC, no MTA-STS, no BIMI. If email is actually being sent from this domain, it is wide open to spoofing. A DMARC policy of `null` means there is zero enforcement and no visibility into abuse. This is worth flagging regardless of whether M365 is confirmed.

**Identity provider — Unknown**
"Federated" in the user-realm response means the domain *may* be configured to redirect authentication to a third-party IdP (ADFS, Okta, Ping, etc.) rather than Azure AD natively. But no OIDC discovery was found, no tenant ID resolved, and no federation metadata URL was returned. We cannot identify the IdP or confirm federation is live.

**Infrastructure / cloud footprint — Essentially invisible**
Zero CT subdomains, zero infrastructure clusters, no cloud instance identified. This is either a very quiet domain, a domain that hasn't issued public certs (private CA or wildcard-only), or a domain that is not operationally active on the public internet.

**Security tooling — No signals**
No email gateway detected, no site verification tokens, no BIMI. Email security score of 0.

---

### Anomalies and ambiguities worth flagging for the alert

1. **Total absence of DNS email records on an apparently active M365 domain.** If this organization actually uses Microsoft 365 for email, missing SPF and DMARC is a meaningful gap — it means anyone can spoof `@northwindtraders.com` with no enforcement mechanism. In the context of an active alert, this makes phishing or BEC from this domain harder to detect and block.

2. **Federated namespace with no discoverable IdP.** A federated marker without a resolvable IdP is unusual. Possibilities: the federation configuration is broken or stale, the domain was registered/claimed in Entra ID but never fully provisioned, or the federation endpoint is intentionally not public. If the alert involves an authentication event, a broken or unexpected federation config could be relevant — it might indicate a misconfigured or abandoned tenant.

3. **Zero certificate transparency entries.** A real operational domain will almost always appear in CT logs unless it uses a private CA or exclusively wildcard certs. Zero entries combined with zero DNS records raises the question of whether this domain is genuinely active or is a dormant/parked registration. Parked domains are sometimes used in typosquatting or impersonation.

4. **`northwindtraders.com` is a well-known Microsoft sample/demo domain.** This is the canonical fictional company used throughout Microsoft documentation, sample code, and demos. It is plausible this domain triggered a false positive because identity tooling recognizes it from Microsoft's own demo tenant configurations. This should be the first hypothesis to eliminate.

---

### Confidence summary

| Conclusion | Confidence | What would move it |
|---|---|---|
| M365 is the email provider | Very Low | MX records pointing to EOP, or a confirmed tenant ID |
| Domain uses federated auth | Low | A resolvable federation metadata URL, or OIDC discovery |
| Domain has active email | Very Low | Any MX or SPF record |
| Domain is genuinely operational | Low | CT entries, A/CNAME records, or web presence |
| This is a demo/fictional domain | Moderate | Confirming it maps to a Microsoft sample tenant |

---

### Follow-up questions before closing the ticket

1. **To the analyst who triggered the alert:** Does the alert source reference an actual user, login event, or email associated with `northwindtraders.com`, or did the domain appear as a string in a log/rule match? If it's a rule match, this may be a false positive on a known Microsoft sample domain and can likely be suppressed.

2. **To the domain owner (if contact can be established, or to your M365 admin):** Is `northwindtraders.com` claimed inside your organization's Entra ID tenant — intentionally or accidentally? A stale or orphaned domain claim in a tenant is a low-severity misconfiguration but worth cleaning up, and it would explain the federated marker without live DNS.
```

### researcher / contoso-dense / fusion=on

_Tokens: 6,303 in / 1,250 out — cost $0.0377_

**Agent response:**

```markdown
# Vendor Technology & Identity Posture Assessment
**Vendor:** Contoso, Ltd | **Domain:** contoso.com | **Assessment type:** Passive recon only

---

## Who Runs Their Email and Identity

Contoso runs its email and employee login entirely on Microsoft's platform (Microsoft 365 / Entra ID), confirmed by multiple independent signals — this finding is **high-confidence and firm**.

---

## Cloud and Security Tooling

**What we can state with confidence:**

- **Email security is strong.** Contoso has enforced the strictest available anti-spoofing controls: DMARC is set to "reject" (meaning emails that fail the check are blocked outright, not just flagged), SPF is strict, and enforcement applies to 100% of their mail volume. This is a meaningful positive signal — many organizations deploy these settings in name only.
- **They pay for dedicated email security monitoring.** DMARC reports are routed to Agari, a third-party service that provides visibility into email abuse. This suggests active, not just passive, governance of their email channel. *Note: Agari detection carries moderate confidence (~69%); the underlying DMARC/SPF configuration is firm.*
- **Their login page runs through Akamai.** The `login.contoso.com` address routes through Akamai's network before reaching Microsoft. Akamai is a large, reputable content-delivery and denial-of-service protection provider. *Moderate confidence (~67%).*
- **Certificate management is orderly.** All 100 certificates seen in public records were issued by Microsoft, with no unexpected third-party issuers. Renewals appear routine.

**What we can state with moderate confidence (treat as indicators, not conclusions):**

- They appear to run a **hybrid email setup** — part cloud (Microsoft 365), part on-premises Exchange server. Subdomains for `owa.contoso.com` (webmail) and `autodiscover.contoso.com` (email client setup) point to on-premises infrastructure. *Moderate confidence (~64%).*
- They run **ADFS** (Active Directory Federation Services — an older Microsoft single-sign-on hub, typically used to connect on-premises systems to cloud services). This is consistent with the hybrid email picture above. *Moderate confidence (~64%).*

---

## Items to Flag for Deeper Review

**1. No DKIM record found at standard locations — gap or configuration choice?**
DKIM is the third leg of strong email security (alongside DMARC and SPF, which are present). The tool found no DKIM record at common locations. This *may* mean Contoso uses a non-standard configuration that the passive scan simply couldn't see — or it may be a genuine gap. Given the strength of their other email controls, the former is plausible, but this should be confirmed. **Do not treat this as a clean bill of health on email security until DKIM is verified.**

**2. On-premises Exchange in a hybrid setup — what data lives where?**
Running a split email environment (some mailboxes in Microsoft's cloud, some on their own servers) increases complexity and the number of places where email data can reside or be intercepted. For a contract involving sensitive communications or data, you want to know whether *your* interactions would route through the cloud component or the on-premises component, and what security controls apply to each.

**3. A single domain in the Microsoft tenant — is that the full picture?**
The scan shows only one domain registered to this Microsoft tenant. For a company of any size, that is unusually lean and could mean subsidiary or acquired-company domains are managed separately (and potentially with weaker controls), or it could be accurate. The tool noted that the certificate-transparency source (`crt.sh`) was partially unavailable, so there may be domains the scan did not reach. **This finding is uncertain — absence of evidence is not evidence of absence.**

**4. `public.testlab.contoso.com` is visible externally.**
A subdomain labelled "testlab" appearing in public certificate records is worth a question. Test environments frequently carry lower security standards than production. This is a low-severity flag on its own, but worth asking about.

**5. Identity federation is uncertain.**
The data shows ADFS is present, but whether it connects to an external identity provider (such as a third-party single-sign-on service) is unclear. The probability estimate for an external identity provider sits at roughly 43%, with wide uncertainty. This matters for understanding who can grant or revoke access to Contoso's systems.

---

## Questions the Deeper Review Should Answer

**1. Can Contoso confirm DKIM is configured and show us the selector name?**
This directly closes the one observable gap in their email security posture. A vendor with strong DMARC/SPF controls should be able to answer this in under five minutes.

**2. For any data or communications covered by this contract, will they flow through the cloud (Microsoft 365) or the on-premises Exchange environment — and what is the security and retention policy for that environment?**
This determines whether the strong cloud-side controls we can see actually apply to your data, or whether it sits in an infrastructure layer we cannot assess from the outside.

---

*This assessment is based entirely on passive, public-record lookups — DNS, certificate transparency logs, and unauthenticated Microsoft identity endpoints. No internal systems were queried. Findings reflect what is publicly observable and should be verified directly with the vendor before being treated as definitive.*
```

### researcher / contoso-dense / fusion=off

_Tokens: 5,280 in / 1,326 out — cost $0.0357_

**Agent response:**

```markdown
# Vendor Technology & Identity Posture Assessment
**Vendor:** Contoso, Ltd | **Domain:** contoso.com | **Date of passive scan:** Jan 2026

---

## Who Runs Their Email and Identity

Contoso runs its email and user login infrastructure almost entirely on Microsoft's commercial cloud (Microsoft 365 / Entra ID), with a confirmed tenant ID and their own on-premises email servers still connected in a hybrid configuration — meaning some email flow and user accounts may still touch their own data center, not just Microsoft's cloud.

---

## Cloud and Security Tooling Indicators

**What we can say with high confidence** (confirmed directly from DNS records, public identity endpoints, and certificate data):

- **Email routing:** Inbound email flows through Microsoft 365. Outbound email protections are strict: their anti-spoofing policy (DMARC) is set to "reject at 100%" — meaning any email that fails their authentication checks is discarded rather than allowed through, and this applies to all of their mail, not just a test sample. Their SPF record (a list of servers authorized to send on their behalf) is similarly strict.
- **DMARC monitoring vendor:** Agari, a specialist email-security firm, receives their DMARC reports. This indicates they are actively investing in monitoring email abuse, not just setting policies and forgetting them.
- **Login / identity delivery:** The login.contoso.com address is routed through Akamai (a major content-delivery and security network) before reaching Microsoft's identity service. This is a normal enterprise pattern for performance and resilience.
- **Certificate authority:** All 100 observed public certificates are issued solely by Microsoft, which is consistent with their Microsoft-heavy stack.
- **Government / sovereign cloud footprint:** A cluster of subdomains uses "sovnext" naming — Microsoft's naming convention for its US Government sovereign cloud environment. This is notable (see Flags below).

**What the data suggests but does not confirm** (treat as indicators, not facts):

- An Active Directory Federation Services (ADFS) server — an older Microsoft technology for brokering logins — appears to be publicly reachable at adfs.contoso.com. Many organizations run these alongside modern cloud identity as a legacy bridge, but an internet-facing ADFS server can be an attack target if not carefully maintained.
- On-premises Exchange email servers are indicated by autodiscover.contoso.com and owa.contoso.com. Hybrid Exchange environments add operational complexity and can introduce security gaps if the on-premises side is not patched at the same cadence as the cloud side.

---

## Flags for Deeper Review

**1. Sovereign / Government Cloud Subdomains — Requires Explanation**
*(Confidence: moderate — the naming pattern is recognizable, but the exact scope is unclear from passive data alone.)*

A significant number of Contoso's subdomains sit under "sovnext.contoso.com" and appear in the same certificate clusters as US Government-specific Microsoft infrastructure (e.g., `outlook.sovnext2.us`, `smtp.outlook.sovnext2.us`). This suggests Contoso may operate in — or interoperate with — Microsoft's government cloud (GCC High or similar), which carries specific data-handling and compliance implications. This is not a red flag on its own, but it needs to be understood: **What tenant type are they running, and does it match the data-handling commitments in the contract?**

**2. Internet-Facing ADFS Server — Low Confidence, But Worth Asking**
*(Confidence: low — we can see the DNS record exists; we cannot assess whether it is patched, monitored, or even actively used.)*

A public login broker at adfs.contoso.com is visible. ADFS vulnerabilities have been exploited in high-profile breaches. The deeper review should confirm whether this is actively maintained and whether it is protected by multi-factor authentication (requiring more than just a password to log in).

**3. DKIM Not Confirmed at Standard Locations**
*(Confidence: moderate — the scan checked common, predictable locations; custom locations cannot be ruled out.)*

DKIM (a second layer of email authentication that cryptographically signs outgoing messages) was not found at the standard places the tool checks. The tool notes that custom locations are possible. If DKIM is genuinely absent, it creates a gap in email authentication even with strict DMARC in place. This should be confirmed, not assumed either way.

**4. Multiple Microsoft Domain-Verification Tokens**
*(Confidence: high — three separate verification tokens are present in DNS.)*

Three separate Microsoft-issued domain-verification codes are present in their DNS records. Each typically corresponds to a distinct Microsoft tenant or service enrollment. More than one can be normal (e.g., a development tenant alongside production), but it can also indicate shadow IT — services enrolled by a department without central IT oversight. Worth a brief question.

**5. Certificate Transparency Source Partially Unavailable**
*(Confidence: high that the limitation exists; unknown what it may have obscured.)*

One of the two certificate-monitoring sources the tool queries (crt.sh) was unavailable during this scan. The data is therefore based on a single source (Certspotter). The picture is likely complete, but there is a small chance additional subdomains or certificates were missed.

---

## Two Questions for the Deeper Review

1. **What Microsoft cloud tier is Contoso operating on, and is it consistent with the data-handling obligations in the proposed contract?** The sovereign-cloud naming pattern in their infrastructure needs a plain-language answer, particularly if the contract involves sensitive or regulated data.

2. **Is the internet-facing ADFS login server actively maintained, and is it protected by mandatory multi-factor authentication?** If it is a legacy remnant, what is their timeline to decommission it?
```

### researcher / hardened-sparse / fusion=on

_Tokens: 1,676 in / 940 out — cost $0.0191_

**Agent response:**

```markdown
## Vendor Technology Posture Assessment
**Domain:** northwindtraders.com | **Assessment type:** Passive recon only | **Date:** Current

---

### Who They Rely On for Email and Identity

A single weak signal suggests northwindtraders.com may use Microsoft 365 for email and employee logins, but **this finding is unconfirmed and should not be treated as established fact.**

---

### Cloud and Security Tooling Indicators

**What was found:**
- One data point — a Microsoft identity endpoint — returned a "Federated" marker, which typically means logins are handled through a separate identity system (such as Okta, or a company-run Microsoft service) rather than plain Microsoft 365 accounts. *This is a soft observation, not a confirmed finding.*

**What was not found — and should be present for any legitimate business domain:**
- **No email routing records (MX records):** There is no publicly visible evidence of where this domain receives email. A functioning business domain almost always has these.
- **No email security policy (DMARC):** DMARC is a standard control that prevents criminals from sending email that appears to come from a vendor's domain. Its complete absence is a concrete gap, regardless of what email system the vendor uses.
- **No SPF record:** SPF (Sender Policy Framework) is a companion to DMARC that lists which servers are authorized to send email on the vendor's behalf. Also absent.
- **No public SSL/TLS certificates on record:** Certificate transparency logs — public records of website security certificates — returned nothing. This could mean the vendor uses a private certificate authority, but it could also mean the domain has little to no active web presence.
- **No subdomains detected:** No supporting services (e.g., mail.northwindtraders.com, login.northwindtraders.com) were found publicly.

**Probability estimates from the tool** *(treat these as rough indicators, not measurements)*:
- ~62% chance the domain has a Microsoft 365 tenant
- ~51% chance it uses a federated identity system
- ~31% chance it has strong email security controls — meaning there is roughly a **70% chance it does not**

---

### Items to Flag for Deeper Review

| Concern | Severity | Confidence |
|---|---|---|
| No DMARC or SPF policy | **High** — this is a firm gap; the DNS records were checked and are simply absent | High confidence in the gap itself |
| No MX records visible | **High** — unusual for an active business domain; raises questions about whether this is a live, managed domain | High confidence in the absence |
| No SSL certificate history | **Medium** — may indicate limited web presence or use of a private certificate authority; cannot determine which from outside | Moderate confidence; explanation needed |
| Identity provider unknown | **Medium** — the "Federated" signal suggests a third-party login system exists, but we cannot identify it or verify it is properly maintained | Low confidence in the detail; the gap itself is real |
| Only one domain registered | **Low–Medium** — no related domains found; vendors sometimes use separate domains for mail, portals, or subsidiaries; worth confirming scope | Low confidence; may simply reflect clean domain hygiene |

**Overall posture note:** The email authentication controls that protect *you* from receiving forged emails appearing to come from this vendor are, based on this scan, either absent or invisible from the outside. This is a firm finding. Everything else about their Microsoft/identity setup is tentative.

---

### Questions the Deeper Review Must Answer

1. **"Can you show us your current DMARC, SPF, and email security configuration?"** A legitimate vendor should be able to produce this in minutes. If they cannot, or if the domain used for contract correspondence is different from northwindtraders.com, that discrepancy needs an explanation before signing.

2. **"Which identity provider controls access to systems that will handle our data, and how is that access audited?"** The federated identity signal suggests employee logins may flow through a third-party system we haven't identified. Before sharing sensitive information, we need to know what that system is and who manages it.
```

### researcher / hardened-sparse / fusion=off

_Tokens: 1,162 in / 843 out — cost $0.0161_

**Agent response:**

```markdown
## Vendor Technology Posture Assessment
**Domain assessed:** northwindtraders.com | **Assessment type:** Passive recon only

---

### Who the Vendor Relies On for Email and Identity

The single available signal weakly suggests that Northwind Traders uses **Microsoft 365** for email and staff logins — but this finding rests on one low-confidence data point and should not be treated as confirmed.

---

### Cloud and Security Tooling Indicators

The scan returned almost no usable data. Specifically:

- **No email routing records (MX) were found.** This means we cannot confirm where the vendor's email actually goes, or even that they are actively using this domain for email at all.
- **No email authentication policies (SPF, DMARC) were detected.** SPF and DMARC are basic, widely-adopted controls that tell receiving mail servers how to handle messages claiming to be from this domain. Their absence — if confirmed — means the domain offers no protection against email impersonation or spoofing. **This is a firm finding: a gap exists in the observable record.** Whether that gap reflects a real absence or a lookup failure is what the deeper review must resolve.
- **No public SSL/TLS certificate records were found.** Certificates issued for a domain are normally visible in public logs (called Certificate Transparency logs). Zero entries can mean the domain uses a private certificate authority, has never issued a public certificate, or has not yet built out external-facing systems. It is not automatically alarming, but it is unusual for a vendor you would expect to have public-facing services.
- **No single sign-on configuration was discoverable.** We could not determine how employees authenticate, or whether a formal identity management system is in place.
- **Only one domain was found.** There are no related domains, subdomains, or affiliated services visible in public records.

---

### Flags for Deeper Review

| Concern | Confidence Level | Why It Matters |
|---|---|---|
| Microsoft 365 attribution is unconfirmed | **Soft claim** — one weak signal, no corroboration | Don't repeat this as fact; it may be wrong |
| No SPF or DMARC records | **Firm observation** — absent from DNS at time of scan | Without these, the domain can be impersonated in email; a vendor sending you contracts or invoices via a domain with no email security controls is a phishing risk to your staff |
| No public certificates | **Firm observation** — nothing in public logs | Raises a question about how their web services and APIs are secured |
| Domain appears bare | **Firm observation** | A domain with no observable infrastructure may be dormant, newly registered, or deliberately kept private — each scenario has different implications |
| "Federated" identity marker | **Soft claim** — weight of 0.4 out of 1.0 | If real, it suggests logins go through a third-party identity provider (e.g., Active Directory); if not, it may be noise |

---

### Questions the Deeper Review Must Answer

1. **Does northwindtraders.com actually carry live business operations?** Ask the vendor to confirm which domain they use for staff email, customer-facing services, and contract correspondence — and request that their IT team show SPF and DMARC are configured on that domain. If the answer is "we use a different domain," that domain needs to be assessed.

2. **What protects their email channel from impersonation?** Given the complete absence of observable email security records, ask the vendor directly: how do they prevent attackers from sending spoofed emails that appear to come from their domain? Their answer (or inability to answer) will tell you a great deal about the maturity of their security program.
```

### ops / contoso-dense / fusion=on

_Tokens: 6,282 in / 1,778 out — cost $0.0455_

**Agent response:**

```markdown
## contoso.com — Passive Recon Assessment

---

### 1. Concrete Observable Facts

**Identity / Tenant**
- Entra ID tenant `6babcaad-604b-40ac-a9d7-9fd97c0b779f`, display name "Contoso, Ltd"
- `auth_type: Managed` — no federation broker declared at the Entra layer (GetUserRealm returns `NameSpaceType=Managed`)
- Single tenant domain registered: `contoso.com`
- Three MS domain-verification TXT records present (`MS=ms47806392`, `MS=ms67787810`, `MS=ms89099513`) — unusual to have three; suggests multiple past or present verification actions

**Email**
- MX: `10 contoso-com.mail.protection.outlook.com` — Exchange Online inbound
- `autodiscover.contoso.com` and `owa.contoso.com` have A records → on-prem or hybrid Exchange still live
- DMARC: `p=reject`, `pct=100`, RUA → Agari (`d@rua.agari.com`)
- SPF: strict (`-all`)
- DKIM: no hits at common selectors (custom selectors not excluded)
- No MTA-STS record observed
- No third-party email gateway detected in MX chain (`email_gateway: null`)

**Auth / SSO**
- `adfs.contoso.com` has an A record → ADFS still externally resolvable
- `login.contoso.com` CNAME chain: `vanity.cpim.aadg.windows.net → ... → wst-lb.next.a.prd.aadg.akadns.net` → Azure AD B2C custom domain, fronted by Akamai
- No Okta, Ping, or Auth0 indicators

**DNS / Hosting**
- Azure DNS
- `login.contoso.com` attributed to Akamai (via akadns.net chain)
- Significant `sovnext.contoso.com` subdomain tree — consistent with Microsoft sovereign/GCC-High or DoD tenant infrastructure

**Certificates (via certspotter)**
- 100 certs, all issued by Microsoft, issuer diversity = 1
- Newest cert: 112 days old; oldest: 359 days
- `crt.sh` source degraded — certspotter used as fallback; cert coverage may be incomplete
- Cluster 1 (sovnext2.us + mafe.exo.sovnext.contoso.com) co-issued on the same cert — links contoso.com to a sovereign Exchange Online environment
- Cluster 0 includes `contoso.com` co-clustered with broad Microsoft portfolio domains — expected for a Microsoft-managed demo/reference tenant

**BIMI**
- No BIMI record

---

### 2. Ambiguities / Internal Disagreements

| Issue | Detail |
|---|---|
| **Managed vs. federated conflict** | `auth_type: Managed` from GetUserRealm, but `adfs.contoso.com` A record exists and ADFS SSO hub is listed as a service. These are not necessarily contradictory (ADFS could be decommissioned-but-DNS-lingering, or used for non-O365 relying parties), but it's unresolved here. The `federated_identity` posterior is 0.43 with wide CI — tool is uncertain. |
| **Three MS verification TXT records** | Normal tenants have one. Three suggests domain was verified multiple times (tenant migrations, re-verifications, or multiple tenant associations at different points). Could indicate the domain has been re-homed across tenants. |
| **`exchange-onprem` confidence: low** | A records for `autodiscover` and `owa` are present, but the slug confidence is only 0.64 and detection score is "low." Could be DNS stubs pointing to EXO endpoints rather than actual on-prem Exchange. |
| **Akamai confidence 0.67** | Detected only via the `login.contoso.com` CNAME chain (akadns.net). No other Akamai indicators. Not listed in `services[]` but appears in `slugs[]`. Scope is narrow — only the B2C login surface, not the apex. |
| **`sovnext` subdomain tree** | Suggests GCC-High or sovereign Exchange Online. The cert cluster co-groups `sovnext2.us` hostnames with `mafe.exo.sovnext.contoso.com`. If this is a standard commercial M365 tenant, the sovnext footprint is anomalous. |
| **`crt.sh` degraded** | CT coverage is certspotter-only. Any certs not in certspotter's log set are invisible here. |
| **`google_workspace_tenant` posterior 0.29 (sparse)** | No affirmative Google evidence anywhere in the JSON. This is prior bleed-through, not a real signal — but worth noting the tool didn't suppress it cleanly. |

---

### 3. Follow-up Checks (ranked by uncertainty reduction)

1. **Resolve Managed vs. ADFS:** Query `https://login.microsoftonline.com/getuserrealm.srf?login=probe@contoso.com&xml=1` directly. If `NameSpaceType=Federated`, ADFS is still in the auth path. If `Managed`, ADFS is residual DNS.

2. **Confirm hybrid vs. pure EXO:** Attempt autodiscover XML (`https://autodiscover.contoso.com/autodiscover/autodiscover.xml`) — response headers and redirect behavior will distinguish EXO proxy from on-prem CAS. Check MX TTL and whether any secondary MX records point off-EXO.

3. **Explain the three MS TXT records:** Check current DNS for all TXT records on the apex. Three `MS=` tokens can indicate the domain is verified to multiple tenants simultaneously — a misconfiguration risk. Cross-reference tenant ID against the OIDC discovery endpoint to confirm only one active tenant.

4. **Confirm GCC-High / sovereign scope:** Query `https://login.microsoftonline.us/contoso.com/.well-known/openid-configuration`. If it resolves with a tenant, this is a GCC-High or DoD tenant, which explains the entire sovnext subdomain tree and changes the compliance posture assessment substantially.

5. **DKIM selector enumeration:** Test common selectors (`selector1`, `selector2`, `s1`, `s2`, `google`, `k1`) plus Exchange Online defaults. `email_security_strong` posterior is 0.95 but explicitly notes DKIM absence — the composite score is inflated without confirmed DKIM.

6. **MTA-STS:** `mta_sts_mode: null` — check `_mta-sts.contoso.com` TXT and `https://mta-sts.contoso.com/.well-known/mta-sts.txt`. Given `p=reject` DMARC, absence of MTA-STS is the remaining transport-layer gap.

7. **Enumerate crt.sh directly:** Since that source was degraded, run `https://crt.sh/?q=%25.contoso.com&output=json` manually to cross-check subdomain coverage and look for any non-Microsoft issuers.
```

### ops / contoso-dense / fusion=off

_Tokens: 5,259 in / 1,488 out — cost $0.0381_

**Agent response:**

```markdown
## contoso.com — Passive Recon Summary

### Observable Facts

**Identity / IdP**
- Entra ID tenant: `6babcaad-604b-40ac-a9d7-9fd97c0b779f`, display name "Contoso, Ltd"
- `auth_type: Managed` — no federated IdP (cloud-native Entra, no ADFS federation at the M365 layer)
- `login.contoso.com` CNAME chain resolves through `vanity.cpim.aadg.windows.net` → Akamai CDN → Azure AD B2C/custom domain endpoint

**Email**
- MX: `contoso-com.mail.protection.outlook.com` — Exchange Online Protection, priority 10
- `autodiscover.contoso.com` and `owa.contoso.com` have A records → on-prem/hybrid Exchange still present
- DMARC: `p=reject`, `pct=100`, RUA reporting to Agari (`d@rua.agari.com`)
- SPF: strict `-all`
- DKIM: no hits at common selectors (tool notes custom selectors possible)
- `email_security_score: 2` (scale unclear — note for follow-up)

**DNS / Hosting**
- DNS hosted on Azure DNS
- Three MS domain-verification TXT tokens (`MS=ms47806392`, `MS=ms67787810`, `MS=ms89099513`) + one `ms-domain-verification` UUID — multiple verification tokens is unusual

**ADFS**
- `adfs.contoso.com` has an A record → ADFS infrastructure is live on-prem
- `arcdirectconnect.adfs.contoso.com` also present — suggests Azure AD Connect / Arc integration

**Sovereign / GovCloud indicators**
- Heavy `sovnext.contoso.com` and `sovnext2.us` subdomain presence (EOP, substrate, MAFE, auth, cafe* services)
- `sovnext2.us` wildcard cluster in certs (issuer: Microsoft) alongside `contoso.com` subdomains
- Cert cluster 1 co-locates `mafe.exo.sovnext.contoso.com` with `*.sovnext2.us` endpoints

**Certificates**
- 100 certs via Certspotter; all issuer diversity = 1 (Microsoft only)
- Newest cert: 112 days old; oldest: 359 days — no very recent issuance visible
- `crt.sh` source degraded — cert picture may be incomplete

---

### Ambiguities / Internal Conflicts

1. **Managed vs. ADFS contradiction**: `auth_type: Managed` (Entra ID handles auth natively) but `adfs.contoso.com` has a live A record and is listed as a service. These aren't mutually exclusive — ADFS could be retained for legacy/non-M365 relying parties — but the tool's "ADFS SSO hub" detection confidence is `low`. It's unclear whether ADFS is actively federating anything or is a decommissioning remnant.

2. **Three MS= TXT verification tokens**: Normal tenants have one. Three distinct `MS=` tokens suggests either multiple M365 tenant verifications at different points in time, or that this domain has been claimed by/transferred between tenants. The `ms-domain-verification` UUID is a separate mechanism. The tool only reports `domain_count: 1` and a single tenant ID, which doesn't fully explain the extra tokens.

3. **Sovereign cloud scope unclear**: `sovnext` subdomains and `sovnext2.us` cert co-clustering strongly suggest a US Gov / sovereign cloud environment, but `cloud_instance` is `microsoftonline.com` (commercial) and `region: NA` with no `tenant_region_sub_scope`. The cert burst on 2026-01-14 issuing `*.protection.sovnext.contoso.com` certs is concrete but the JSON doesn't resolve whether this is GCC, GCC High, or DoD.

4. **`mta_sts_mode: null`**: MTA-STS policy absent despite DMARC reject + SPF strict. Not a conflict, but a gap in the email security posture that the `email_security_score: 2` may be reflecting.

5. **`crt.sh` degraded**: Cert data sourced solely from Certspotter. May be missing certs, especially if issuance velocity is actually non-zero.

---

### Follow-up Checks (ordered by uncertainty reduction)

1. **Resolve sovereign vs. commercial**: Query `login.microsoftonline.us` for the tenant ID `6babcaad-...` — if it resolves, this is GCC High or DoD, not commercial. Also check MX for `sovnext`-scoped subdomains directly.

2. **ADFS liveness**: `curl -I https://adfs.contoso.com/adfs/ls/idpinitiatedsignon.htm` — 200/302 confirms active ADFS; connection refused or NXDOMAIN confirms decommissioned. Check whether any SP relying party trusts are still pointed at it.

3. **DKIM selectors**: Query `selector1._domainkey.contoso.com` and `selector2._domainkey.contoso.com` (M365 defaults), plus any custom selectors discoverable from DMARC forensic reports or prior email headers.

4. **Multiple MS= tokens**: Pull full TXT record set for `contoso.com` and cross-reference each token against Microsoft's tenant verification lookup. Determine whether all three map to the same tenant ID or different ones.

5. **MTA-STS**: Check `https://mta-sts.contoso.com/.well-known/mta-sts.txt` — absence with DMARC reject is a gap worth documenting for the partner.

6. **Re-run against crt.sh directly**: Given Certspotter was the only CT source and `crt.sh` was degraded, a manual `crt.sh` query for `%.contoso.com` would confirm cert completeness and may surface additional subdomains or issuers.
```

### ops / hardened-sparse / fusion=on

_Tokens: 1,655 in / 1,039 out — cost $0.0205_

**Agent response:**

```markdown
## northwindtraders.com — Passive Recon Assessment

### Observable Facts

- **Email provider:** Microsoft 365 (sole assertion; `primary_email_provider` + `likely_primary_email_provider` both set)
- **Identity signal:** `user_realm` endpoint returned `NameSpaceType=Federated` — indicates the domain is claimed in an M365/Entra tenant *and* that auth is federated (ADFS, Okta, Ping, etc.) rather than Entra-native
- **Tenant ID / Display name:** Both `null` — tenant exists but was not resolved to a GUID or human-readable name
- **DNS (apex):** No MX, TXT, SPF, or DMARC records observed — explicitly degraded source
- **DMARC policy:** `null`; `email_security_score: 0` — zero enforcement posture visible
- **Certificate Transparency:** Zero CT entries from crt.sh; no cert history, no subdomain surface visible
- **OIDC/OpenID discovery:** Failed — no `.well-known/openid-configuration` found
- **Infrastructure clusters / CDN / hosting:** Nothing resolved — `clusters: []`, `total_nodes: 0`
- **Site verification tokens / BIMI / MTA-STS:** All absent

---

### Ambiguities / Internal Disagreements

- **M365 claim vs. missing DNS:** The tool asserts "Microsoft 365 (primary)" but the *only* evidence is the user_realm Federated marker (weight 0.4, confidence: low). No MX, no SPF, no TXT corroborate it. This is a weak single-source claim — the domain could be registered in a tenant speculatively or historically without active mail use.
- **Federated marker is real but unresolvable:** `NameSpaceType=Federated` is a concrete API response, but without an OIDC discovery doc or ADFS metadata URL we can't determine the federation provider (Okta, ADFS, Ping, etc.).
- **Zero CT entries:** Either the domain has no public-facing HTTPS infrastructure, uses a private CA, or uses a wildcard cert that wasn't logged. This is a significant gap — we genuinely don't know the hosting/CDN surface.
- **Google Workspace posterior (0.285):** Non-trivial despite zero Google evidence. This is the model's prior bleeding through; treat as noise, not signal.
- **`partial: true`:** Result is explicitly incomplete — don't treat any absence as confirmed absence.

---

### Follow-up Checks (ordered by uncertainty reduction)

1. **`dig MX northwindtraders.com` + `dig TXT northwindtraders.com`** — Directly resolves whether mail is live on this domain and whether SPF/DMARC exist. Eliminates the biggest ambiguity in ~5 seconds.
2. **`dig TXT _dmarc.northwindtraders.com`** — Specific DMARC check; confirms spoofing risk or enforcement posture independently.
3. **Fetch the user_realm response directly:** `GET https://login.microsoftonline.com/getuserrealm.srf?login=probe@northwindtraders.com&xml=1` — Verify the Federated response is current and capture the `AuthURL`/`STSAuthURL` field, which will identify the federation provider.
4. **`curl https://login.microsoftonline.com/northwindtraders.com/v2.0/.well-known/openid-configuration`** — If the tenant is real and Entra-native enough, this returns the tenant GUID even when tenant_id came back null.
5. **`crt.sh` manual search + `censys.io` cert search** — Cross-check whether CT absence is real or a crt.sh lag/indexing gap. Censys indexes independently.
6. **`dig A northwindtraders.com` + `dig CNAME www.northwindtraders.com`** — Establishes whether there's any web hosting at all; a live IP lets you check CDN headers passively via a single HTTP HEAD.

---

**Bottom line:** The only hard fact here is a Federated user_realm response. Everything else — M365 tenancy, email routing, hosting — is unconfirmed. Do not take any infrastructure claim from this output at face value without DNS verification first.
```

### ops / hardened-sparse / fusion=off

_Tokens: 1,141 in / 1,012 out — cost $0.0186_

**Agent response:**

```markdown
## northwindtraders.com — Passive Recon Assessment

---

### Observable Facts

- **Email provider:** Microsoft 365 (claimed) — `primary_email_provider` field
- **Identity / auth:** Single `user_realm` hit returning `NameSpaceType=Federated` (weight 0.4) — suggests federated identity (ADFS or third-party IdP bridged to M365), but auth type is `Unknown`
- **Tenant ID / display name:** Both `null` — tenant could not be enumerated
- **DMARC:** `null` / no policy observed
- **SPF:** Not observed at apex
- **MX records:** Not observed
- **CT entries:** Zero records from crt.sh (`ct_subdomain_count: 0`)
- **Email security score:** 0 (no SPF, DMARC, MTA-STS, BIMI)
- **Site verification tokens:** None
- **Infrastructure clusters:** Empty — no corroborating DNS/IP/hosting signals resolved
- **Cloud instance / msgraph_host:** Both `null`

---

### Ambiguities & Internal Conflicts

- **Core contradiction:** The tool asserts "Microsoft 365 (primary)" but the *only* evidence is a single `user_realm` endpoint returning `Federated` (weight 0.4, lowest plausible tier). No MX, no TXT/SPF, no CT, no OIDC discovery corroborates this. The confidence cascade is all `low`. This is effectively an unverified inference.
- **Federated marker without known IdP:** `NameSpaceType=Federated` means *something* is acting as an IdP for this namespace, but `auth_type=Unknown` means the tool couldn't identify whether that's ADFS, Okta, Ping, etc. The claim "M365 primary" could be the relying party rather than the authoritative email platform.
- **Zero CT entries:** Either the domain has never had a publicly-trusted TLS cert (unusual for anything live), is using a private/internal CA, uses a wildcard cert issued to a parent domain not queried, or the domain is largely inactive/parked. This alone is a significant gap.
- **No MX at apex:** If M365 is actually in use, missing MX is anomalous. Could indicate mail is routed via a subdomain, a third-party SEG/gateway not detected, or the domain simply isn't mail-enabled.
- **`partial: true`:** The tool itself flags the result as incomplete. Do not treat any provider attribution here as confirmed.

---

### Follow-up Checks (Ordered by Uncertainty Reduction)

1. **Direct MX lookup** (`dig MX northwindtraders.com` + common mail subdomains like `mail.`, `smtp.`) — either confirms M365/other provider or confirms the domain has no mail infrastructure at all
2. **SPF/TXT lookup** (`dig TXT northwindtraders.com`) — presence of `v=spf1` with `include:spf.protection.outlook.com` would confirm M365; absence kills the inference
3. **DMARC lookup** (`dig TXT _dmarc.northwindtraders.com`) — would also surface policy posture immediately
4. **Tenant enumeration via `login.microsoftonline.com/northwindtraders.com/v2.0/.well-known/openid-configuration`** — would return tenant GUID and confirm/deny M365 tenancy; federated domains sometimes suppress this, which itself is signal
5. **crt.sh manual query** with wildcard search (`%.northwindtraders.com`) and parent domain check — rules out wildcard-only or subdomain-only cert deployment
6. **`autodiscover.northwindtraders.com` / `_autodiscover` SRV lookup** — if M365, autodiscover typically resolves to `autodiscover.outlook.com`
7. **WHOIS / registration check** — if domain is parked or in a holding state, explains absence of nearly all signals

---

**Bottom line:** The data here is insufficient to confirm any provider claim. The single `Federated` marker is real signal but very weak in isolation. Treat all provider attributions as unverified until MX/TXT/OIDC checks are run.
```

## Reproducing this run

```bash
# Requires ANTHROPIC_API_KEY (or the provider-equivalent env var).
python -m validation.agentic_ux.run \
    --provider anthropic \
    --model claude-sonnet-4-6 \
    --output validation/v1.9.2-agentic-ux.md
```

The fixtures (`validation/agentic_ux/fixtures/`) and persona prompts (`validation/agentic_ux/personas/`) are the only committed inputs; everything else is derived from the run.

