Departure Watch

Metadata-only review of a departed employee's mailbox. An Exchange management scope was measured on 2026-08-08 not to bound the application — see How access is scoped before relying on it. A dedicated-app ApplicationAccessPolicy was measured on 2026-08-17 to bind. Last updated 2026-08-22

What this is

Departure Watch is designed to read message metadata only from a named departed employee's mailbox — subject lines, timestamps, participant addresses, folder, and a link that opens the original message in Outlook. It never reads message bodies, previews, attachment contents, or attachment file names.

Every case is bound to a named window with an explicit end date, after which collection stops, and to a named list of recipients recorded with a written reason for why those people. Recipients must be addresses this organization already knows — an organization member or a People record — and an address that is neither is refused by name at case creation rather than silently dropped. A briefing lists a named individual's client correspondence; a mistyped address that happens to be deliverable would send it to a stranger.

The window is bounded at both ends, and the start bound is the one worth understanding. windowStart is not a label — it is what TATER asks Microsoft Graph for, as a receivedDateTime ge filter — so it decides how far back into the mailbox the feature actually reaches. It may begin at most 90 days before the subject's last day (or before today, if the People record carries no last day), and a case may span at most 180 days in total. Both are refused at case creation and re-checked at activation against the current People record, because a last day corrected by HR after the draft was written would otherwise widen the lookback silently. The 90-day figure is deliberately the same as the maximum metadata retention: collecting deeper history than the platform will keep is incoherent, so the two move together.

Access is fenced at the Microsoft 365 layer, not by TATER's own good behaviour: Exchange Online is told which mailboxes the application may touch, and TATER verifies that grant rather than creating it.

What is live today, and what is not

This is the most important section on the page, and it changes as the feature ships — check its date against your release rather than assuming. The left-hand column is what exists today. The right-hand column is what still stands between a provisioned mailbox and a monitored one.

Provision the Exchange boundary first, before anything else. Activation verifies this provisioning and deliberately refuses to create it: TATER cannot add a mailbox to its own scoping group, because an application that can widen its own scope is not fenced by it. A case whose mailbox has not been provisioned is refused with exchange-scope-not-provisioned, and no amount of configuration inside the product will clear that. The negative test and the Entra grant audit are the parts most often skipped, and they are the parts that make the boundary evidence rather than assertion.

The complete HTTP surface

Fourteen routes, listed in full because a partial list is how an approved scope and a built scope come apart. Eleven live in departureWatch.ts; the last three live in the timer files, so anyone auditing this feature by reading the routes file alone would miss them — and they are the most operationally potent of the set.

“Org member only” means the caller must hold a real membership in the organization — a TATER SuperAdmin who merely selected it in the org picker is refused. A managing service provider with a genuine membership is not: an MSP-run offboarding is a real scenario, and the person authorizing it legitimately works for the MSP. What the check excludes is the platform vendor, who has no relationship to the firm and whose name on a monitoring authorization would be worse than no record at all.

There are no MCP tools for any of this, and there will not be. An automated caller must not be able to authorize surveillance of a person.

Before you begin — the legal gate

This feature reads an identified person's mailbox. Treat the legal question as the first step of the project, not the last.

The platform is designed to refuse collection without a recorded policy attestation for the organization: a statement that the firm has appropriate notice and policy in place for this monitoring, in the jurisdictions listed, as reviewed by named counsel. That attestation should not be recorded until someone with authority has answered the questions in the notice and counsel brief:

• Departure Watch — employee-monitoring notice, attestation, and counsel brief. It lives in the TATER repository at Docs/DEPARTURE_WATCH_NOTICE_TEMPLATE.md. It is deliberately not linked and not published — ask TATER Security for the current copy, and read the warning below before you send it anywhere.

It covers whether existing acceptable-use policy already reaches automated recurring review of a departed employee's account, whether notice obligations attach before monitoring begins, which states' rules apply, third-party content from clients and plan participants who never agreed to firm policy, retention and litigation hold, the scope of the recipient list, and whether transmitting message metadata to an AI provider is acceptable under client confidentiality obligations.

Two points that should be stated plainly to whoever signs the attestation:

