Who is accountable when a delegated action is approved for one party but executed by another?

Why This Matters for Security Teams

delegated action create a deceptively simple audit question: who is responsible when approval and execution are split across different identities? In practice, that split is common in service-to-service workflows, agentic AI pipelines, and human-in-the-loop operations. If the record only shows the approval, teams lose the ability to prove who actually acted, whether the action stayed within scope, and whether the system enforced the intended policy.

This is why NHI governance cannot stop at “was access granted.” It must capture actor, approver, policy decision, subject scope, and expiry as a single lineage event. That expectation aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where accountability, audit logging, and least privilege are required. It also maps to the governance gaps documented in NHI Mgmt Group's Ultimate Guide to NHIs, where excessive privilege and weak visibility remain persistent failure modes.

When delegated authority is not tied to durable evidence, teams can end up defending an approval trail that does not prove execution lineage. In practice, many security teams discover the absence of actor-level accountability only after a policy exception has already been abused.

How It Works in Practice

The accountable model for delegated actions is a three-part chain: the initiator or actor, the approver, and the enforcement system. The actor is the identity that executed the request, the approver is the identity that granted conditional authority, and the policy engine is the control point that verified scope and time bounds at runtime. For NHI and agentic workflows, that means the authorization record must include subject identity, delegated subject, action, resource, decision, TTL, and policy version.

Best practice is evolving toward event records that preserve both intent and execution. A request may be approved for one party, then carried out by another on behalf of that party, but the system should still record the actual executor and the approval lineage. This is especially important when a service account, workload identity, or AI agent uses a short-lived token to complete a task. The token proves what was allowed at that moment, while the audit trail proves who used it and under what authority.

Operationally, that means:

• Use workload identity as the primary identity primitive for the executor, not a shared secret.
• Issue just-in-time credentials with narrow TTL and explicit task scope.
• Log the approver, actor, and enforcement decision as separate fields.
• Bind the approval to a policy version so later reviews can reconstruct the rule in force.
• Revoke access automatically when the task completes or the TTL expires.

For agentic systems, this aligns with runtime authorization patterns discussed in NHI Mgmt Group's Ultimate Guide to NHIs and with control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls. These controls tend to break down when approvals are stored in one system, execution happens in another, and neither system preserves a shared correlation ID across the full transaction.

Common Variations and Edge Cases

Tighter delegated-access controls often increase workflow friction, requiring organisations to balance auditability against speed for high-volume operations. That tradeoff becomes sharper when approvals are recursive, when a human delegates to a service account, or when an AI agent chains multiple subtasks under one parent request.

There is no universal standard for this yet, but current guidance suggests the same principle across edge cases: accountability follows both authority and execution, not approval alone. If the approver grants authority to a role, but a different workload identity performs the action, then both identities need to remain visible in the record. If an agent re-delegates inside a tool chain, each hop should be captured so the original scope is not lost.

Two common failure patterns deserve attention. First, shared service accounts collapse attribution, making it impossible to prove which executor used the delegated privilege. Second, approval-only systems often omit policy context, so reviewers cannot tell whether the action was allowed because of time, subject scope, or an exception. The broader risk is visible in real-world incidents such as the Schneider Electric credentials breach, where identity handling and access control weaknesses can turn into broad exposure. Current guidance suggests preserving per-action lineage, but the exact storage model remains implementation-specific across IAM, PAM, and agent orchestration platforms.

Related resources from NHI Mgmt Group

• Who is accountable when access changes are approved in one system but applied in another?
• When do NHI access reviews create more value than a one-time cleanup?
• Who is accountable when an employee retains access in one system after leaving another?
• Who is accountable when a delegated agent performs the wrong tool action?