| name | contact-template |
| description | Contact / communications plan generator โ primary operator, escalation chain, abort signal recipient, external SOC endpoint, blackout windows. |
| allowed-tools | Read Write Edit |
| metadata | {"subdomain":"planning","when_to_use":"create contact plan, communications plan, escalation chain, operator contacts, SOC notification, blackout window","tags":"contact, communications, escalation, soc, deconfliction, blackout","mitre_attack":[]} |
Contact / Communications Plan Generator
Slim version of the traditional white-cell/blue-cell/red-cell matrix tailored for autonomous-AI engagements. The agent itself is the "red cell"; only humans staff the white / blue cells. Full multi-cell rosters belong in an external comms doc, not here.
When to Use
- After RoE is written (escalation_contacts seed the primary operator)
- User says "create contact plan", "communications", "who do we notify", "escalation chain"
Workflow
Step 1: Identify Primary Operator
This is the single human responsible for the engagement on the operator side. Resolve from the RoE escalation_contacts:
- If exactly one contact has the role "engagement lead" or "primary operator" โ use that
- Otherwise ask via
ask_user_question who the primary is
Fields: name, role, channel (resolvable โ Signal, email, PagerDuty service-key, Slack channel), availability
Step 2: Build Escalation Chain
Ordered list of fallbacks. The agent walks this chain when the primary is unreachable past the abort plan's response window (default 15 minutes).
Typical chain:
- Primary operator
- Engagement owner (lead pentester / red team manager)
- Client SOC lead (only contacted on deconfliction events)
Step 3: Abort Signal Recipient
The contact paged on EMERGENCY-severity abort triggers. Usually = primary operator but can differ (e.g., engagements with a dedicated on-call rotation).
Optional โ leave None only if the engagement explicitly opts out of EMERGENCY paging (rare).
Step 4: External SOC Endpoint (Optional)
If the client has an integration endpoint for deconfliction (HTTP webhook, Splunk HEC token, internal ticketing API), record the URL here. The agent POSTs before active scanning begins so the SOC can pre-allowlist red-team activity.
Empty = no external integration; deconfliction happens via the primary operator only.
Step 5: Blackout Windows
ISO 8601 datetime ranges during which the agent must not run active operations (passive recon โ DNS, public WHOIS โ is usually OK). Format: "<start>/<duration-or-end>", e.g.:
"2026-05-22T22:00:00+09:00/PT8H" โ 8 hours starting May 22 22:00 KST
"2026-05-25T00:00:00Z/2026-05-26T00:00:00Z" โ full day UTC
Common blackouts:
- Production change-management freeze windows
- Client business-critical events (earnings, product launch)
- Holidays / weekends (if RoE forbids weekend testing)
Validation Checklist
Before writing plan/contact.json:
Anti-patterns
- Listing the primary operator twice (once as
primary_operator, once in chain) โ redundant
- Using non-resolvable channels ("call John") โ the agent can't dial; require a concrete
tel: / signal: / mailto: style
- Blackout windows without timezone โ agent will misinterpret in UTC
Output
Write to plan/contact.json validating against atlas.core.schemas.ContactPlan.