• TATER records the attestation. It does not verify or endorse it. The platform serves firms in different states with different obligations and is not positioned to determine any firm's compliance. The attestation is a statement by the firm, stored and audit-logged by the platform.
• Expiry stops collection. The attestation carries an expiry date and the gate treats a lapsed attestation as a block, not as a reminder banner.

Per-case, the design additionally requires a human authorizer, a business justification of at least 40 characters, and an explicit acknowledgement of the folders, window, and retention limits. Machine principals — API keys and service identities — are refused as authorizers by an explicit machine-principal check in the compliance gate (departureWatchGate.ts).

Be precise about what that check is, because the difference matters to anyone relying on it: it enumerates the known machine-identity shapes and rejects them. It does not require positive proof of an interactive Entra sign-in, because no such signal exists on the platform's user record today — the gate's own header states that residual gap rather than papering over it, and notes that an auth path arriving unlabelled would not be structurally caught. "Interactively authenticated" is the design intent, not a property the code can currently verify.

What is read, and what is never read

The reader requests exactly one projection from Microsoft Graph. This is it, verbatim:

id, internetMessageId, conversationId, subject,
receivedDateTime, sentDateTime,
from, sender, replyTo, toRecipients, ccRecipients,
hasAttachments, parentFolderId, webLink

webLink is a URL that opens the original message in Outlook on the web. It is metadata, not content, and it is what lets a briefing point at a message instead of copying one. Opening the link requires the reader's own Exchange access to that mailbox; if they do not have it, the link does not work for them. There is exactly one copy of the correspondence and it stays in Exchange.

The fields that are unreachable by construction

Five keys are forbidden outright:

body, bodyPreview, uniqueBody, attachments, contentBytes

These are not filtered out after retrieval. They are rejected at two independent layers:

• On the request. The projection is validated before the first read of every folder pass. A forbidden key in the $select throws rather than being stripped.
• On the response. Each message is checked for the presence of a forbidden key. If one appears, the message is rejected with a reason naming the field — and the caller escalates that rejection to fail the entire folder pass rather than skipping the message, on the grounds that dropping messages would understate activity, which is the dangerous direction.

Both boundaries are covered by unit tests that run as a gated step of the API deployment pipeline, so a widened projection fails the build rather than shipping quietly.

Why this shape matters for a benefits and audit practice. The mailbox holds plan-participant data. Retrieving message bodies and then redacting them means the data has already left the mailbox and, in any AI-summarized design, would already have left the tenant — and no downstream redaction can undo an egress that has happened. Building so the content is never retrieved is a materially stronger position than building so it is retrieved and filtered.

What is genuinely not obtainable

Some things an admin might expect are not missing by choice; they cannot be had under this boundary.

How access is scoped

The tenant enforces Exchange Online RBAC for Applications in default-deny mode. An application with a Graph token still cannot read a mailbox unless Exchange has been told it may. The chain has three links, and each is meaningless without the others:

Direct members only

MemberOfGroup matches direct members. Nesting a group inside the watch group adds nobody to the scope. To watch ten mailboxes, ten mailbox objects go in this group.

Propagation is 30 minutes to 2 hours

Exchange evaluates MemberOfGroup against a cached view of membership. A mailbox added minutes ago will legitimately test out of scope for 30 minutes to 2 hours. That is expected and does not mean the scope is broken. The setup script tracks whether the current run changed anything and reports this state as NOT RUN rather than as a pass or a failure — see verifying.

Revocation happens in Microsoft 365, not in TATER

Because access is evaluated from group membership, removing the mailbox from the watch group removes it from the scope. The revocation is enforced by Exchange, not by TATER choosing to stop asking. That is the property that makes the window meaningful: when a case ends, take the mailbox out of the group. Expect the same membership-cache timescale to apply to the removal, and confirm it with the negative test rather than assuming it was instant.

Auditing the Entra grants

The setup script performs this audit automatically, using read-only Graph scopes. It inspects two resources, because mailbox data can be reached from either one and they are separate objects in Entra. They play opposite roles for this feature — one holds the permission it needs, the other holds nothing it needs:

The audit records three separate checks, because these are three different questions and one verdict cannot answer them all:

Performing the empirical negative read

