Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

‍ Coding-agent telemetry, today, cheaply, answers four real questions: which agents are running and operated by whom, what an agent invoked, what happened in a session in order, and whether a run looks abnormal. Part 1 of this series covers that case in full. ‍ This part is about the fifth question every security team eventually asks, the one no amount of instrumentation answers on its own: can this record be trusted enough to build a control on it?

The OWASP list for agentic applications, published in December 2025, gives security teams a shared vocabulary for what goes wrong when software acts rather than answers. Ten categories covering planning, tools, identity, supply chain, code execution, memory, inter-agent communication, cascading failures, human trust and rogue behavior. ‍ Translating that into a financial figure is where programs stall, and the usual attempt makes a specific error.

A model ranks phishing sixth. The security team has spent three years on phishing and knows how often people click. Somebody in the room concludes the model is wrong, or that the security team is attached to its own program, and the meeting stops being useful. ‍ Most of these disagreements are not about risk. They are about which question each side answered, and establishing that first resolves a surprising proportion of them without anyone conceding anything. ‍

Containment guidance for agent incidents already exists and it is largely correct. Revoke the tokens, freeze the orchestration tier, cut egress, set the vector store to read-only. Those steps take minutes and any competent team will find them. ‍ The difficulty sits either side of containment. Deciding what kind of incident this is takes longer than stopping it, establishing what the agent did before you stopped it takes longer still, and both depend on preparation that has to exist beforehand.

Scenario libraries grow. A program starts with ransomware and a data breach, adds a third-party failure after a supplier incident, splits ransomware into encryption and extortion variants, adds a cloud outage, and two years later holds forty entries nobody has revisited. ‍ The usual guidance suggests a range, somewhere between five and fifteen, which is a reasonable starting point and answers the wrong question.

Colorado passed the first comprehensive state AI law in May 2024, and organizations spent the following year building impact assessment processes against it. Those obligations never took effect. The statute was delayed twice, blocked by a federal court, then repealed and replaced by a narrower framework before its own effective date arrived. ‍ Anyone who built a compliance program to that specific statute prepared for a regime that never existed.

The same quantification run supports two conversations that happen weeks apart. One with a board asking whether the organization is managing cyber risk sensibly. One with an underwriter deciding what to charge for it. ‍ Most guidance treats these as a formatting problem, where the board version gets charts and the submission gets detail.

‍ The distance between what OpenTelemetry was built for and what AI governance is asking of it shows up in a single number. Distributed tracing descends from Dapper, the 2010 Google paper that gave the industry the vocabulary of traces and spans. Dapper sampled one trace in 1,024. That is ample for finding a latency regression, because a regression recurs and the next sample catches it.

A software bill of materials works because software changes through a build. Someone bumps a dependency, the pipeline runs, the manifest updates and a scanner compares the new list against known vulnerabilities. Every part of that loop assumes a rebuild is the thing that changes behavior. ‍ AI systems break that assumption at the point it matters most. Editing a system prompt changes what a model does, swaps no dependency, triggers no build and produces no new manifest.