AI cybersecurity best practices need human risk governance

At a glance

What this is: This article argues that AI security failures often start with everyday human behaviour, not just model weaknesses, and that Human Risk Management ties those actions to AI risk.

Why it matters: It matters because IAM, PAM, and identity governance teams now have to watch how employees, service accounts, and AI workflows intersect when prompts, code, and data move across tools.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Living Security Human Risk Management Platform's blog on 9 AI cybersecurity best practices for your enterprise

Context

AI cybersecurity is not just a model-security problem. It becomes a governance problem as soon as employees, developers, and integrated tools start feeding prompts, code, and sensitive data into systems that can store, transform, or act on that information. In practice, the weak point is usually the boundary between human behaviour and machine action.

That boundary also matters for identity teams. When access to AI tools, training data, and downstream systems is not tied to clear identity and privilege controls, organisations inherit the same problems they already know from secrets sprawl and over-privileged service accounts, only faster and harder to see.

Living Security Human Risk Management Platform frames the issue through human behaviour and AI risk correlation rather than through models alone. That starting point is increasingly typical for enterprises trying to move AI security out of isolated technical testing and into operational governance.

Key questions

Q: How should security teams govern generative AI tools that connect to core systems?

A: Treat them as non-human identities with lifecycle, access, and telemetry requirements. Assign an owner, limit privileges to the exact task, log every data flow they can trigger, and revoke access immediately when the business need ends. If a tool cannot be inventoried or monitored, it should not be connected to sensitive systems.

Q: Why do AI systems create identity and access risk beyond traditional AppSec?

A: Because AI systems often act through delegated access. When a model can use tools, retrieve data, or trigger actions, it becomes a runtime decision-maker with privileges that can be misused through prompt injection, poisoned context, or overbroad permissions. That is an identity problem as much as a code problem.

Q: Why are AI gateways not enough to stop prompt injection and data leakage?

A: AI gateways control where traffic goes, but they do not understand what the traffic means. Prompt injection, jailbreaks, and sensitive data leakage happen inside the content layer, so teams need inspection and policy enforcement that can evaluate the interaction itself, not only the network path.

Q: How can security teams tell whether AI lifecycle controls are working?

A: They should look for evidence that access requests, policy enforcement, and usage visibility are centrally recorded and current. If those signals are fragmented across platforms, the programme may be documenting governance rather than enforcing it. Continuous traceability is the practical test.

Technical breakdown

Why AI prompts and code create a new attack surface

Generative AI expands the attack surface because user input is no longer just text. A prompt can carry sensitive data, instructions, embedded secrets, or malicious control strings, and AI-generated code can propagate unsafe logic into production systems. Prompt injection and jailbreaking work by manipulating the model’s instruction hierarchy, while data leakage happens when users place confidential material into tools that retain, reuse, or expose it. The security failure is often not the model itself, but the ungoverned interface between users, data, and model outputs.

Practical implication: treat AI input and output paths as governed data flows, not casual user interactions.

How model training and third-party AI supply chains fail

AI systems inherit risk from the data and components around them. Training data can be poisoned, external models can arrive with hidden behaviour, and third-party libraries or APIs can introduce untracked dependencies into decision-making pipelines. Because models are probabilistic, a small contamination can produce persistent bad outcomes after deployment. This is why AI supply chain security now includes dataset integrity, model provenance, and versioned component inventories rather than only software patching.

Practical implication: validate dataset provenance and maintain an AI bill of materials for every external component.

Why identity and access controls still matter for AI security

AI security fails when access to prompts, datasets, model APIs, and administrative consoles is too broad. Least privilege, role-based access control, and behavioural monitoring are still the base layer, but they must be applied to AI workflows as well as to traditional applications. Identity correlation is especially important because a compromised employee account, service account, or API token can turn a low-risk interaction into model theft, data exposure, or unauthorised action. That is the identity bridge most AI programmes miss.

Practical implication: bind AI systems to identity governance, not just application security reviews.

Threat narrative

Attacker objective: The attacker wants to use trusted AI workflows to extract data, manipulate decisions, or pivot into connected systems without triggering conventional security controls.

1. Entry occurs when an employee, developer, or attacker injects a prompt, uploads data, or uses a compromised account to interact with an AI tool.
2. Escalation happens when the model processes untrusted input, leaks sensitive data, or executes unsafe actions through connected systems or APIs.
3. Impact follows when the output is used operationally, allowing data theft, fraudulent decisions, code injection, or wider compromise of downstream environments.

