The approval can be completed by the wrong person, turning a delegated decision into an unintended access grant. In agent workflows, that means the account that finished the approval may not be the one that should own the resulting action, which undermines both accountability and audit integrity.
Why This Matters for Security Teams
When an MCP approval is not bound to the original requester, the approval flow stops being a controlled delegation and becomes a transferable permission event. That breaks the basic security assumption behind identity-bound authorization: the person or agent that asked for access is the one whose intent is being evaluated. For agentic workflows, that distinction matters because tool calls, approvals, and downstream actions can be separated in time and by actor.
In practice, this is where audit trails become misleading and access reviews lose meaning. A reviewer may approve a request believing they are authorising one agent or session, while the final grant lands with a different user, service account, or automation path. The result is weak accountability, unexpected privilege, and a higher chance of policy drift. NHIMG’s research on the OWASP Agentic Applications Top 10 shows why identity binding is a core control in agent workflows, not a nice-to-have.
The risk is not theoretical. Current guidance from the OWASP Agentic AI Top 10 treats confused-deputy style failures as a primary design concern, because autonomous systems can chain actions faster than human reviewers can notice the mismatch. In practice, many security teams encounter this only after an approval event has already been reused, replayed, or detached from the original requester.
How It Works in Practice
The fix is to make the approval transaction cryptographically and logically tied to the original requester, not just to the approval actor. That usually means the request is created with a stable request identifier, the requester’s workload identity, and the intended scope of action. The approval step must verify that the same requester context is still present before the grant is issued. If the approval is for an agent, the agent’s workload identity should be the identity primitive, not a human proxy.
In mature implementations, the approval record carries the original subject, tool scope, expiration, and policy decision. A downstream enforcement point checks that the approval token, the requester identity, and the execution context all match. This is where context-aware authorization and just-in-time access become important. The approval should enable only the specific task, for a short time, and only for the original requester. If the request was initiated by an AI agent, the resulting privilege should be ephemeral and revocable once the task is complete.
- Bind approvals to the original subject, not to a generic queue item.
- Use short-lived tokens or delegated credentials that expire automatically.
- Validate requester identity again at execution time, not only at review time.
- Log who approved, who requested, and which workload actually executed the action.
For agentic systems, this aligns with the operating model described in Analysis of Claude Code Security, where tool use, credential scope, and session continuity have to be treated as one control plane. These controls tend to break down when approvals are copied across sessions or routed through shared service accounts, because the platform can no longer prove that the final action belongs to the original requester.
Common Variations and Edge Cases
Tighter approval binding often increases workflow friction, requiring organisations to balance stronger accountability against reviewer convenience and automation speed. That tradeoff is real, especially in high-volume agent environments where requests are frequent and human review is already a bottleneck.
One common edge case is asynchronous approval, where the original requester’s session expires before the decision is made. Current guidance suggests the system should re-validate identity or re-issue the request rather than silently handing the approval to a different actor. Another edge case is shared operations teams, where a human reviewer approves on behalf of multiple agents or services. That may be acceptable only if the approval is explicitly transferred and the audit record preserves the original requester and the final executor separately. There is no universal standard for this yet, so the control design should be documented and tested.
The pattern also becomes more dangerous in multi-agent systems and automation pipelines, where one agent requests, another approves, and a third executes. Without strict binding, the approval becomes a reusable privilege artifact instead of a task-specific decision. NHIMG’s Schneider Electric credentials breach illustrates how quickly credential misuse can become an enterprise-wide issue when identity and intent are not tightly controlled.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Approval binding failures are a confused-deputy risk in agentic flows. |
| CSA MAESTRO | IAP-02 | MAESTRO addresses authorization and delegation for autonomous agents. |
| NIST AI RMF | GOVERN | AIRMF requires accountable oversight for AI-enabled decision paths. |
| OWASP Non-Human Identity Top 10 | NHI-04 | Identity binding and session integrity are core NHI control concerns. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero Trust requires continuous verification of subject and context. |
Tie each approval to the original requester and re-check identity at execution time.
