Your AI systems are already an attack surface

The 2026 DBIR, page 26 (Figure 26), records requests from 793 actors in the Anthropic dataset. The median actor asked for AI help with roughly 15 MITRE ATT&CK techniques; a request does not establish a successful attack. NIST's Generative AI Profile covers the AI lifecycle, while the preliminary Cyber AI Profile addresses securing AI components, using AI for defense, and defending against AI-enabled attacks.

NIST IR 8596 is still a preliminary draft — it closed comments in January 2026 — so treat it as direction, not as a control standard you can be audited against. The point it makes does not depend on the draft status: AI is both a system you have to secure and a capability changing how attackers work.

AI changes both sides of the system

On the attacker side, AI speeds up research, lure-writing, translation, and code modification. It makes familiar techniques cheaper without inventing a new class of vulnerability.

On the defender side, AI can summarize alerts, correlate records, draft queries; explain code, propose response steps, and help teams search large evidence sets. Those benefits also introduce new trust decisions: which data may enter the model, which output can drive an action, and who verifies the result?

The security boundary extends behind the chat window to every identity and dataset, each connector and tool, and the approval path.

An AI inventory needs seven parts

1. Use case and owner. What decision or workflow uses AI, who is accountable for it, and what happens if it is wrong?
2. Model and provider. Record the model and version with its hosting region, service terms, and retention configuration.
3. Data flow. Trace what enters prompts and retrieval stores. Follow it through fine-tuning or logs to evaluation and output destinations.
4. Identity and authorization. Record the user or service account, its token and role, and the tenant that can invoke each tool.
5. Tools and agents. State the allowed read and write operations first. Then identify any authority to execute or purchase, followed by publication, deletion, or outbound messages. Mark every approval boundary.
6. Software supply chain. Name the client libraries and orchestration framework, followed by plugin and model packages. Record containers and deployment services separately.
7. Evaluation and incident path. Explain how the system detects unsafe output or data leakage. Cover prompt injection, model drift, and unauthorized action in the containment and investigation plan.

A control model for AI-enabled workflows

Separate read, propose, and act

A system that can retrieve information does not need the same authority as a system that can change a firewall, send a message, or issue a refund. Use separate identities and explicit gates for side effects.

Assume retrieved content is untrusted

A document, a web page or a ticket can carry instructions aimed at your agent rather than at your reader. Treat all of it as data, constrain the tool arguments, and check authorisation somewhere the model cannot reach.

Limit each tool by where it can reach and what it can change

Allowlist exact origins and validate inputs against a schema. Cap lengths, pace each destination, set transaction ceilings, and confirm side effects. Safety instructions alone are insufficient.

Record enough to reconstruct the decision

Record the model and prompt version, the sources retrieved, the tool calls and the approval — and keep secrets out of the log. If you cannot reconstruct how an answer was produced, you cannot audit it or improve it.

Design a stop path

Operators need a way to revoke credentials, halt jobs, isolate connectors, reject queued actions, and identify what the system already changed.

What to measure first

• Percentage of AI use cases with an owner, data classification, and approved model/provider.
• Percentage of tool-enabled workflows split between read-only and state-changing identities.
• Number of connectors able to reach secrets, customer data, production changes, payments, or external communications.
• Coverage of prompt-injection and data-exfiltration tests for high-impact workflows.
• Rate of AI-proposed actions independently reviewed before execution.
• Time required to revoke an agent's credentials and reconstruct its recent actions.

How KernelHawk fits

KernelHawk reviews AI-enabled workflows for data exposure, excessive permissions, unsafe tool access, missing approvals, and gaps in incident response.

Certainty in model output does not make it evidence. Evidence means an artifact you can inspect, a source record, or a response someone verified. That distinction matters more as plausible text gets cheaper.