Accountability is shared across endpoint, identity, and security operations teams because the failure sits at the boundary of user behaviour, script policy, and endpoint enforcement. Frameworks such as NIST SP 800-53 and the NIST Cybersecurity Framework both expect clear control ownership and monitoring over execution paths, not just incident response after the fact.
Why This Matters for Security Teams
When a user session turns into malware execution, the issue is not simply whether the endpoint blocked a file. It is a control boundary problem that exposes gaps across identity, device posture, script governance, and incident response. NIST guidance, including the NIST SP 800-53 Rev 5 Security and Privacy Controls, makes clear that execution control and monitoring are operational responsibilities, not after-the-fact forensic concerns.
Security teams often misread this kind of event as a single-product failure, but the real accountability question is who owns prevention, who approves exceptions, and who validates that detections are actually working. If script interpreters, living-off-the-land binaries, and user-initiated tooling are allowed to run without tight policy, the session can pivot from ordinary productivity into malware execution in seconds. The presence of a valid user login does not make the activity safe or trusted.
In practice, many security teams encounter this only after an attacker has already used a legitimate session to launch payloads, rather than through intentional control testing.
How It Works in Practice
Operational accountability usually sits across three functions. Endpoint security owns execution policy and telemetry. Identity teams own authentication strength, session context, and conditional access. Security operations owns detection, correlation, and escalation. A clean handoff is only possible when these groups share the same visibility into what a session is allowed to do, not just whether a user signed in.
In mature environments, the chain looks like this: a user authenticates, the device is evaluated, a session is granted, and control logic determines whether macros, PowerShell, shell interpreters, unsigned binaries, or child processes can run. If suspicious behaviour appears, detections should link the user identity, host, process tree, network activity, and policy decision. That makes it possible to answer whether the event was an allowed action, a policy gap, or an outright compromise.
- Identity controls should confirm who authenticated and whether the session matched expected risk.
- Endpoint controls should restrict or log execution paths that are commonly abused.
- Monitoring should connect process activity to the initiating user, device, and timeline.
- Exception handling should be explicit, time bound, and reviewed.
Security teams can align this with the CIS Controls v8, especially around inventory, secure configuration, malware defences, and audit log management. The practical test is whether responders can trace the decision that allowed execution, not just whether they can isolate the host after compromise. These controls tend to break down when legacy endpoints, local admin rights, and inconsistent script policies exist on the same network because the enforcement point is no longer reliable.
Common Variations and Edge Cases
Tighter execution control often increases operational friction, requiring organisations to balance user productivity against containment and review overhead. That tradeoff is real, especially for engineering, IT operations, and automation-heavy teams that depend on scripts and signed tools to do their work.
Best practice is evolving for environments that rely on BYOD, VDI, privileged workstations, or just-in-time admin access. In those settings, accountability becomes more complex because the same session may span managed and unmanaged assets, multiple identities, or delegated privileges. There is no universal standard for how far the identity team’s responsibility extends once a trusted session is established, but current guidance suggests the owner of the control must be able to prove enforcement, not just policy intent.
Edge cases also appear when malware execution follows a user action that was technically permitted, such as opening a document, running a sanctioned script, or invoking an approved automation tool. In those situations, the question is not whether the user caused the event in a simple sense, but whether the organisation failed to constrain a known execution path. For stronger governance, teams should document exception workflows, review high-risk allowances regularly, and test whether detection logic still works when common admin tools are abused.
Where identity, endpoint, and SOC ownership are split across different tooling stacks, accountability often becomes disputed only after containment has already started.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Session trust and access conditions matter when execution follows user authentication. |
| NIST AI RMF | Risk governance is relevant where automation or AI-driven actions trigger execution paths. | |
| MITRE ATT&CK | T1059 | Command and scripting interpreter abuse is a common route from user session to malware execution. |
| OWASP Agentic AI Top 10 | If an AI agent can launch tools, its execution authority becomes part of the accountability chain. |
Tie session access to least privilege and reassess trust when activity shifts toward suspicious execution.
Related resources from NHI Mgmt Group
- Who is accountable when social engineering turns a user into the execution layer?
- Who is accountable when a workflow flaw exposes session secrets and code execution?
- Who is accountable when an agentic IDE turns search into execution?
- Who is accountable when an AI workflow turns a calendar event into code execution?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
