What it covers
| Capability | What it does |
|---|---|
| Phishing simulation | Plans a consented internal campaign: a template, a recipient list restricted to your own organization's verified domains, and a disclosure line included with every simulated message. It is built to be structurally incapable of sending anything at all: there is no code path anywhere in the module that opens a network connection or calls a mail API. Running a real send is a separate, later capability with its own review. Clicking a simulated link is recorded; nothing about the click is capable of capturing a typed password or any other credential; the module has no landing-page form model at all. |
| Awareness training | Assignment triggered by one of three already-detected failures: a click on a simulated phishing link, a real business-email-compromise message that reached an inbox, or a credential found in a transcript or another artefact. The module tracks assignment and completion only; a completion timestamp means someone opened a training module, not that they learned anything, and no competence score is produced. |
| Email security (CEO fraud and impersonation) | Reads a message against who your organization actually is (its own domains, its executives, its known vendors and their real bank details) for the identity, header, and language patterns that mark business-email compromise: executive impersonation from a non-org address, a look-alike domain, a reply-to that diverges from the sender, new or changed payment details in a vendor-invoice context, urgency and secrecy language, and a push to switch channels away from email. |
| Pretext surface | Scores which of your organization's identities are publicly discoverable and whether your domain's own SPF and DMARC posture makes a spoofed pretext easy to stage, reusing the same DNS posture and lookalike-domain checks used elsewhere on the platform. It does not collect that information itself. The discoverable identities you evaluate are facts you already gathered and enter, not something the tool went and found. |
| Insider risk | Framed entirely around access, not people: an account is a fact that exists, was used on some date, and holds some privilege. Nothing here scores an employee, infers intent, or monitors behaviour. It reports residual access after someone leaves, and credentials or connected mailboxes that remain valid after an account was disabled, reusing this platform's own dormancy and standing-privilege findings rather than recomputing them, and reporting a dedicated "not applicable" result where a check has no population to run against, rather than padding it into a false-clean verdict. |
| Fraudulent-campaign filter | Groups reported scam messages by template rather than by sender, since a coordinated fraud campaign rotates through disposable numbers while reusing the same lure. Blocking one number does nothing when the next message arrives from a different one carrying the same text. |
What it stops short of
- Nothing on this platform places a phone call, sends a text message, or impersonates anyone in a live vishing, physical-access, or pretexting engagement. Those are services delivered by a human, and this platform does not offer them.
- The pretext-surface assessment evaluates facts you supply; it does not perform its own reconnaissance to find them.
- Awareness-training tracking measures assignment and completion, never comprehension or future behaviour, and it never infers why a person failed: carelessness, a genuinely well-crafted lure, and simply not having seen the message yet all look identical from the trigger alone.
- Insider-risk findings never estimate a person's intent, loyalty, or state of mind. Where this deployment has no meaningful population to measure (no departed accounts, for instance), the result is reported as not applicable rather than as a clean pass.
- Phishing-campaign metrics are never used to name or score an individual recipient inside this module; each recipient is tracked only by an opaque token.
- A "ready" result on the pretext-surface checklist is never authorization to run a live engagement; that decision belongs to people, not to this tool.
How to run it
- 1
Declare a phishing campaign
Name who authorized it, in what role, and type the exact consent phrase. Recipients outside your organization's own verified domains cause the whole declaration to be refused, not just that recipient. - 2
Review the plan
Every declared campaign starts as a plan (recipient count and template only) before anything further happens. - 3
Connect your mail for BEC detection
Email security reads messages arriving through a connected mailbox against your organization's own domains, executives, and vendors. - 4
Use pretext surface and insider risk as assessments
Enter the facts they ask for from /settings and your organization's own records; both are read-only evaluations, not live tests.
Acceptable use
Every simulation on this platform runs only inside your own organization, against your own verified domains, under a named, accountable owner who typed a consent phrase. Anything outside that scope, such as a target outside your organization, a live vishing call, a physical-access test, or an unconsented campaign, is refused by design, not merely discouraged.
Read before relying on any result
Sentinelleai is an automated security monitoring platform. Nothing it produces is an audit, a penetration test, a compliance opinion, or a guarantee that a system is secure. "No findings" means the tools that ran found nothing, never that nothing is there; anything a tool could not check is reported as unknown, not as clean. For decisions that carry real money or real liability, engage qualified professionals and treat Sentinelleai's output as their starting material.