Notifications
Clear all
Topic starter
01/08/2026 10:50 pm
TL;DR: As AI copilots, assistants and autonomous agents become embedded in workflows, attackers are targeting the human-AI interaction layer through prompt injection, impersonation and social engineering, according to KnowBe4. The security gap is no longer just access control, but governance for how humans and AI systems influence each other in production.
NHIMG editorial — based on content published by KnowBe4: Securing the Hybrid Workforce: Protecting Humans and AI Agents in a New Era
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities , 46% confirmed, 26% suspected.
Questions worth separating out
Q: How should security teams govern AI-enabled workflows that can act on their own?
A: Treat them as identity-governed execution paths, not just software features.
Q: Why do AI agents increase non-human identity risk?
A: AI agents increase non-human identity risk because they can execute many actions quickly once they inherit a credential or tool permission.
Q: What do organisations get wrong about AI prompt injection risk?
A: Organisations often treat prompt injection as a text-only problem, when it is really an execution problem.
Practitioner guidance
- Map AI-enabled workflows to their backing identities Inventory every assistant, copilot and agent that can access enterprise data, then bind each to the service account, token or user context it uses.
- Separate advice from execution in AI-assisted processes Allow AI systems to draft, summarise or recommend, but require explicit guardrails before they can submit, modify or trigger actions that affect access, records or transactions.
- Add prompt-injection and impersonation controls Use content filtering, tool-use restrictions and channel validation to reduce the chance that manipulated prompts or synthetic messages can drive unsafe behaviour in AI systems or employee workflows.
What's in the full article
KnowBe4's full whitepaper covers the operational detail this post intentionally leaves for the source:
- Concrete examples of human-AI attack paths and the control points they exploit
- Practical guidance on reducing automation bias and improving digital mindfulness
- Operational ideas for discovery, monitoring and protection in AI-enabled environments
- Policy and governance considerations for scaling controls across human and AI collaboration
👉 Read KnowBe4's whitepaper on securing the human-AI attack surface →
Human-AI attack surface: what IAM and security teams need now?
Explore further
01/08/2026 10:58 pm
AI governance is becoming an identity problem, not just a model-risk problem. Once AI assistants are embedded in production workflows, they influence actions, data access and trust decisions in ways that belong in the identity control plane. That means IAM, PAM and NHI teams cannot treat AI usage as an adjacent concern. They need governance for who or what can act, on whose behalf, and with what data scope. The practitioner conclusion is clear: AI oversight must be mapped into identity governance, not parked beside it.
A question worth separating out:
Q: Who is accountable when an AI agent causes a security incident?
A: Accountability should sit with the business owner, the system owner, and the security function together, because agent behaviour crosses operational boundaries. Organisations need a defined owner for approval, monitoring, and retirement, plus audit evidence that shows what the agent accessed and why.
👉 Read our full editorial: Securing the human-ai attack surface now needs dual governance
