Because a single agent turn can trigger many more security-relevant actions than a normal request, and the multiplication changes the real cost profile. Per-event figures can make a control look cheaper than it is, or hide the fact that low-cost events add up to meaningful latency and analyst workload. Per-turn measurement captures the whole execution loop, which is what attackers actually exploit.
Why per-turn measurement matches the real security workload
Agent security tooling is not being evaluated against a normal request-response pattern. A single agent turn can include multiple tool calls, policy checks, memory reads, context assembly steps, and remediation decisions, so the work done by the control is closer to a full execution cycle than to one discrete event. Measuring per turn reflects the actual unit of risk, effort, and latency that operators experience.
That distinction matters because the same turn can fan out into repeated security decisions before the agent finishes its task. If you only count events, you can understate the amount of protection being applied and miss the fact that the control is shaping an entire chain of actions, not one isolated call.
Per-turn measurement also aligns with how agent behaviour is understood in practice. The meaningful question is whether the control can govern one complete agent decision loop, including what happens before and after the model calls a tool, rather than whether it intercepted a single observable event in the middle of that loop.
Why event-based metrics can mislead cost and performance decisions
Event-based figures can make a control look cheaper than it really is when one turn expands into many security-relevant operations. A tool that appears low-cost per event may still create meaningful cumulative spend, latency, or analyst review burden once multiplied across all the actions taken in a typical turn.
This is especially important for teams comparing vendors or sizing controls. If one product reports cost at the event level while another reports at the turn level, the comparison is not apples to apples. The apparent efficiency of the event metric can hide the true operational footprint of the security layer.
Per-turn accounting also helps teams reason about user experience. When a turn is delayed by repeated checks, the end user feels the total delay, not the number of individual events that caused it. That makes turn-level measurement the more useful basis for budget planning, capacity planning, and deciding where to simplify the control path.
How to define the unit so the metric stays honest
The key is to define a turn as one completed agent execution loop, from the initial user or system request through the agent’s internal reasoning, tool use, policy enforcement, and final output. Once that unit is fixed, teams can measure security actions, latency, and analyst effort consistently across different workloads and products.
That definition should be stable enough to support comparisons over time. If the turn boundary changes from one release to the next, the metric stops being useful because the denominator has shifted. Good measurement practice depends on a shared definition that engineering, security, and operations all use the same way.
Per-turn measurement is also the better basis for threshold setting. If a control is allowed to issue a certain number of checks, reviews, or interventions per turn, teams can evaluate whether the control is proportionate to the task and whether the friction it adds is acceptable for the class of action being governed.
Risk and Threat Considerations
When agent security is measured per event, attackers can benefit from the blind spot created by fragmentation. A turn can be broken into many cheap-looking events, each of which seems manageable on its own, while the combined loop still gives an attacker enough opportunities to probe, chain actions, or force repeated policy handling.
Failure mechanism: Per-event reporting undercounts the full execution path, so teams underestimate the cumulative cost, latency, and review burden of one agent decision. That can lead to controls that are approved as “lightweight” even though they become expensive or slow at scale.
Impact: The organisation may overcommit to a control that is operationally noisy, or underinvest in a control that is actually doing substantial work per turn. The result is weaker budget accuracy, poorer tuning, and less reliable risk acceptance for agent-driven systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent turn costs reflect repeated policy and privilege decisions. |
| Recommendation — Measure agent controls per turn when privilege decisions shape the full execution loop. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Turn-level measurement depends on complete logged execution sequences. |
| AU-6 — Audit Review, Analysis, and Reporting | Per-turn review better reflects the analyst workload created by chained actions. | |
| Recommendation — Log complete agent execution sequences so cost and detection metrics can be aggregated per turn. Review audit output at the turn level to capture total analyst effort and response load. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | Monitoring agent activity needs a unit that captures the full execution cycle. |
| Recommendation — Monitor agent execution as a full turn so security events are interpreted in operational context. | ||
Practitioner Guidance
What to measure: Track security cost, latency, and human review at the turn level first, then break the turn into events only for diagnostic detail. That gives you the executive metric that reflects real operating cost and the engineering metric that shows where the work is happening.
Decision rule: If a control changes how many actions an agent can complete before finishing one task, measure it per turn; if it only records an isolated signal with no effect on the loop, event-level telemetry may be enough as a secondary view. The turn is the right billing and capacity unit whenever the control influences the full execution path.
Practitioner takeaway: Use per-event data to debug, but use per-turn data to judge cost, performance, and security value, because the agent is judged by the whole loop it executes, not by each individual action inside it.
Related resources from NHI Mgmt Group
- How should small engineering teams turn AI agent demos into production-grade tools without creating new security gaps?
- Why do event-based tools struggle with AI agent governance?
- Should organisations evaluate AI agent security tools before or after identity controls are in place?
- How should security teams evaluate AI agent authorization tools?