Attempted versus executed calls

Expanded Definition

Attempted versus executed calls is a runtime governance distinction that records both the intent of an agent and the effect that actually reached a target service. In NHI operations, an attempted call may be blocked by policy, denied by policy enforcement, or redirected for inspection, while an executed call changes state, consumes privileges, or creates an audit trail. The distinction matters because a single execution log can hide repeated probing, failed tool selection, or policy friction that still signals risk. NHI Management Group treats this as a control-effectiveness signal, not just a logging preference, because it shows whether guardrails are stopping misuse before impact. The concept aligns with the broader monitoring and detection emphasis in the NIST Cybersecurity Framework 2.0, where organisations need visibility into events that reveal both attempted compromise and successful action. The most common misapplication is to count only executed calls, which occurs when telemetry is collected after authorization decisions instead of before them.

Examples and Use Cases

Implementing attempted-versus-executed tracking rigorously often introduces more telemetry volume and correlation work, requiring organisations to weigh better control validation against higher storage and analysis cost.

• An AI agent attempts to read a production secret from a vault, but policy blocks the request and only the attempted call is logged. That record shows pressure against the control plane even though no secret was returned.
• A service account tries three tool invocations with malformed parameters before one succeeds. The failed attempts can indicate prompt injection, schema confusion, or misconfigured orchestration.
• An agent requests access to a database endpoint, receives denial, then later succeeds after a just-in-time approval. Comparing the attempt and the execution clarifies whether the approval path behaved as intended.
• During a review of service-account activity, defenders compare blocked calls with executed calls to spot overbroad permissions and repeated access probes, using guidance from the Ultimate Guide to NHIs and NIST Cybersecurity Framework 2.0.
• An agent submits a request to rotate a key, but only the approval and execution events together prove whether the rotation really happened.

Why It Matters in NHI Security

Without this distinction, teams can mistake blocked abuse for successful control and overlook the pathways that are still being tested. That creates false confidence in policy enforcement, especially where agents have broad tool access, weak segregation of duties, or inconsistent logging across APIs and vaults. It also obscures the difference between noisy automation and genuine compromise, making incident response slower and less precise. The risk is material in environments where NHIs already outnumber human identities by 25x to 50x, and where only 5.7% of organisations report full visibility into their service accounts, according to the Ultimate Guide to NHIs. For governance, the security question is not just what executed, but what was tried, blocked, retried, and eventually allowed. This is where runtime evidence, incident review, and least-privilege tuning intersect with the NIST Cybersecurity Framework 2.0 and identity-centered controls. Organisations typically encounter the importance of this distinction only after a blocked agent action becomes the precursor to a later successful abuse, at which point attempted versus executed calls becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does identity lifecycle automation reduce risk versus hide it?
• How should organisations govern agentic AI when it makes judgment calls, not just automated actions?
• What breaks when identity controls are only documented and not executed consistently?
• How should teams decide when to keep a static secret versus migrate to federation?