Notifications
Clear all
Topic starter
10/06/2026 12:18 am
TL;DR: AI agents can remain fully authorised while exfiltrating data, assuming unused roles, or pulling secrets through misconfigured paths, and AuthMind says more than 65% of AI apps and services are unmanaged outside IdP, PAM, or secrets controls. Permission checks alone cannot govern behaviour that drifts within granted access.
NHIMG editorial — based on content published by AuthMind: LLMjacking and anomalous AI agent behaviour
By the numbers:
- 65% of these AI apps and services, d services, including agentic ones, are unmanaged, meaning they're not connected to an IdP, PAM system, or secrets manager.
Questions worth separating out
Q: What breaks when AI agents are only checked for authorised access?
A: The control breaks because authorisation proves only that a request matched policy, not that the behaviour was safe.
Q: Why do AI agents complicate IAM and PAM governance?
A: They complicate governance because access can be valid while intent is drifting.
Q: How do you know if an AI agent is operating outside its intended scope?
A: Look for repeated patterns such as unusual volume, new role usage, unexpected secret retrieval, or access paths that do not match the agent's normal baseline.
Practitioner guidance
- Baseline every AI agent before granting broad access Create an inventory of agents, their proxy users, their roles, their secret dependencies, and their normal destination patterns.
- Correlate identity events across the full execution chain Join impersonation, role assumption, secret retrieval, and network egress in one detection path so the sequence can be evaluated as a single identity event.
- Separate permission review from behavioural review Keep access recertification for entitlements, but add a distinct behavioural review process for agents that are allowed to act continuously within those entitlements.
What's in the full article
AuthMind's full analysis covers the operational detail this post intentionally leaves for the source:
- Behavioral observability patterns for detecting anomalous AI agent access across the full execution chain
- Examples of how agents can stay authorized while still performing lateral reconnaissance or secret retrieval
- The detection logic used to correlate impersonation, role use, and external connections into one identity signal
- Operational context on how the vendor maps AI agent access activity across its execution context
👉 Read AuthMind's analysis of rogue and anomalous AI agent behaviour →
AI agent behavioural drift is the governance gap teams miss?
Explore further
11/06/2026 2:01 am
Authorised access is not the same as safe access: AI agents break the old IAM assumption that a valid permission check is enough to declare the session benign. An agent can remain entirely within granted entitlements while still behaving in ways that indicate data theft, role abuse, or covert reconnaissance. The implication is that governance must treat behaviour as a first-class identity signal, not a secondary logging problem.
A few things that frame the scale:
- More than 65% of these AI apps and services, including agentic ones, are unmanaged, meaning they're not connected to an IdP, PAM system, or secrets manager, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who should own AI agent behaviour monitoring in an identity programme?
A: Identity, security operations, and platform teams need a shared model, but identity governance should own the policy and lifecycle side. Security operations should own the detection logic, while platform teams provide the inventory and execution context. Without that split, anomalous behaviour will stay outside accountable control.
👉 Read our full editorial: AI agent identity risk is outpacing permission-based controls
12/06/2026 3:35 am
Authorised access is not the same as safe access: AI agents break the old IAM assumption that a valid permission check is enough to declare the session benign. An agent can remain entirely within granted entitlements while still behaving in ways that indicate data theft, role abuse, or covert reconnaissance. The implication is that governance must treat behaviour as a first-class identity signal, not a secondary logging problem.
A few things that frame the scale:
- More than 65% of these AI apps and services, including agentic ones, are unmanaged, meaning they're not connected to an IdP, PAM system, or secrets manager, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who should own AI agent behaviour monitoring in an identity programme?
A: Identity, security operations, and platform teams need a shared model, but identity governance should own the policy and lifecycle side. Security operations should own the detection logic, while platform teams provide the inventory and execution context. Without that split, anomalous behaviour will stay outside accountable control.
👉 Read our full editorial: AI agent identity risk is outpacing permission-based controls
