Notifications
Clear all
Topic starter
10/06/2026 10:40 pm
TL;DR: AI agents that can book travel, manage calendars, and move across accounts are becoming attractive targets because hijacked agents can still look legitimate to the outside world, according to SumSub. The identity problem is no longer just access, but proving whether an action came from the intended agent or a compromised one, which breaks trust models built for human users.
NHIMG editorial — based on content published by SumSub: AI agent hijacking, Know Your Agent, and trusted automation risk
Questions worth separating out
Q: How should security teams govern AI agents that act on behalf of users?
A: Security teams should govern AI agents as delegated identities with explicit scope, lifecycle ownership, and runtime monitoring.
Q: Why do AI agents create a new identity risk for IAM programmes?
A: AI agents create a new identity risk because they can perform valid-looking actions across multiple systems while still appearing legitimate to the outside world.
Q: What breaks when an AI agent is hijacked but still looks trusted?
A: What breaks is the assumption that a trusted session implies a trusted actor.
Practitioner guidance
- Inventory all user-delegated agents Map every AI agent that can act on behalf of a person, including calendar, travel, finance, and support workflows.
- Reduce cross-platform authority Limit each agent to the smallest possible task scope and separate high-risk actions from low-risk convenience workflows.
- Add runtime behaviour checks for agents Monitor for prompt anomalies, unusual action sequences, and repeated requests that do not match the expected task pattern.
What's in the full article
SumSub's full research coverage leaves the operational detail for readers who need implementation specifics:
- How to distinguish legitimate agent behaviour from hijacked behaviour across connected platforms
- Why Know Your Agent adds a runtime trust layer that traditional identity checks do not provide
- Which fraud and IAM controls need to share ownership when agents can act on behalf of users
👉 Read SumSub's analysis of AI agent hijacking and Know Your Agent →
AI agent hijacking: what it means for IAM teams and fraud controls?
Explore further
11/06/2026 2:48 am
AI agent hijacking is an identity assurance failure, not just a fraud event. The outside world often sees a valid workflow, a trusted account, and a normal-looking action trail, which is exactly why the compromise is hard to detect. That makes agent identity different from human sign-in assurance, because the trust boundary extends into runtime behaviour. Practitioners should treat agent integrity as part of identity governance, not as an adjacent monitoring problem.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
A question worth separating out:
Q: Who should own response when an AI agent is compromised?
A: Ownership should sit across IAM, fraud, and application security, because the compromise can affect identity trust, customer impact, and workflow integrity at the same time. The response should include token revocation, connector shutdown, and review of all actions the agent performed while compromised.
👉 Read our full editorial: AI agent hijacking exposes the identity gap in trusted automation
