Defining an Unauthorized Tool Attempt
There is no standards body that formally defines "unauthorized tool attempt rate" as a named metric. The concept is constructed from established access control principles, most directly NIST SP 800-53's AC-6 Least Privilege control, which requires that processes operate only with the permissions necessary for their assigned task. Applied to an AI agent, an unauthorized tool attempt is any tool, API, or function invocation request that falls outside the agent's declared permission scope or policy configuration at the time of the call.
This definition needs to be distinguished from a denied-but-expected call, such as a benign fallback attempt an agent makes as part of normal error handling before succeeding through an approved path. Reviewed standards do not address this distinction directly, so each organization must define it within its own policy model. Without that distinction, a rate calculation will conflate routine denials with attempts that warrant investigation, reducing the metric's usefulness as a security signal.
Calculation Methodology
No reviewed source specifies a preferred formula for this metric, so the calculation window and aggregation level are organization-specific decisions. Common approaches include counting unauthorized attempts per agent session, per individual agent over a rolling time period, or across an entire agent fleet within a fixed window such as 24 hours. The rate itself is typically expressed as unauthorized attempts divided by total tool-call attempts within the chosen window.
Consistency matters more than the specific window chosen. If sessions vary widely in length or tool-call volume, per-session rates can be misleading when compared across agents. A time-windowed calculation normalized by total call volume tends to produce more comparable figures across deployments, but this remains a practitioner-level choice rather than a documented standard.
Interpreting Baseline Shifts and Anomalies
No authoritative baseline thresholds or anomaly ranges exist in the reviewed standards for this metric. Any specific threshold referenced by a vendor or internal team should be treated as organization-specific rather than an industry benchmark. What is useful is tracking the rate against its own historical baseline for a given agent or fleet and investigating deviations.
A sudden increase in unauthorized attempts from a single agent may indicate a permission misconfiguration, particularly following a deployment or policy change. A pattern concentrated around specific input sources or prompt content changes is more consistent with OWASP's Prompt Injection category, where crafted inputs cause an agent to attempt actions outside its intended scope. A sustained elevated rate across many agents with similar permission profiles may instead point to an Excessive Agency issue, where the granted permission scope itself is too broad. MITRE ATLAS technique categories can help classify the likely cause once an anomaly is flagged, though ATLAS does not define a rate metric or logging schema itself. The rate figure alone rarely indicates root cause and should be correlated with other telemetry before treating it as a confirmed incident.
Practical note
Treat a spike in this rate as a prompt to investigate, not as a confirmed incident on its own. Correlate it with input source, prompt content, and recent policy or deployment changes before escalating.
Governance and Audit Considerations
NIST SP 800-53's AU family establishes the general expectation that logged events, including access decisions, include enough detail to determine what occurred, when, and with what outcome. This provides the audit basis for retaining tool-call decision logs long enough to support later investigation and compliance review, though no reviewed source mandates a specific retention period for this use case.
NIST's AC-6 least privilege requirement supports periodically reviewing and tightening an agent's permission scope, which directly changes what counts as unauthorized going forward. NIST's AI RMF Manage function frames this kind of continuous monitoring as an ongoing risk management activity rather than a one-time control exercise. Organizations should avoid representing an internally derived baseline or threshold as compliance with an external standard, since no regulatory or standards body reviewed here mandates one. Platforms that provide runtime policy enforcement, agent permission management, and audit logging, including Trussed AI, implement the enforcement point and logging infrastructure this metric depends on, but the definition of "unauthorized" and the threshold for investigation remain governance decisions made by the deploying organization.