Subscribe to the Non-Human & AI Identity Journal
Home FAQ Threats, Abuse & Incident Response What do organisations get wrong about AI-related cybercrime?
Threats, Abuse & Incident Response

What do organisations get wrong about AI-related cybercrime?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated June 27, 2026 Domain: Threats, Abuse & Incident Response

They often focus on the novelty of the tool instead of the control failure that still matters most. The real issue is whether exposed secrets, over-permissioned accounts, or weak approval flows let AI-generated attacks become authenticated action. If those identity controls are weak, the model label is secondary.

Why This Matters for Security Teams

AI-related cybercrime is often misread as a model problem when it is usually an identity and control problem. Attackers do not need to “beat” the AI if they can steal a token, abuse a service account, or exploit a weak approval path. That is why guidance from CISA cyber threat advisories and NHIMG research on LLMjacking keeps pointing back to the same failure mode: authenticated misuse at machine speed.

The practical mistake is assuming new attack language requires new root-cause analysis. In reality, AI-generated phishing, prompt injection, agent misuse, and automated recon all become far more damaging once a system has standing access to secrets, APIs, or privileged workflows. NHIMG’s The State of Secrets in AppSec shows how fragmented secret management still is, which matters because fragmented controls are exactly what attackers exploit. In practice, many security teams encounter AI-related cybercrime only after a valid credential has already been used to move from message generation to actual compromise.

How It Works in Practice

What organisations get wrong is treating AI as the attacker, rather than the accelerant. The model may generate convincing lures, discover weak points, or chain actions, but the compromise usually happens when an exposed secret, over-permissioned workload, or unsafe approval flow converts that output into action. The most effective response is therefore to reduce what AI-linked systems can do by default and to make access conditional at runtime.

That means short-lived credentials, workload identity, and policy checks at the moment of request. For agents and automated workflows, static RBAC alone is often too blunt because the agent’s next step is not fully predictable. Current guidance suggests combining intent-aware authorisation with ephemeral tokens so a task can be permitted only for the narrow context in which it is valid. Standards work such as MITRE ATLAS adversarial AI threat matrix helps teams map how attackers weaponise AI-assisted tradecraft, while NHIMG’s The 52 NHI breaches Report shows how identity failure is repeatedly the entry point.

  • Issue credentials per task, not per environment, and revoke them when the job ends.
  • Bind agents to workload identity so access reflects what the workload is, not what the prompt says.
  • Evaluate policy at request time, using context such as tool, target system, and risk level.
  • Segregate secrets so one leaked token does not unlock an entire automation chain.

These controls tend to break down when legacy automation, shared service accounts, and manual exception handling are all present in the same environment because there is no clean boundary for runtime authorisation.

Common Variations and Edge Cases

Tighter credential controls often increase operational overhead, requiring organisations to balance faster automation against tighter blast-radius reduction. That tradeoff is real in environments with high-volume CI/CD, shared integration platforms, or agentic workflows that need rapid tool switching. Best practice is evolving, but one point is already clear: long-lived secrets and broad entitlements create the conditions for AI-assisted abuse, even when the underlying model is benign.

There are also edge cases where the threat is not direct exfiltration but secondary misuse. For example, an AI system may be used to generate believable internal messages, then hand off to a compromised account that performs the actual action. In other cases, an agent may chain low-risk tools into a high-risk outcome because no single step looked abnormal. That is why organisations should treat Top 10 NHI Issues as an operational checklist, not a taxonomy exercise, and why threat briefings such as Anthropic’s AI-orchestrated cyber espionage report matter for pattern recognition.

Where this guidance breaks down most often is in heavily decentralised environments with unmanaged secrets sprawl, because no single team can see or revoke every credential path in time.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10A2Covers agent misuse and tool abuse, central to AI-driven cybercrime.
CSA MAESTROT1Addresses agent trust, delegation, and runtime control for autonomous systems.
NIST AI RMFAI RMF governance fits the need for accountability and risk treatment.

Assign ownership for AI-linked abuse paths and validate controls continuously.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on June 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org