The account administrator should be accountable for the delegated operation, because that role performs the action and must hold the correct permissions. The sender remains the business owner of the transaction once it is created. In practice, accountability is shared: the admin controls execution, while the sender retains ownership and the resulting lifecycle state within the account.
Who owns accountability when a transaction is created on someone else’s behalf?
Accountability should follow the role that executed the delegated action, while ownership of the business transaction stays with the sender who initiated it or on whose behalf it was created. That split matters because delegated operations can only be governed cleanly when execution responsibility and business ownership are both explicit.
When a platform allows one person to create a transaction for another sender, the accountable party is the administrator or operator who performed the delegated action. The sender still owns the transaction outcome, but the admin is responsible for using the correct permissions, following the approved workflow, and ensuring the action is attributable.
How does delegated transaction accountability work in practice?
Delegated creation creates two different obligations. The first is operational: the person or role that submits the transaction must be authorised to do so and must be able to justify the action if it is reviewed later. The second is business: the original sender remains tied to the transaction as its owner, so the account state, history, and downstream lifecycle remain associated with that sender.
This is a common source of confusion because “who caused it” and “who owns it” are not the same question. In delegated workflows, the admin is the accountable executor, but the sender is still the business source of the transaction record. That distinction is especially important where approvals, audit trails, and exception handling depend on clear attribution.
Why does shared accountability need clear boundaries?
Shared accountability only works when the system can prove who acted, under what authority, and for whose benefit. Without that separation, teams lose the ability to answer basic control questions such as whether the action was legitimate, whether the right permissions were used, and whether the sender or administrator should resolve a dispute.
For practitioners, the useful test is whether the platform preserves both execution trace and business ownership. If the answer is yes, the delegated action can be reviewed and investigated cleanly. If the answer is no, responsibility becomes ambiguous, and that ambiguity usually shows up later as approval gaps, audit friction, or unresolved operational disputes.
Risk and Threat Considerations
Delegated transaction flows create accountability risk when the platform cannot distinguish between the actor who executed the action and the sender who benefits from it. That ambiguity can hide misuse of delegated access, weaken auditability, and make it harder to assign corrective action after a disputed or unauthorized transaction.
Failure mechanism: If delegated actions are recorded only against the sender, the true operator can disappear from the audit trail, which weakens attribution and review. If they are recorded only against the administrator, the business owner loses visibility into the transaction lifecycle and may be unable to confirm what was created on their behalf.
Impact: Investigations become slower, approvals are harder to defend, and control failures can persist because no one role is clearly accountable for execution while ownership remains detached from the operational event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Delegated transaction execution depends on limiting what the acting role can do. |
| AU-2 — Audit Events | Delegated actions need audit records that preserve actor, authority, and event detail. | |
| AU-12 — Audit Record Generation | Accountability relies on generating records that preserve the true executor of the action. | |
| Recommendation — Enforce least privilege for delegated operators so they can only create the transactions they are allowed to submit. Log delegated transaction creation with actor, on-behalf-of sender, and outcome fields. Generate audit records that capture who executed the delegated transaction and under what authority. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Delegated creation is an access-control question about who may act for whom. |
| A.5.18 — Access rights | The role performing on-behalf-of actions must have explicit, reviewable rights. | |
| Recommendation — Define and enforce delegated access rules that separate operator authority from sender ownership. Review and document the rights that permit users to create transactions on behalf of others. | ||
Practitioner Guidance
What to verify: Confirm that the transaction record stores both the delegated actor and the original sender, and that the audit trail shows who executed the action, not just who ultimately owns it. If the system collapses those two roles into one field, accountability will be unreliable.
Decision rule: If a user is acting on behalf of another sender, treat the operator as accountable for correct execution and permission use, and treat the sender as accountable for the business content and lifecycle of the transaction once created.
What good looks like: Reviewers can see a clear chain of responsibility, the delegated executor can be challenged on improper action, and the sender can still be traced as the business owner without confusing ownership with execution.
Practitioner takeaway: The control objective is not to choose one owner for everything, it is to make execution accountability and business ownership simultaneously visible so disputes, reviews, and investigations do not rely on interpretation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
