Who is accountable when social engineering turns a user into the execution layer?

Why This Matters for Security Teams

When a user is manipulated into pasting commands, approving a prompt, or running a script, the attacker is no longer just targeting the person. They are turning the human into an execution path. That shifts the issue from awareness training alone to endpoint control, identity assurance, and privilege containment. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls makes that distinction operational by emphasizing enforceable controls around execution, access, and system hardening, not just user education.

This is also where NHI governance becomes relevant, because attackers often pivot from the manipulated user to tokens, service accounts, or API keys already available on the endpoint. NHIMG’s research on the MGM Resorts Breach 2023, Scattered Spider and Storm-2949 Azure Breach shows how social engineering can quickly become identity abuse when execution controls are weak. In practice, many security teams discover the missing guardrail only after a user has already run the attacker’s instructions.

How It Works in Practice

Accountability is shared, but the control owner depends on where the failure occurred. Security awareness owns the human susceptibility layer, endpoint engineering owns the ability to prevent unsafe execution, and identity governance owns what can be touched once the user is tricked. A mature model assumes that people will make mistakes and designs the environment so those mistakes do not become remote code execution, privilege escalation, or credential theft.

Practically, this means pairing awareness with technical prevention. Modern guidance from ENISA Threat Landscape and NIST SP 800-63 Digital Identity Guidelines supports stronger identity proofing and session protection, but that is not enough on its own when the attack vector is command execution. Security teams typically need:

• application control and script restriction so pasted commands do not execute silently
• privilege separation so a standard user cannot turn one click into admin-level impact
• device posture checks before allowing sensitive actions or token use
• phishing-resistant authentication and step-up approval for high-risk workflows
• rapid revocation of tokens, sessions, and cached credentials after suspected manipulation

For identity teams, the question becomes whether the user session is also a trusted execution context. If the endpoint can run arbitrary code, harvest browser sessions, or expose locally stored secrets, then the manipulator has effectively converted the user into an execution layer for the rest of the environment. NHIMG’s Uber Breach analysis is a reminder that social engineering often succeeds because downstream controls do not stop what happens after the first credential or approval is obtained. These controls tend to break down when users have local admin rights and the organisation allows unsanctioned scripting, because the attacker inherits both trust and execution power.

Common Variations and Edge Cases

Tighter execution controls often increase operational overhead, requiring organisations to balance user flexibility against the risk of turning endpoints into attacker-operated launch pads. The right answer is not always full lockdown, and current guidance suggests a risk-based model because developer, IT admin, and finance workflows have very different tolerance for script restrictions and step-up prompts.

One edge case is the so-called “legitimate” command pasted by a user who is following help desk instructions. Another is a prompt injection or browser-based lure that causes the user to approve actions inside an approved app. A third is the hybrid case where the attacker does not need admin rights because the user is already logged into cloud tools with broad session permissions. That is why accountability should be mapped to three places: training for recognition, endpoint policy for prevention, and identity governance for containment.

There is no universal standard for this yet, but the practical pattern is consistent: reduce standing privilege, restrict high-risk execution paths, and require stronger assurance before a session can touch secrets or privileged resources. Where mature controls are missing, the manipulated user becomes the bridge from social engineering to identity compromise.

Related resources from NHI Mgmt Group

• Who is accountable when an agentic IDE turns search into execution?
• Who should be accountable when authenticated users abuse access after a social engineering attack?
• Who is accountable when an AI workflow turns a calendar event into code execution?
• Who is accountable when social engineering defeats identity controls?