Who is accountable for preventing social engineering that leads users to run attacker-supplied scripts during meetings or interviews?

Why This Matters for Security Teams

social engineering during meetings or interviews is not just a user-awareness issue. It is an access, endpoint, and process-control problem that can turn a legitimate collaboration channel into an execution path for attacker-supplied scripts. The practical risk is simple: if staff are conditioned to trust a request because it arrives in a video call, chat thread, or recruiting workflow, an attacker can bypass many technical controls by persuading the target to run code voluntarily. Guidance from the CISA cyber threat advisories consistently shows that social engineering remains a durable initial access method because it exploits routine business behaviour, not just technical gaps.

Accountability therefore sits with security and IT for guardrails, but it also extends to managers, recruiters, and interviewers who set expectations for how remote sessions are conducted. If the process allows ad hoc troubleshooting, screen-sharing with unknown participants, or “quick setup” steps from a stranger, then the organisation has created the conditions for abuse. Security teams often focus on blocking malware after execution, but the better control is stopping the social path that authorises the execution in the first place. In practice, many security teams encounter this only after a candidate interview, support call, or executive meeting has already been used to deliver the malicious script, rather than through intentional process design.

How It Works in Practice

Effective prevention is a layered control problem. First, organisations need explicit policy: no one should run pasted commands, open attachments, install remote tools, or follow unsolicited setup instructions during a meeting unless the request is validated through an approved channel. Second, the environment should make unsafe behaviour harder by default through least privilege, application control, script restrictions, and endpoint prevention. Third, staff need a simple escalation path so they can pause the interaction, verify identity, and report suspected scams without embarrassment or delay.

That model maps well to common attack patterns described in the MITRE ATT&CK Enterprise Matrix, especially techniques that rely on user execution and trusted relationships. It also aligns with control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, where organisations are expected to combine training, access control, monitoring, and incident response rather than treat awareness as a standalone safeguard.

• Use meeting and interview scripts that prohibit running code on demand.
• Require verified support or recruiting channels before any troubleshooting step.
• Limit local admin rights and restrict script interpreters where feasible.
• Monitor for suspicious child processes, downloads, and remote-access tooling.
• Give employees a clear “stop and verify” procedure for live calls.

Where identity is involved, especially in hiring or contractor onboarding, verification should be separated from execution: proving who someone is should not imply trusting their instructions. These controls tend to break down when fast-moving interview loops, outsourced recruiting, or high-pressure support calls normalise exceptions and people skip verification to keep the conversation moving.

Common Variations and Edge Cases

Tighter meeting and endpoint controls often increase friction for legitimate support, recruiting, and engineering workflows, requiring organisations to balance speed against misuse resistance. That tradeoff is real, especially in distributed teams where live troubleshooting is part of the job. Best practice is evolving toward role-based exceptions, but there is no universal standard for this yet.

Some environments need extra nuance. Executive meetings may require stronger moderation because impersonation attempts often target authority and urgency. Interview processes need special care because candidates are frequently asked to demonstrate setup steps, which can be abused if the workflow is not tightly scripted. In contractor-heavy or BYOD environments, security teams may have less control over the endpoint, so verification and containment matter more than attempting to guarantee a clean device.

For broader threat context, current reporting such as the Anthropic — first AI-orchestrated cyber espionage campaign report shows how AI-assisted social engineering can scale believable interaction. That does not change accountability, but it does raise the bar for verification because polished language and rapid improvisation can make a request seem legitimate. Organisations should treat unusual urgency, secrecy, or requests to “just run this once” as warning signs, and they should reinforce that no interview or meeting outcome depends on executing unknown code. When the process depends on unmanaged exceptions, social engineering will usually win before the security team ever sees an alert.

Related resources from NHI Mgmt Group

• Who should be accountable when authenticated users abuse access after a social engineering attack?
• Who is accountable when social engineering leads to credential compromise?
• Who is accountable when a social engineering call leads to SSO compromise?
• Who is accountable when social engineering defeats identity controls?