This is the step the script cannot do for you, and the only one that distinguishes an application bounded by RBAC for Applications from one that is genuinely tenant-wide. Run it where the application's client secret is available — the setup script never handles one.

$body = @{
    client_id     = '<application (client) id>'
    client_secret = '<client secret>'
    scope         = 'https://graph.microsoft.com/.default'
    grant_type    = 'client_credentials'
}
$tok = (Invoke-RestMethod -Method POST -Body $body `
    -Uri "https://login.microsoftonline.com/<tenant id>/oauth2/v2.0/token").access_token

# NEGATIVE READ - a mailbox that is NOT in the watch group.
try {
    $r = Invoke-WebRequest -Method GET -Headers @{ Authorization = "Bearer $tok" } `
        -Uri "https://graph.microsoft.com/v1.0/users/<mailbox NOT in the group>/mailFolders/inbox"
    "UNBOUNDED - HTTP $($r.StatusCode). This app can read outside the watch group."
} catch {
    $code = $_.Exception.Response.StatusCode.value__
    "HTTP $code : $($_.ErrorDetails.Message)"   # expect 403 containing [RAOP]
}

Then run the same request against a mailbox that is in the watch group, and expect 200. A 403 on both proves nothing about boundedness — that is what a missing grant looks like, not what a fence does.

To inspect the grants by hand:

# The enterprise application (service principal) object id
az ad sp show --id <application (client) id> --query id -o tsv

# Its application-permission grants, across every resource
az rest --method GET --uri "https://graph.microsoft.com/v1.0/servicePrincipals/<that id>/appRoleAssignments"

Each assignment carries a resourceDisplayName and an appRoleId GUID — not a role name. Pick out every assignment whose resource is one of the two above, then resolve the GUID against that resource's own appRoles collection to learn what it actually grants:

# Role names published by Office 365 Exchange Online
az rest --method GET --uri "https://graph.microsoft.com/v1.0/servicePrincipals(appId='00000002-0000-0ff1-ce00-000000000000')" `
    --query "appRoles[].{id:id, value:value}"

An assignment you cannot resolve to a role name is not a clean result. Treat it as unproven and resolve it before concluding the application is bounded.

Remove-MgServicePrincipalAppRoleAssignment `
    -ServicePrincipalId <enterprise application object id> `
    -AppRoleAssignmentId <assignment id>

Running the setup script

Get the script

The script is published at a public URL — no TATER repository access required. This is the path to hand to a client or tenant admin. From a PowerShell 7 session on a workstation that can sign in to the target tenant:

irm https://www.tatersecurity.com/Setup-TATERDepartureWatch.ps1 -OutFile .\Setup-TATERDepartureWatch.ps1

The script contains no secrets. It provisions and verifies objects in the tenant the runner signs into, and prints its results to that runner's console. Alternatives:

• Direct download in a browser: https://www.tatersecurity.com/Setup-TATERDepartureWatch.ps1
• From the repository root, if you have TATER-Security access: Setup-TATERDepartureWatch.ps1

Read it before you run it. It is a script that grants an application read access to a person's mailbox, and it is written to be read.

Prerequisites

• PowerShell 7. The Microsoft Graph PowerShell modules no longer support Windows PowerShell 5.1.
• Modules: ExchangeOnlineManagement and Microsoft.Graph.Applications. The script installs them for the current user if they are missing.
• An existing application. The script does not create an app registration. Departure Watch reuses the organization's existing per-tenant credentials application — the same one already used for Graph compliance scanning — so that one consent decision covers one identity instead of two. You pass its application (client) id.
• An enterprise application for it in this tenant. If the service principal does not exist, the script stops and tells you how to create it rather than creating it itself: a script that provisions the identity it then grants mailbox read access to is not a control.
• A Microsoft Graph Mail.Read application permission on that app, admin-consented. This is required and the script does not grant it — it audits for it and FAILs if it is missing. Without it the client-credentials token carries no mail scope, Graph rejects every read before Exchange RBAC is consulted, and everything else on this page accomplishes nothing. Grant Mail.Read only; not Mail.ReadWrite, not Mail.Send.
• A mailbox that is not in the watch group, licensed and real, to use as the negative test subject.

Required roles

• Exchange Administrator — for the management scope and the role assignment.
• Global Reader or Application Administrator — to read the application's Entra permission grants for the audit. Only read-only Graph scopes are requested (Application.Read.All, Directory.Read.All).
• Or Global Administrator, which has both.

Parameters

The command

.\Setup-TATERDepartureWatch.ps1 -AppId <application (client) id> `
    -Mailbox departing.manager@contoso.com `
    -NegativeTestMailbox unrelated.person@contoso.com

Preview it first if you prefer:

.\Setup-TATERDepartureWatch.ps1 -AppId <application (client) id> `
    -Mailbox departing.manager@contoso.com -WhatIf

