You approved the AI. Can you prove what it did?

Ask your security team a simple question: if an AI agent did something bad tomorrow, could you prove exactly what it did — which agent, under whose identity, which data it touched, which tool it called, and what happened as a result? For most organizations the honest answer is no. As Chris Hughes argues in “AI's Evidence Problem”, the central issue in AI security isn't a shortage of policy. It's a shortage of evidence — the telemetry that lets you reconstruct, after the fact, what an AI system actually did.

This is the companion to our last post on prompt injection. That one was about stopping the bad action. This one is about the part that comes before and after every control you deploy: being able to see and prove what your agents do at all.

Sanctioned isn't instrumented

Moving an employee from a personal ChatGPT account to a corporate one is real progress for identity governance. It is not the same as knowing what the AI did. A sanctioned system is one you're allowed to use; an instrumented one is one you can investigate. Approval doesn't buy you observability. After the migration you still may not know:

• which data was fed into the model,
• which documents were pulled in via RAG,
• which tools an agent invoked and which APIs fired,
• where the data went, what output came back, and what action was actually taken.

The gap shows up in the numbers. An ISACA 2026 poll found only 43% of respondents were meaningfully confident they could investigate and explain a serious AI incident to leadership or a regulator — and 56% didn't know how quickly they could even stop an AI system mid-incident. Incident investigation, as Hughes puts it, is fundamentally an evidence capability: you can only investigate what you decided, in advance, to record.

The risk was always the data

Strip away the novelty and most “AI risk” is a new face on old security problems: sensitive data leaving the org, unmanaged accounts, insecure integrations, excess privilege, and missing logs. Verizon's 2026 DBIR reports the share of employees regularly using AI tools on corporate devices jumped from 15% to 45% in a year, that 67% reach AI services through non-corporate accounts, and that source code is the data type most often fed into external GenAI services. Shadow AI, in other words, is first and foremost a data-security problem — not just an acceptable-use one.

The evidence chain no one is capturing

Agentic AI makes this sharply harder, because an agent doesn't just produce an answer — it takes actions. Logging User → Model was never enough; the real chain is:

Identity → Agent → Model → Tool → API → Data → Action → Target

— and sometimes Agent → Agent. OWASP's Top 10 for Agentic Applications (2026) names exactly the failure modes this chain is meant to catch — agent goal hijacking, tool misuse, identity and privilege abuse — and calls for logging and monitoring of agent activity, tool calls, and behavioral patterns. An AI agent is, in effect, a non-human digital actor, and like any actor it needs an identity and a behavioral baseline you can measure it against.

Four capabilities, one dependency

Hughes reduces the operational problem to four requirements. Each one, underneath, rests on the same foundation — telemetry:

• Inventory — the models, agents, tools, plugins, and extensions actually in use.
• Usage visibility — the sessions, activity, and actions taken.
• Data lineage — where data came from, where it went, where it's held.
• Behavioral detection — exfiltration, account compromise, and shifts in an agent's behavior.

This is the shape MoorAI was built to fit — with one deliberate inversion. Inventory is MoorAI's on-device AIBOM. Usage visibility is a signed record of every tool and MCP call an agent makes — action visibility, captured without reading the prompt. Data lineage is drawn from content-free signals: which app was read from, which actor drove it, the data class, where it was headed — never the file, never the prompt. Behavioral detection is the autonomous-agent signature MoorAI already ships. Same four capabilities Hughes asks for; none of them require us to see your content.

The catch: evidence vs. SIEM economics

Here's the tension the governance frameworks leave open. OWASP wants more logging; SOC teams are already drowning in ingestion and retention costs. AI adds enormous new volume — prompt logs, completion logs, tool traces, retrieval events, MCP interactions, agent-to-agent chatter. So organizations do the rational thing under budget pressure: they delete telemetry. And then, when the incident lands, the evidence isn't there.

Notice what makes AI telemetry expensive and risky to keep: it's the prompts and completions — high-volume, and full of exactly the sensitive data (source code, secrets, customer records) you least want sitting in a SIEM. The evidence requirement and the economics collide precisely on the content.

Evidence without the prompts

MoorAI resolves that collision by capturing the evidence and dropping the content. Every hop in the chain is recorded as governance metadata plus a tenant-keyed one-way hash — who, what agent, which tool, which data class, what decision, what risk — and never the prompt, the output, the arguments, or the file path. The record is signed and tamper-evident, and it streams off the device as OpenTelemetry — the same OTLP envelope Datadog, Dynatrace, Grafana, Elastic, and your SIEM already ingest — so the copy in your pipeline becomes the durable, immutable record:

export MOORAI_OTLP_ENDPOINT="https://otel-collector.example:4318"

Because the payload is a hash, not the prompt, this is the telemetry a cost-pressured SOC can actually afford to keep: a fraction of the volume, none of the sensitive content, no data-residency problem, and it drops straight into the Cribl-style pipeline the evidence architecture already assumes. The rest of the field ships you the prompts. MoorAI ships you the evidence.

The question to ask before the incident

The old question — “are we allowing AI?” — is settled; your teams are using it. The question that decides whether you have an evidence gap is the other one: if it goes wrong tomorrow, can we prove exactly what the agent did? That capability isn't something you bolt on during the incident. It's a design requirement — evidence and telemetry built into how the AI system runs from day one:

Identity → Model → Agent → Tool → Data → Action → Target → Evidence

You can meet that requirement the expensive way — capture every prompt and pay to store and protect it — or the content-free way. MoorAI is the second: the evidence without the exposure, signed and streamed, auditable in the open.

MoorAI is content-free, open-core (AGPL-3.0) security for AI agents — the evidence layer that runs on the developer's endpoint, not in a cloud that reads your prompts.

Sources

• Chris Hughes, “AI's Evidence Problem” — Resilient Cyber, Aug 28, 2026.
• 2026 Verizon Data Breach Investigations Report (DBIR).
• ISACA 2026 AI Pulse Poll.
• OWASP Top 10 for Agentic Applications (2026).

Note: Hughes's article discloses Cribl as a commercial partner; the statistics above are as reported by their cited sources.