Who is accountable when employees are tricked into authorising a malicious workflow?

Why This Matters for Security Teams

When employees are tricked into approving a malicious workflow, the immediate mistake is human, but the failure is usually systemic. Attackers target approval paths because they know organisations often treat workflow sign-off as routine rather than as a security control. That turns a single click into authorisation for secret access, deployment, data movement, or privilege escalation. NHI Mgmt Group’s guidance on the Ultimate Guide to NHIs shows why this matters: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

The accountability question matters because control owners cannot outsource risk to the person who was deceived. Security teams need to know who owns the workflow, who approved the trust boundary, who set the verification step, and who monitors for abuse after approval. Under NIST SP 800-53 Rev 5 Security and Privacy Controls, that responsibility maps to concrete control ownership, not informal awareness. In practice, many security teams encounter misuse only after a signed workflow has already moved secrets, not through intentional review of approval design.

How It Works in Practice

Accountability starts with treating the workflow itself as a privileged system component. If an employee can authorise a deployment, token grant, or connector install that creates access for an agent, service account, or CI/CD job, then the organisation must define who validates the workflow logic, who approves high-risk changes, and who can revoke the resulting access. The right model is usually layered:

• Business owners define what the workflow is allowed to do.
• Security owners define approval thresholds, logging, and detection.
• Platform owners enforce controls such as change review, scoped tokens, and time-bound access.
• Audit or risk teams verify that approval events are evidence, not just user intent.

This becomes especially important in agentic or automated environments, where a malicious workflow can chain actions faster than a human reviewer can notice. The attack pattern described in the GitHub Action tj-actions Supply Chain Attack shows how workflow trust can expose CI/CD secrets at scale. Current guidance suggests pairing human approval with policy checks, short-lived credentials, and monitoring tied to the actual resource being requested. Controls in NIST SP 800-53 Rev 5 Security and Privacy Controls support this by requiring authorisation, accountability, and continuous monitoring, but they still need operational ownership.

In mature environments, workflow approvals are also recorded as part of the change and identity trail, so investigators can see whether the user was socially engineered, whether the workflow lacked verification, and whether the platform allowed excessive standing access. These controls tend to break down when approval systems are disconnected from secrets governance, because the authorisation event and the credential issuance event happen in different tools.

Common Variations and Edge Cases

Tighter approval controls often increase friction, requiring organisations to balance speed against assurance. That tradeoff becomes most visible when employees need to approve urgent production changes, third-party integrations, or delegated admin actions. In those cases, the question is not whether the person clicked “approve,” but whether the organisation created a safe decision environment with meaningful context and bounded impact.

There is no universal standard for this yet in workflow-driven agentic environments, but current guidance suggests three common exceptions. First, if the employee was using an approved break-glass path with documented controls, accountability shifts toward the control owner rather than the approver alone. Second, if the workflow was intentionally misleading or lacked clear context, the design failure sits with the platform or product owner. Third, if monitoring failed to flag unusual post-approval behaviour, detection and response ownership becomes part of the accountability chain. NHI Mgmt Group’s broader research on non-human identity governance is relevant here because approval abuse often becomes credential abuse immediately after the event. Organisations that rely on a signed user action as proof of safety usually discover the real weakness only after secrets, tokens, or privileged workflows have already been consumed.

Related resources from NHI Mgmt Group

• Who is accountable when a public support workflow is abused for trusted-message spam?
• How should teams reduce risk from malicious npm package installs?
• Who is accountable when a customer is tricked into authorising a fraudulent payment?
• Who is accountable when a GitHub Actions workflow exposes secrets or pushes malicious code?