The script is idempotent. Re-running changes nothing that already matches and re-runs every verification check.

What it does, in order

1. Verifies or installs the two required modules.
2. Connects to Microsoft Graph with read-only scopes (device code by default).
3. Resolves the enterprise application object id for your -AppId and prints it, labelled as such. Stops if none exists.
4. Connects to Exchange Online.
5. Runs Enable-OrganizationCustomization if the organization is dehydrated, polling up to five minutes.
6. Finds or creates the watch group.
7. Optionally adds -Mailbox to it, idempotently.
8. Resolves the group's distinguished name and finds or creates the management scope.
9. Registers the Exchange service principal and assigns Application Mail.Read, scoped.
10. Runs the positive authorization test.
11. Runs the negative authorization test.
12. Audits the application's Entra grants on both Microsoft Graph and Office 365 Exchange Online: confirms the required Graph mail-read grant is present, and flags anything beyond read.
13. Prints the commands for the empirical negative read it cannot perform itself, and records that check as NOT RUN.
14. Prints a results table, then a block stating plainly that nothing is being monitored, and exits with a code that reflects the worst result in the table.

Connect-ExchangeOnline
Test-ServicePrincipalAuthorization -Identity <application (client) id> `
    -Resource someone@yourdomain.com   # expect InScope False

What correct output looks like

The script ends with a results table. Every check resolves to exactly one of PASS, FAIL, or NOT RUN; no code path lets a skipped check render as a pass, and a check that never got recorded at all is materialised as NOT RUN so it cannot quietly shrink the table. The fourteen checks, in the order they are recorded, are:

1. Enterprise application resolved
2. Exchange organization customization
3. Watch group present
4. Watch group membership is gated
5. Mailbox added to watch group
6. Management scope bound to the group
7. Exchange service principal registered
8. Role 'Application Mail.Read' scoped to '<your scope name>'
9. App's other Exchange role assignments
10. POSITIVE test (access works)
11. NEGATIVE test (access is BOUNDED)
12. Graph mail-read grant present (REQUIRED)
13. Entra grants are least privilege
14. Entra grant boundedness (empirical read)

These are the check names verbatim, so they can be searched for or quoted in a support request. Only check 8 carries values that vary per run — it interpolates the role and your -ScopeName.

Checks 12–14 replaced a single check named "Entra mailbox-access grant audit" in earlier versions. That check failed on the presence of a Graph mail grant, which is the permission the feature requires; if you are comparing against an older run or an older copy of this page, that verdict was inverted.

The table is followed by the tenant, application id and name, enterprise application object id, group name, scope name, and the assigned role, then by a block headed EXCHANGE SIDE ONLY — nothing is being monitored.

A NOT RUN is not one thing — read which check it is on

A first run commonly comes back with several NOT RUNs, and the ones an admin is most likely to see mean completely different things. Do not treat them as the same result.

So a given PASS count is not a single expected shape. Thirteen PASS with only check 14 NOT RUN is the clean result. Twelve PASS with the POSITIVE test also pending propagation is a normal first run. Twelve PASS with the NEGATIVE test NOT RUN means the Exchange scope has not been shown to bound anything — the script prints that conclusion explicitly rather than leaving the count to be read as a near-pass. This is why the exit code and the status column, not the count, are what to judge a run by.

Exit codes

The script sets a meaningful exit code so a scheduled or piped run can be judged without reading the table:

In PowerShell, read it from $LASTEXITCODE after the call. Gate automation on -le 1, and treat the empirical negative read as a separate, deliberate step rather than something a script can discharge.

The Exchange Online and Microsoft Graph sessions are deliberately left open when the script finishes, so that every remediation command it printed can be pasted directly into the same session. Disconnect when you are done:

Disconnect-ExchangeOnline -Confirm:$false
Disconnect-MgGraph

Verifying it worked

Come back in 30 minutes to 2 hours and re-run in verify mode. This changes nothing in your tenant and re-runs every check:

.\Setup-TATERDepartureWatch.ps1 -AppId <application (client) id> `
    -NegativeTestMailbox unrelated.person@contoso.com -VerifyOnly

