NHI breach prevention 30 and 90 day plan template: Ten actions with owners, evidence and dates

Most non-human identity breaches start through doors that were already known to be open: a key in code, an unowned OAuth grant, an agent with production write access, a password-only login to a data platform. NHI Mgmt Group, The State of NHI & AI Agent Breach Report 2026 (October 2026) analysed more than 200 breaches and ends with a ten-action plan: five actions for the first 30 days to close the open doors and five for the next 90 days to make it hard to happen again. This template turns that plan into a fill-in document with an owner, a completion test, evidence and a due date for every action, plus the breach that shows why it matters. It is for security, platform and IAM leads who need a short, defensible plan after a breach in their sector, an audit finding or a board question. If you are starting an NHI programme from nothing, use it alongside the NHI 30/60/90 day plan template for a new programme, which covers mandate and governance.

How to use this template

• Replace every value in square brackets: [Organisation], [Plan owner], [Sponsor], [date], [team], [system].
• Keep the ten actions: they come from the report's plan. You may split an action into sub-tasks but do not drop one without recording an exception in section 7.
• Name a person, not a team, as owner: the owner is accountable for the completion test, even when another team does the work.
• Evidence is what you would show an auditor: a report export, a configuration screenshot, a closed ticket set, a signed exception. If you cannot name it, the action is not specific enough.
• All numbers in this template are illustrative placeholders: counts, targets and dates must come from your own baseline. The only figures quoted from the report are attributed to it.
• Review weekly: update status in sections 4 and 5 every week and report to the sponsor at day 30 and day 120.

1. Purpose and scope

The identity list mirrors the identity types the report classifies. Its finding that 44% of the breaches it analysed (99) began with a leaked, stolen or weak credential is the reason the first 30 days focus on credentials already exposed.

2. Roles and sign-off

3. Baseline

Record the starting position on day 0. The values below are illustrative examples of the format, not benchmarks.

4. First 30 days: close the open doors

Why each action, and what good looks like

• 30.1 Secrets: the xAI API key leak stayed live for about 59 days after automated scanning emailed the developer. Route findings to an owned queue and revoke at the issuer; deleting the file is not revocation. Rotate what appears in tickets too: after the Salesloft Drift breach, Cloudflare rotated 104 API tokens found in its support cases. See the Developer Secret Scanning Triage guide.
• 30.2 OAuth and SaaS: in the Salesloft Drift case one vendor's stored tokens reached Salesforce data across many tenants. For each grant record owner, scopes, last use and expiry. See the SaaS and OAuth App Governance Guide.
• 30.3 AI inventory: the Moltbook database exposure leaked about 1.5 million agent API keys, and the OpenCode Console breach showed that keys held by tools must be revoked at the provider. Include keys entered into IDE plugins, gateways and hosted tools. See the LLMjacking Guide.
• 30.4 MFA: the Snowflake customer breaches used infostealer credentials on password-only accounts, some unrotated for years, with no network allow-lists. Prefer phishing-resistant methods for admins; see the Phishing-Resistant MFA Guide.
• 30.5 Agent production access: in the Replit AI agent database deletion the code freeze was only a chat instruction, and the agent had direct production write access. Enforce it in permissions, not prompts.

5. Next 90 days: make it hard to happen again

Why each action, and what good looks like

• 90.1 Short-lived credentials: in the second Shai-Hulud npm worm wave, stolen publishing tokens were reused to republish victims' packages; npm later revoked classic tokens and capped new write tokens at 90 days. See the npm Trusted Publishing and Provenance Guide and the GitHub Actions OIDC Federation Hardening Guide.
• 90.2 Scope and metadata: one identity per environment limits what a single compromised host or pipeline can reach. For metadata settings see the Cloud Instance Metadata Services Compared Guide.
• 90.3 Baselines and automatic revocation: the Trivy supply chain attack succeeded a second time because a rotation "wasn't atomic" and a bot account stayed valid. The completion test must include proof that every credential in scope was revoked, not a list of the ones that were.
• 90.4 Agent guardrails: the kill switch counts only if it has been tested against a running agent. See the AI Agent Kill Switch and Containment Guide.
• 90.5 Tier-zero vendors: in the BeyondTrust breach a stolen infrastructure API key could reset passwords on customer instances, which led to a major incident at the US Treasury. Ask each vendor how keys to your environment are stored, who can use them and how quickly they can be revoked. See the Third-Party Risk Management Guide.

6. Evidence register

Keep evidence for at least [retention period] so the next review can compare against it.

7. Exceptions, risks and dependencies

Every exception has an expiry date. An exception without one is a decision not to fix.

8. Metrics and reporting

Day-30 and day-120 reports to the sponsor contain: actions complete with evidence links, actions late with reason and new date, open exceptions, and the metric table above.

9. Approval

Implementation guidance

1. Start with the scan, not the inventory debate: action 30.1 produces findings that make every other action easier to fund. Run it in week one even if the scanner is basic.
2. Rotate safely: create the replacement credential, update consumers, confirm traffic on the new credential, then revoke the old one at the issuer. Keep a rollback path for the first hours, and record each rotation as evidence.
3. Pilot before enforcing: roll MFA (30.4) and agent permission changes (30.5) out to one team or platform first, in report-only mode where the platform offers it, then enforce.
4. Use the report's route-to-control mapping to prioritise: the report's table of what would have stopped the breaches puts supply chain (51 breaches), leaked secrets (48) and stolen credentials (47) at the top. Actions 90.1, 30.1 and 90.3 carry their controls, so protect those first if time runs short.
5. Small organisations: one person may own several actions. Keep the ten actions but shrink scope to the systems that hold customer data or ship code.
6. Large organisations: run actions 30.1 to 30.5 per business unit with a central plan owner, and report one combined metric table.
7. Map to frameworks for audit: NIST CSF 2.0 PR.AA-01 (credentials managed), GV.SC-07 (supplier risk), RS.MI-02 (incidents eradicated); NIST SP 800-53 Rev. 5 IA-5, AC-2, AC-6, CM-8 and SR-6.

Standards and references

• NIST: Cybersecurity Framework (CSF) 2.0
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• Microsoft Security: Advice for incident responders on recovery from systemic identity compromises
• OpenAI: Best practices for API key safety
• Google Cloud: Manage API keys
• NHI Mgmt Group: The State of NHI & AI Agent Breach Report 2026 (October 2026)

Related NHI Mgmt Group resources: NHI 30/60/90 day plan template for a new programme · NHI Programme Roadmap · LLMjacking Response Playbook · Non-Human Identity (NHI) Guide