TL;DR: Legacy email security tools often block attacks without giving analysts enough context to explain why a threat was stopped, according to Abnormal AI’s on-demand Demo Day with Air Canada’s Kyle Howson. The governance issue is not just detection, but whether security teams can understand, validate, and operationalise blocked-attack intelligence across the email environment.
At a glance
What this is: This on-demand Demo Day says cloud email attack prevention depends on more than blocking threats, because analysts also need enough context to understand and use what was detected.
Why it matters: For IAM and security teams, that matters because email security controls increasingly feed identity-related response decisions, and blocked-attack intelligence is only useful if it can be validated, triaged, and acted on.
Context
Cloud email security is not just a detection problem. When a platform blocks an attack but cannot explain why it was stopped, analysts lose the context needed to validate alerts, tune controls, and connect email events to identity and response workflows.
The article frames that gap through Air Canada’s operational experience and the value of blocked-attack intelligence. For practitioners, the issue is whether email security produces evidence that can support day-to-day operations, not only whether it can stop a message from landing in an inbox.
Key questions
Q: How should security teams evaluate cloud email security tools beyond simple block rates?
A: They should assess whether the tool provides enough context to explain each block, support triage, and connect email events to identity risk. A high block rate is not enough if analysts still need to reconstruct what happened from scratch. The useful control is one that turns prevention into evidence.
Q: Why is attack intelligence important when an email security platform already blocks threats?
A: Because prevention alone does not tell analysts what happened or how to improve the control. Attack intelligence turns a stop event into evidence, helping teams understand the tactic, validate the alert, and use the outcome to strengthen policy and response workflows.
Q: What are the signs that email security is creating more work than it saves?
A: The main signs are frequent manual investigation of blocked messages, unclear detection reasons, and analyst reliance on outside evidence to explain why an attack was stopped. Those symptoms show that the platform is preventing threats without giving operations enough usable context.
Q: How can security teams make blocked email detections operationally useful?
A: They should require every blocked event to carry enough detail for triage, correlation, and reporting. That means preserving the message context, detection rationale, and campaign indicators so the SOC can decide what to escalate without starting from scratch.
Background and context
Why blocked-attack context matters in cloud email security
Modern cloud email security is expected to do more than filter messages. It has to identify malicious intent, explain why a message was blocked, and preserve enough evidence for analysts to investigate campaign patterns, sender infrastructure, and user-targeting tactics. When a platform gives only a stop decision, teams must infer the attack path from fragments, which slows triage and weakens control tuning. Context is therefore part of the control, not an optional report layer. In practice, the value is in turning a blocked message into a usable security event that can be correlated with other signals.
Practical implication: Preserve message, sender, and delivery context alongside every blocked email event so analysts can validate and operationalise the detection.
Legacy email security and the visibility gap
Legacy email tools often optimise for containment, but not for explanation. That creates a visibility gap where security teams know an attack was stopped yet cannot see enough detail to determine whether it was a targeted phish, a delivery-bypass attempt, or part of a broader campaign. The operational cost is time spent manually reconstructing what happened, plus a weaker feedback loop for policy improvement. In identity terms, the problem is not only ingress control but evidence quality: security operations cannot govern what they cannot interpret. Effective email defence therefore depends on attack intelligence attached to the event, not buried elsewhere.
Practical implication: Treat lack of explanatory detail as a control gap and require investigation-ready telemetry from email security events.
Cloud email integration as an operational control
Cloud email environments change the operational bar because controls must integrate quickly and support day-to-day analyst work without creating extra administrative overhead. A security platform that is difficult to deploy or manage shifts attention away from threat hunting and toward maintenance, which reduces the benefit of better detections. The architectural point is straightforward: the security control must fit the mailbox and collaboration workflow, not sit beside it as a separate system. When integration is fast and the resulting signals are intelligible, teams can spend more time on genuine threats and less time deciphering tooling output.
Practical implication: Prioritise email controls that integrate cleanly with the production mail environment and reduce analyst overhead.
NHI Mgmt Group analysis
Attack prevention without attack intelligence is incomplete: Blocking an email is only half the control if the platform cannot explain the detection. Analysts need enough context to validate the event, understand the tactic used, and feed the result back into operations. Without that, prevention becomes a black box rather than an actionable security function.
Email security has become an evidence problem, not only a filtering problem: The key governance question is whether blocked messages generate usable artefacts for triage, tuning, and escalation. If the answer is no, teams are left with a containment result that cannot be operationalised across the wider security programme.
Blocked-attack intelligence is the control value: In cloud email, the differentiator is not merely whether a message is stopped, but whether the stop event carries enough signal to support analyst decision-making. That shifts attention from raw detection volume to the quality of the investigative record.
Operational simplicity is now part of security efficacy: If email protection adds complexity, analysts spend their time managing the tool instead of the threat. A control that reduces workload while preserving context gives security teams a better chance of responding consistently and at scale.
What this signals
Blocked-attack intelligence is now part of email governance: In cloud email security, stopping a message is not enough if the SOC cannot explain the detection or turn it into a repeatable workflow. Teams should judge controls by the quality of the evidence they preserve, not only by whether they block delivery.
Analyst time is the hidden cost of opaque controls: When defenders have to reconstruct every blocked email event, security tooling is shifting work rather than reducing risk. The programme signal is clear: the next control requirement is intelligibility, not just interdiction.
For practitioners
- Require investigation-ready telemetry Make every blocked email event include the sender, delivery path, detection reason, and campaign context so analysts can act on it without rebuilding the case manually.
- Test the explanation layer, not only the block rate Validate whether the platform can tell analysts why it stopped a message and whether that explanation is sufficient for triage, escalation, and policy tuning.
- Reduce analyst rework Measure how much time the team spends reconstructing blocked attacks from logs and inbox artefacts, then treat that rework as a control weakness.
- Fit email security into operational workflows Choose controls that integrate with the cloud mail environment and surface usable intelligence in the systems your SOC already uses.
Key takeaways
- Cloud email security fails as an operational control when blocked attacks arrive without enough context for analysts to interpret them.
- The article’s central issue is the gap between prevention and usable attack intelligence, which affects triage, tuning, and response.
- Practitioners should demand investigation-ready telemetry from blocked email events so the SOC can act without manual reconstruction.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10, MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | Email attack paths often exploit weak authentication and impersonation signals. |
| Recommendation — Apply API2-style authentication rigor to verify sender identity and reject spoofed or unauthorised message sources. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potential cybersecurity events | The article centres on monitoring and interpreting blocked email events as security telemetry. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Email controls influence who can deliver, access, and act through the mail channel. | |
| Recommendation — Monitor blocked email events as actionable telemetry rather than treating them as isolated delivery failures. Tighten authorisation paths that allow malicious mail to reach users or trigger follow-on actions. | ||
| MITRE ATT&CK | TA0001;TA0005 — Initial Access; Defense Evasion | Email attacks typically enter through delivery and then evade detection or explanation. |
| Recommendation — Map blocked email patterns to initial access and evasion tactics to improve campaign detection and response. | ||
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | Email security often depends on humans interpreting machine-generated detections correctly. |
| Recommendation — Reduce human interpretation burden by ensuring detections explain themselves clearly to analysts. | ||
Key terms
- Blocked-Attack Intelligence: Blocked-attack intelligence is the contextual information attached to a prevented attack, such as why it was stopped, what it tried to do, and how it was delivered. In email security, this evidence turns a simple block into something analysts can validate, correlate, and use for tuning.
- Investigation Telemetry: The collection of logs, events, and identity data used to reconstruct what happened during an alert. Good telemetry is broad, time-aligned, and accessible across systems. When telemetry is partial or fragmented, AI and human analysts both lose confidence in the resulting decision.
- Email Security Control Debt: Email security control debt is the accumulated mismatch between legacy email controls and current threat behaviour. It shows up as duplicated rules, brittle policy layers, and manual work that persists because the environment was never fully rationalised after older controls lost their original value.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 27, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org