Telling "not propagated yet" from "misconfigured"

This distinction is implemented in the script rather than left to the reader, and it is worth understanding because the two states look identical in the raw cmdlet output.

If the negative test reports InScope True

There is no effective scoping. Do not proceed on the assumption that Departure Watch is bounded. The likely causes, in the order worth checking:

1. A second management role assignment on the same application with no CustomResourceScope, or one scoped to something far wider.
2. A mailbox-reaching grant on the Office 365 Exchange Online resource — full_access_as_app, EWS.*, IMAP.*, POP.*. Nothing in this feature needs any of them.
3. The tenant does not enforce RBAC for Applications at all. In that case no Exchange management scope bounds anything, and the Graph mail grant is effectively tenant-wide. The empirical negative read is what tells you this.

You do not have to hunt for cause 1 by hand — the script checks it. App's other Exchange role assignments (check 9) enumerates every assignment on the application and FAILs on any mailbox-data role scoped outside your management scope. Run the cmdlet below only to see the detail, or if that check itself reported NOT RUN:

Get-ManagementRoleAssignment -App <application (client) id> |
    Format-List Name, Role, CustomResourceScope, RecipientWriteScope

Doing it by hand if the automation fails

This is the sequence the script performs, and the sequence it prints if its Exchange RBAC step throws. Run it as an Exchange Administrator, then re-run the script — it is idempotent and will verify what you did.

Connect-ExchangeOnline

# One-time; skip if the organization is already customized
Enable-OrganizationCustomization

# The group's DISTINGUISHED NAME is what the scope filter takes
$dn = (Get-Group -Identity 'sg_tater_departure_watch').DistinguishedName

New-ServicePrincipal -AppId <application (client) id> `
    -ObjectId <ENTERPRISE APPLICATION object id> -DisplayName '<app display name>'

New-ManagementScope -Name 'TATER-DepartureWatch' `
    -RecipientRestrictionFilter "MemberOfGroup -eq '$dn'"

New-ManagementRoleAssignment -App <application (client) id> `
    -Role 'Application Mail.Read' -CustomResourceScope 'TATER-DepartureWatch'

Then both tests, which are not optional:

# POSITIVE — a mailbox that IS in the group. Expect InScope True.
Test-ServicePrincipalAuthorization -Identity <application (client) id> `
    -Resource departing.manager@contoso.com

