Request To Execution Gap

What the request to execution gap means

The request to execution gap is the separation between the person or system that authorizes work and the identity that actually carries it out. In agentic workflows, that gap is not just semantic, it determines who can be blamed, audited, constrained, or stopped when the action occurs.

This matters because the executor can have broader technical reach than the requester ever had. If a workflow does not preserve the relationship between intent, approval, and execution, the resulting action may be technically valid yet operationally misaligned with the original request.

Why the gap matters in agentic systems

In conventional software, a request usually maps to a direct system action. In agentic systems, the chain is longer: a user issues intent, an orchestrator interprets it, and one or more identities may perform the actual API call, file change, or tool invocation. That indirection can be useful, but it also means execution authority may outstrip human intent.

When that happens, the executor becomes the meaningful security subject. Policy enforcement, logging, and accountability need to reflect the identity that performed the work, not only the person who started the workflow. Otherwise, a narrow request can trigger a broader effect than the requester could have produced directly.

The gap is especially important where an agent can act across systems, reuse session context, or switch tools during a task. The original intent may be legitimate while the execution path becomes more powerful, more persistent, or more difficult to interpret than the user expected.

Accountability, authorization, and audit implications

The central challenge is that approval and execution may live in different control planes. A manager, operator, or application owner may approve an action, but the active identity might be a service account, workload, or delegated agent credential. That makes audit quality depend on whether logs preserve both the requester and the executor as separate actors.

Without that separation, a system can look compliant while hiding the real source of authority. The audit trail should show who asked, what was approved, what the executor did, and which identity used the privilege. For a broader identity-control lens, NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that authentication, access control, and auditability are separate control concerns.

The same idea appears in zero trust design: execution should not inherit trust merely because a request originated from an approved user or workflow. NIST SP 800-207 Zero Trust Architecture is relevant because it treats every action as something to verify, constrain, and continually evaluate rather than assume safe by origin.

How the gap shows up in practice

Common failure modes include over-broad delegated access, unclear ownership of agent actions, and logs that capture the human trigger but not the actual executor. In those cases, the system may not be able to explain why an action occurred, who benefited from it, or whether the executor exceeded the original request.

That problem is closely related to privilege misuse in agentic systems. If an agent can translate a narrow request into a broad tool action, the execution identity effectively becomes a power multiplier. OWASP Agentic AI Top 10 is useful here because it explicitly addresses identity and privilege abuse, tool misuse, and trust exploitation in agent-driven workflows.

Where agents call APIs directly, the gap can also resemble an authorization problem. OWASP API Security Top 10 is relevant because broken authorization often emerges when the system cannot cleanly distinguish between who requested an action and which identity was allowed to perform it.

Risk and Threat Considerations

The main risk is that an apparently narrow request can be executed through a more privileged identity, creating unauthorized scope expansion, weak accountability, or hidden lateral reach. In adversarial cases, attackers may try to exploit that separation by steering a legitimate agent or workflow into performing actions outside the requester’s expected authority.

Failure mechanism: The control failure occurs when policy is bound to the request origin but enforcement is bound to a different executor, or when the executor’s authority is broader than the request’s business intent.

Impact: This can produce excessive access, ambiguous attribution, stealthy abuse of delegated authority, and security decisions that cannot be reliably reconstructed after the fact.

Practitioner Guidance

Why practitioners should care: The request to execution gap is a governance boundary, not just an implementation detail. Treat the requester, approver, and executor as distinct actors whenever an agent or automation layer can act on behalf of a person.

What to watch for: Pay attention when logs, approvals, and downstream actions do not name the same identity set, or when an agent can perform actions that the originating user could not directly perform. That mismatch is usually where accountability and privilege drift begin.

Practitioner takeaway: Design workflows so the executor’s identity, privilege, and audit trail are explicit, because intent without execution traceability is not enough to govern agentic action.

Related resources from NHI Mgmt Group

• How should security teams close the gap between IAM policy and actual execution?
• How should security teams reduce the risk of poisoned pipeline execution in pull request workflows?
• What breaks when LLM frameworks expose code execution or dangerous request features?
• Why do global plugins and execution order create hidden request failures in gateway environments?