NHI Mgmt Group analysis

Human behaviour is now part of the AI attack surface. The strongest lesson in this article is that employees are already shaping AI risk every time they paste prompts, accept generated code, or connect tools to sensitive systems. That makes AI security inseparable from identity governance, because the path to compromise often runs through legitimate access rather than exotic exploits. Practitioners should stop treating AI use as a side channel and start treating it as governed enterprise activity.

AI security creates a new kind of governance debt. Organisations that adopt AI faster than they can inventory prompts, data flows, and access paths accumulate risk they cannot later reconstruct cleanly. The named concept here is AI governance debt: the backlog of ungoverned AI usage, hidden data exposure, and unreviewed access that grows faster than policy can catch up. The longer that debt persists, the harder it becomes to prove compliance or contain misuse.

Identity controls remain the most practical control plane for AI systems. The article is strongest when it links AI risk to identity and access rather than to model theory alone. That is the right lens for IAM and PAM teams, because AI tooling often inherits privilege from the humans and service accounts around it. The governance question is no longer whether AI is special, but whether existing identity controls can actually see and constrain its runtime behaviour.

Human Risk Management is a programme model, not a point solution. The article points to a wider operational truth: AI security programs fail when they live in one team and ignore behaviour elsewhere. Correlating employee behaviour, identity telemetry, and threat intelligence is the only way to make AI risk measurable across the enterprise. That should push security leaders toward integrated governance rather than isolated awareness campaigns.

AI monitoring must be designed for auditability, not just detection. A lot of AI security talk stops at spotting prompt injection or model misuse, but compliance teams need evidence they can actually investigate. Visibility into who used what, what data was touched, and what action was taken is what converts AI security from best effort to defensible control. Practitioners should measure whether their control set can support both response and audit.

What this signals

AI governance debt: enterprises that adopt AI faster than they can inventory prompts, access paths, and delegated actions will keep accumulating blind spots that become audit and incident-response problems later. That is why identity telemetry and behavioural controls now matter as much as model testing.

The programme signal for IAM and security teams is clear: AI security cannot remain a one-team initiative. It has to connect access governance, secrets management, threat monitoring, and user behaviour into one operating model, or the control stack will fail at the first delegation chain it cannot explain.

For practitioners

• Map AI usage to identity and access paths Inventory who can reach each AI tool, model endpoint, training dataset, and connected system, then align that access to least privilege and approval boundaries.
• Classify prompts and generated outputs as governed data Define which prompt content is prohibited, which outputs require review, and where sensitive data must be blocked, redacted, or retained for audit.
• Track AI credentials and API tokens as security assets Include model keys, service tokens, and automation credentials in the same rotation, revocation, and monitoring processes used for other secrets.
• Test for prompt injection and unsafe tool execution Run red-team scenarios that combine malicious prompts, data leakage attempts, and connected-system abuse so you can see where the workflow breaks.
• Build audit-ready evidence for AI activity Capture who accessed the system, what data was involved, and what action the AI took so investigations can reconstruct behaviour after the fact.

Key takeaways

• AI security problems often begin with ordinary user behaviour, which means governance has to cover prompts, code, and data as well as models.
• The evidence base now shows broad AI-agent misuse and weak policy adoption, so the gap is already operational rather than theoretical.
• Identity controls, auditability, and behaviour-aware monitoring are the practical controls that turn AI security into a managed programme.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Human Risk Management: The practice of managing how people interact with security controls, especially under pressure, distraction, or deception. It combines training, policy, and friction management so identity systems are still usable enough that users do not bypass them in day-to-day work.
• AI bill of materials: An inventory of the components used by an AI development environment, including models, plugins, hooks, skills, and agent integrations. It gives security teams visibility into what is operating in the stack so they can assess trust, dependency risk, and governance coverage.

What's in the full article

Living Security Human Risk Management Platform's full blog post covers the operational detail this post intentionally leaves for the source:

• Specific examples of how employee actions create AI risk across prompts, code, and connected tools
• Stepwise AI security best practices for data access, model hardening, and runtime monitoring
• Human Risk Management workflow detail for correlating behaviour, identity, and threat intelligence
• Practical guidance on turning AI usage into audit-ready security evidence

👉 The full Living Security Human Risk Management Platform post covers the AI lifecycle controls, Human Risk Management approach, and practitioner examples.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management for practitioners building control over machine-facing systems. It helps identity and security teams turn emerging AI usage into a governed part of the enterprise security model.