# NEGATIVE — a mailbox that is NOT in the group. Expect InScope False.
Test-ServicePrincipalAuthorization -Identity <application (client) id> `
    -Resource unrelated.person@contoso.com

Troubleshooting

Retention, and what leaves the tenant

What leaves, and where it goes

Running the setup script transmits nothing to TATER. It reads Entra and Exchange configuration from your own tenant using your own administrator sign-in, writes the group, scope, and role assignment, and reads no mailbox content. Provisioning is entirely a tenant-side operation.

Once a case is active, collected metadata is stored by TATER — not only in your Microsoft 365 tenant. Message metadata, security signals, and generated briefings are written to Cosmos DB in TATER Security's Azure subscription, partitioned by tenant. That is a real transfer of data about a named individual's correspondence to a vendor, and it should be stated plainly to whoever signs the attestation rather than left to be inferred. What is not transferred is message content: no body, no preview, no attachment contents, no attachment file names — those are unreachable by construction, as described above.

TATER itself sends nothing to an AI model provider in either briefing mode. No timer, endpoint or MCP tool in TATER submits mail metadata to a model, and a case in the default raw mode involves no model at all.

A case in agent mode is different, and the difference is yours rather than TATER's. That mode is written to be driven by an external routine you run: it reads the collected metadata — subject lines, counterparties, timestamps — through TATER's read tools, submits it to whichever model that routine uses in order to write the summary, and posts the resulting text back. So the transmission is real, it carries client-correspondence metadata about a named individual, and it happens under your agreement with that model provider, not TATER's. Whoever signs the attestation should be told this explicitly if you intend to run agent mode; leaving it to be inferred from "TATER sends nothing" would be true about TATER and misleading about the firm.

Designed retention limits

The case model carries per-case retention settings with hard maximums that cannot be raised:

A value above the maximum is silently clamped to the maximum rather than rejected, so asking for 36,500 days quietly yields the ceiling. Read back what was stored rather than assuming the request was honoured. The same applies to the recipient list (25) and the client, competitor, and personal-webmail domain lists.

These limits are now enforced by a daily retention sweep (07:10 UTC) across the three stores — metadata, signals, and briefings. Two behaviours are worth knowing because both invert a reasonable guess:

• An unset retention means the platform ceiling, not "keep forever." A case that never specified a retention is swept at the maximum, and so is an orphaned row whose case no longer exists. The dangerous reading — absent means unbounded — is the one the sweep deliberately does not take.
• The destructive step is off by default. Deletion runs only when the app setting DEPARTURE_WATCH_PURGE_ENFORCE is exactly true. Until it is set, the sweep still runs and reports what it would delete, but deletes nothing. If your firm's answer on retention is a commitment rather than an aspiration, confirm with TATER Security that this setting is on — a limit that is computed and reported is not a limit that is applied.

Deletions are capped at 200 rows per store per run, so a large backlog drains over several nights rather than in one spike.

The optional AI-summarised briefing mode

The design has two briefing modes on each case:

• raw — deterministic. Threads, tiers, and signals are rendered as-is. Nothing is sent to a model provider. This is also the fallback whenever the other mode fails.
• agent — a routine reads the staged evidence and writes the narrative. In this mode, message metadata and derived fields (subject, dates, direction, counterparty domain, days silent) would be sent to the AI model provider to compose the text. No message body would be sent, because none is ever retrieved.

In both modes the design has TATER perform delivery and enforce the recipient list. The model authors content; it never gains the ability to choose an audience. The monitored mailbox is attacker-influenced by construction — anyone can email the person under watch — so its contents are treated as untrusted input to whatever summarises them.

How a reader reaches a source message

A briefing links to the original message in Outlook rather than copying it. That is a deliberate choice: copying source mail into a second system would create a second persistent copy of client correspondence, including plan-participant data. Linking keeps one copy, in Exchange. Opening a link requires the reader's own access to that mailbox, granted and revoked through normal Exchange permissions, so a reader without access gets a link that does not open for them.

Who can open the briefing page, and who only gets the email

Two separate permissions decide what a recipient actually sees, and they are easy to conflate because being on the recipient list looks like access. Being emailed a briefing does not grant the ability to open it.

• To open the briefing page in TATER Ops — the reader needs the Auditor role or higher in that organization, and a TATER Security product licence. The page reads counterparties and subject lines, and every read is written to the audit log as exactly that, so it is not a Viewer-level surface.
• To open a source message from the page — the reader needs their own access to the monitored mailbox in Exchange. That is a separate grant, made and revoked in Microsoft 365, and it is described below.

A Viewer-level recipient receives the daily email and gets a "User does not have required role" error on the page. The email is still useful to them — it carries the counts, the integrity warnings, the checks that could not run, and the subject lines of the threads waiting on someone — but the per-message detail is closed to them. Check the roles of everyone you name on a case before you rely on them being able to follow the link, because nothing in the email says who it will work for.

Granting the Exchange access without mounting the mailbox in anyone's Outlook. Full Access assigned directly to a user is auto-mapped: Exchange stamps msExchDelegateListLink and the mailbox appears in that person's Outlook profile whether they want it or not. Assigning the same Full Access to a mail-enabled security group does not auto-map, because that attribute is only stamped for direct user assignments — so group members can open a link without the mailbox being added to their profile. It must be mail-enabled; Add-MailboxPermission needs a recipient object and will not accept a plain Entra security group. A direct assignment with -AutoMapping:$false achieves the same thing for one named person. Expect the usual Exchange delay before a new grant takes effect.

Changing who receives the briefing

The recipient list can be edited on a live case, without stopping collection. Open TATER Ops → Departure Watch, find the case, and use the Recipients button on its card. Adding and removing in the same edit is fine — the change is sent as one operation and the resulting list is validated as a whole.

This is deliberately separate from the case editor. That editor changes scope — the window, the folders, the mailbox — and is refused outright while a case is active, because changing what is being collected midway through a collection is not safe. Changing who reads the briefing moves nothing about the collection, so it does not require a deactivate.

• Adding someone needs the Admin role and a written rationale, which is recorded on the case. It also requires an interactively signed-in human — an API key or automation cannot widen the audience for a named person's mail activity.
• Removing someone needs Admin, or that person removing themselves. A recipient can always take themselves off a briefing without asking an administrator.
• Every recipient must already be an organization member or a People record here. A mistyped address that happens to be deliverable would send the briefing to a stranger, so unknown addresses are refused by name rather than dropped silently.
• The subject of the case can never be a recipient. Adding them is refused, on the case's mailbox address and on every alias it resolves to. Sending someone a surveillance briefing about themselves discloses the monitoring to its subject and hands them their colleagues' client correspondence.
• The list cannot be emptied by an edit. A case that still collects but notifies nobody is monitoring with no reader. If monitoring should stop, deactivate the case — that is a different decision and it is recorded as one.

Every addition and removal is written to the audit log with the addresses involved, who made the change, when, and why — because "who could see this person's mail activity, and from when" is the question an auditor actually asks.

The machine-authored summary

A case set to agent report mode can carry a short written summary at the top of its briefing, interpreting the figures rather than restating them. The summary is written by an external routine through the stage_departure_watch_narrative MCP tool; TATER stores it, renders it, and delivers it.

The routine authors content and never chooses an audience. It cannot add a recipient, change the window, authorize a case or activate one — those are refused for any automated caller. The briefing still goes to the case's own recipient list, enforced by the server.

• It is labelled machine-authored wherever it appears, in the block itself rather than in a footnote, and it names the principal that wrote it and when. A reader deciding what to do about a colleague is entitled to know which sentences were generated.
• It is written for a specific date. A summary staged for a different date is ignored rather than attached, so a routine that has not run for three days cannot put Monday's analysis on Thursday's evidence.
• The briefing is built at 13:00 UTC (09:00 US Eastern in summer, 08:00 in winter). The routine must finish before that; anything staged afterwards applies to the next briefing.
• If no summary was staged, the briefing still goes out and says plainly that the narrative was requested and did not arrive, with the reason. A missing analysis must never read like a quiet day.
• You can read it before the recipients do. Open the briefing page in Ops and the staged summary is shown at the top, marked with the date it is for.

The summary is stored and rendered as plain text and escaped before it reaches the email. It is the one part of a briefing TATER did not generate, written by a model over mail that anyone able to write to the monitored mailbox has influenced, so it is never trusted as markup.

Where to get help, and related pages

• Email-to-Ticket Setup — the sibling case for the same Exchange RBAC-for-Applications mechanism, with the read/write variant of the role.
• Azure Registered Apps — the per-tenant credentials application this feature reuses.
• Staff Roster & Account Classification — who counts as staff, and how departures are recorded.
• Help Center home

The setup script is published at https://www.tatersecurity.com/Setup-TATERDepartureWatch.ps1 — see get the script for the download one-liner. Its comment-based help (Get-Help .\Setup-TATERDepartureWatch.ps1 -Full) covers what the script does, what it explicitly does not do, and the current state of the TATER side, plus worked examples. Note that its help block documents seven of the ten parameters — -GroupPrimarySmtpAddress, -ServicePrincipalObjectId and -UseBrowserAuth are described in the code but carry no help entry, so use the table above for those.

If a check on this page reports FAIL and the fix here does not resolve it, raise it with TATER Security with the full results table from the script — the check names and their detail lines are designed to be pasted verbatim.