Predictika · Autonomous email-security remediation · AI agents
An AI agent that remediates email threats can remove a campaign from thousands of mailboxes, end sessions, force password resets, block sign-ins and suspend or cut off other AI agents. Before each action runs, the agent sends it to Predictika, which checks it against the customer's own response policy and the state of the target, and returns a verdict (allow, needs approval or block), every reason, and the same answer on every call.
Source and independence. The kinds of action come from public descriptions of autonomous remediation, such as removing malicious messages and campaigns, ending sessions and forcing credential resets (AI-driven auto-remediation) and suspending an agent run or revoking its access (AI agent security). The tool names here are descriptive, not any vendor's API names, and the rules are example policies of a fictional customer, not any vendor's rules. The accounts, agents and campaigns are that customer's inventory, supplied by the customer's own system. No vendor is involved in this demonstration or has endorsed it.
This validator handles any call to these actions against this inventory — not just the scenarios shown below.
Not covered: the detection itself, any vendor's own controls (which remain worth using alongside), real inventory feeds, and actions not listed above.
8 scenarios in 4 groups · each group runs from the agent’s first attempt to the outcome · click one to switch
Proposing agent: AI remediation agent (scripted)
Before sending, the agent must call Recorded run
What this means
Our assessment of what a detection-confidence threshold or an allow/deny list does with the same cases. It is a general judgment about fit, not a claim about any vendor's product, and those controls remain worth using alongside the validator.
| What the validator caught | Threshold or list alone | Predictika |
|---|---|---|
| A removal that reaches mail on legal hold, though the detection is confident | Only with workarounds A confidence threshold knows how sure the detection is, not which mailboxes are under hold. | The state of every mailbox is looked up on every call and the reason is returned. |
| The agent states 12 mailboxes and the campaign reaches 4,180 | Only with workarounds A threshold or list never sees the count the agent expects. | The stated scope is compared with the real one. |
| Ending sessions aimed at an AI agent instead of suspending its run | Only with workarounds An allow or deny list says the action is permitted; it does not say it is the wrong kind for this target. | Each action is checked against the kind of target. |
| Hold for a person: a large removal, an executive, quarter-close | Only with workarounds A list allows or denies. Holding with the reason is a third outcome it does not give. | Allow, needs approval and block are three verdicts of the same check. |
| Every reason in one answer | Only with care A denial typically stops at the first refusal. | All findings come back together, whatever order the choices arrived in. |
These are the example customer policies at work, recorded from the test cases. Every policy is checked on every call, in any order the choices arrive; one problem never hides another. A block stops the action; an approval holds it for a person.
| 1 | Block: the agent stated 12 mailboxes, but cmp_invoice_wave reaches 4,180. |
| 2 | Approval: removing cmp_invoice_wave from 4,180 mailboxes is more than the 500-mailbox limit for an autonomous removal; a person must approve. |
| 3 | Block: removing mail would touch 3 mailboxes under legal hold; the agent role may not delete mail that is on hold. |
| 4 | Block: detection confidence is 48, below the 60 minimum for an action that removes mail, resets a credential or blocks access. |
| 5 | Approval: mail in cmp_vendor_spoof comes from a vendor with an open invoice; removing it needs a person to approve. |
| 6 | Block: the remediate_campaign tool call is missing the number of mailboxes the agent expects it to reach. |
| 7 | Block: the remediate_campaign tool acts on a detected campaign; m_okafor is a user account. |
| 8 | Block: detection confidence is 52, below the 60 minimum for an action that removes mail, resets a credential or blocks access. |
| 9 | Approval: detection confidence is 74, between 60 and 84; a person must confirm before this action runs. |
| 10 | Approval: r_whitfield is an executive; locking or resetting an executive account needs a person to approve. |
| 11 | Approval: r_whitfield is in a critical business window (quarter-close); a person must approve any lockout. |
| 12 | Approval: c_dalton is an executive; locking or resetting an executive account needs a person to approve. |
| 13 | Approval: t_nguyen has no MFA method registered, so the user could not recover after a reset; a person must approve. |
| 14 | Approval: sa_itadmin holds an administrator role; locking or resetting it needs a person to approve. |
| 15 | Block: bg_emergency01 is a break-glass account; the agent role may never lock it or end its sessions. |
| 16 | Block: svc_erp_sync is a service account that integrations depend on; the agent role may not reset it or block its sign-in. |
| 17 | Block: removing mail would touch 1 mailbox under legal hold; the agent role may not delete mail that is on hold. |
| 18 | Approval: production payroll depends on agt_payroll_recon; revoking its credential needs a person to approve. |
| 19 | Block: detection confidence is 55, below the 60 minimum for an action that removes mail, resets a credential or blocks access. |
| 20 | Block: the terminate_sessions tool acts on a user account; agt_research_bot is an AI agent. |
| 21 | Block: the revoke_agent_credential tool acts on an AI agent; m_okafor is a user account. |