How can organisations reduce the risk of insiders approving attacker actions on behalf of a criminal group?

Organisations should combine least privilege with strong behavioral monitoring and approval governance. Restrict who can approve sensitive actions, flag out of pattern requests, and correlate approvals with user history and business need. If an approval or command does not fit the person’s normal behavior, investigate immediately. The objective is to catch the trusted account working for someone else.

Why This Matters for Security Teams

When an insider is induced, coerced, or compromised into approving attacker actions, the control failure is not just access. It is trust in the approver workflow itself. A valid login or familiar name can mask malicious intent, especially when the request is small, urgent, or routed through a business process that already normalises exceptions. Current guidance suggests treating approvals as security events, not administrative courtesy.

The risk is amplified because attacker operations often blend into legitimate work. The same account that approves a vendor payment, code deployment, or privileged session may also be used to authorise a harmful action if the workflow lacks strong context, separation of duties, and behavioural review. NIST CSF 2.0 reinforces the need to govern identity and access decisions continuously, while MITRE ATT&CK helps teams model how adversaries abuse valid credentials and trusted processes. NHI research from 52 NHI Breaches Analysis shows how quickly trusted identities become a liability once control is lost.

In practice, many security teams discover approval abuse only after the authorised action has already been executed and the trusted account has done exactly what the attacker needed.

How It Works in Practice

Reducing this risk requires designing approvals so that a human requestor cannot easily become a blind proxy for an attacker. The first step is to narrow which roles can approve high-impact actions, then require step-up verification when the request is unusual, sensitive, or outside the approver’s normal pattern. Approval paths should also be separated from execution paths so that the person who can request or stage an action is not automatically the person who can bless it.

Behavioural monitoring should correlate approvals with historical patterns, device posture, time of day, location, workload, and business context. If an engineer who normally approves routine changes suddenly authorises a privileged export, a new API key, or a lateral movement step, that event should trigger review. This is especially important in environments where social engineering, session hijacking, and token theft are already observed attack paths, as described in the Ultimate Guide to NHIs — Key Challenges and Risks.

• Use least privilege for approvers, not just executors.
• Require dual approval for actions with irreversible impact.
• Compare every approval against user history and business justification.
• Alert on approvals that arrive from atypical devices, sessions, or geographies.
• Log the full decision context so investigators can reconstruct intent later.

For organisations building stronger monitoring pipelines, the CISA cyber threat advisories and MITRE ATT&CK Enterprise Matrix are useful references for mapping trusted-account abuse to known adversary techniques. These controls tend to break down when approval tools are fragmented across chat, email, and ticketing systems because investigators cannot reliably reconstruct who approved what, when, and under which context.

Common Variations and Edge Cases

Tighter approval controls often increase friction for legitimate work, so organisations have to balance speed against resilience. That tradeoff is real in operations, incident response, and finance workflows where delayed approvals can create business impact. Best practice is evolving, but there is no universal standard for this yet: some organisations rely on risk scoring and delegated approval chains, while others enforce hard blocks for specific action classes.

One common edge case is the privileged insider who is also the legitimate owner of the workflow. In those cases, trust should not be absolute. Organisations should use periodic recertification, exception expiry, and independent review of approval logs. Another edge case is account takeover without a role change, where the attacker uses the insider’s normal approval authority. That is why approval governance must be paired with anomaly detection and session assurance, not only RBAC. NHI incidents documented in JetBrains GitHub plugin token exposure and the vendor-reported findings in Anthropic — first AI-orchestrated cyber espionage campaign report both reinforce the same lesson: trusted access is often the attacker’s preferred route.

For board and control owners, the practical question is not whether approvals exist, but whether the approval system can distinguish normal authority from coerced authority fast enough to stop abuse before execution.

Related resources from NHI Mgmt Group

• How should organisations strengthen password policies to reduce breach risk in business environments?
• How should organisations unify identity verification, authentication, and recovery to reduce account takeover risk?
• Which controls should organisations combine with browser fingerprinting to reduce account takeover risk?
• Why does authorization matter so much when organisations are trying to reduce identity-related risk?