Concern is not readiness. Readiness means a named team can detect a scenario, make a decision, contain it and show what happened.
Darktrace's State of AI Cybersecurity 2026 survey gives a useful starting point. It covered more than 1,500 cybersecurity professionals. Darktrace reports that 73% of respondents said AI-powered threats were having a significant impact on their organization. It also reports that 46% felt inadequately prepared for the current threat landscape.
These are perceptions reported by surveyed professionals. They are not a global incident rate, and they do not prove that a specific security team is ready or unready.
Across security consulting and operations work involving more than 40 organizations, I learned to test readiness through ownership and evidence. Who knows which AI systems exist? Which logs show an action chain? Who can revoke a token? Who decides whether to disable a business process?
Define the gap in operational terms
A readiness gap exists when one of these statements is true:
- an AI service or agent has no owner;
- the team cannot list the data and tools it can reach;
- security logs stop before the model or tool decision;
- an alert has no matching containment procedure;
- a procedure depends on access the responder does not have;
- nobody has authority to stop the workflow;
- recovery has never been tested.
That definition is more useful than asking whether a team "uses AI security." It produces a list of failures that can be assigned and closed.
1. Inventory the exposure
A vendor list is not an AI inventory. One service can contain several agents, data connectors and identities with different risk.
For each AI system, record:
| Field | Question |
|---|---|
| Owner and purpose | Who accepts the risk, and which job requires the system? |
| Deployment | SaaS, endpoint, cloud workload or internal service? |
| Model and provider | Which external or internal dependency processes the request? |
| Connected tools | Can it read, write, send, deploy, delete or transact? |
| Data classes | Which confidential, personal or regulated data can it access? |
| Identity | Which user, workload, OAuth client or API key authorizes action? |
| Approval | Which high-impact actions require a person? |
| Telemetry | Which logs capture request, policy, tool call and outcome? |
| Revocation | Who can stop it, and has that path been tested? |
| Review date | When does the approval expire? |
Include sanctioned systems and shadow use discovered through cloud application, identity, endpoint and network telemetry. The inventory is complete enough when the team can select a high-risk agent and trace its authority to an owner and revocation method.
2. Collect telemetry across the action chain
A model response is one part of an incident. The security record needs the chain around it.
Collect or correlate:
- user and workload authentication;
- OAuth consent, token issuance and scope changes;
- AI service access and data-loss prevention events;
- agent and model request identifiers;
- tool calls and target resources;
- approval requests and policy decisions;
- endpoint and network actions;
- data access, download and sharing events;
- response, error and rollback state.
Do not centralize raw secrets or sensitive prompts without a defined need and retention policy. Stable IDs and redacted policy evidence are often enough to join the event chain.
Known indicators still matter. Add behavior-focused detections for the parts that remain observable when an attacker changes wording or payload structure:
- a read-only agent attempting a write;
- a new tool or data source;
- unusual token use or consent;
- a sudden increase in records accessed;
- an external destination not seen for that workflow;
- repeated denied actions followed by a successful alternative path.
Behavioral signals reveal authority and consequence that signatures can miss. Use both.
3. Write playbooks for concrete scenarios
"AI incident" is too broad for one useful playbook. Start with four scenarios that exercise different controls.
Sensitive data sent to an external AI service
Confirm the data, user, service and retention terms. Revoke the relevant session or grant if needed. Preserve DLP and access evidence. Assign privacy and notification decisions.
Prompt injection influences a tool-using agent
Identify the content source, agent identity, attempted tool call and policy decision. Disable the affected connector or tool authority. Review other tasks that consumed the same content. Restore only after the input and authorization boundary is corrected.
Agent credential misuse
Revoke the token or workload identity, inspect downstream calls, rotate related secrets and check for persistence through refresh tokens or shared credentials. Confirm the old path fails.
Deepfake or AI-assisted impersonation
Stop the requested business action, verify the person through an independent channel and preserve the message, call or video evidence. The playbook should connect security, finance, HR or executive protection according to the target process.
Each playbook needs entry criteria, evidence sources, containment authority, legal or privacy decision points, communications ownership and recovery checks.
4. Run a table-top exercise that can fail
A useful exercise should expose missing access and unclear decisions. Do not let the facilitator supply every answer.
Give the team a scenario and the telemetry it would actually have. Then ask:
- Which alert or report starts the process?
- Who is incident lead?
- Which identity, data and tool paths are in scope?
- What can be disabled without destroying evidence?
- Who has authority to disable it?
- Which facts trigger privacy, legal or customer communication?
- What proves containment?
- What must be true before recovery?
Capture time to first defensible decision, missing logs, unavailable permissions, manual handoffs and unresolved ownership. Those findings are the readiness backlog.
5. Assign ownership before buying another tool
Tooling can improve visibility or response. It cannot decide who accepts business impact when an agent is disabled.
At minimum, name owners for:
- AI service and business purpose;
- identity and credential lifecycle;
- data classification and DLP policy;
- detection and incident command;
- legal, privacy and communications decisions;
- restoration and post-incident review.
A person may hold several roles in a small organization. The requirement is explicit authority, not a large committee.
A 30-day starting plan
Week 1: inventory
List AI services, agents, connectors and identities. Select the five workflows with the broadest write authority or most sensitive data.
Week 2: trace
For each selected workflow, map authentication, data access, tool calls, logs, approval and revocation. Open issues for every missing link.
Week 3: write
Create one-page playbooks for data disclosure, prompt injection, credential misuse and impersonation. Assign decision owners.
Week 4: exercise
Run one table-top exercise. Fix the highest-impact missing log, permission or ownership issue. Schedule a retest.
This plan will not make a team "AI secure" in a month. It will replace survey concern with a tested operating baseline.
What the Darktrace numbers are good for
The 73% and 46% figures are useful for showing that threat impact and confidence are separate questions among the people Darktrace surveyed. They are weak evidence for purchasing a specific product or declaring another organization unprepared.
Use the survey to open the discussion. Use inventory, logs, playbooks, exercises and named owners to answer it locally.