AI agent identity risk is outpacing permission-based controls

At a glance

What this is: This analysis says AI agents can act dangerously even when every policy check says they are authorised.

Why it matters: It matters because IAM, PAM, and NHI programmes must now detect behavioural abuse inside permitted access, not just block unauthorised access.

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.

👉 Read AuthMind's analysis of rogue and anomalous AI agent behaviour

Context

AI agent identity risk starts when organisations assume granted access equals safe access. In practice, an agent can stay inside its permission boundary and still exfiltrate data, pivot into unused roles, or retrieve secrets through a misconfigured path.

That creates an identity governance gap that sits between authorisation and behaviour. For IAM teams, the question is no longer only who is allowed in. It is also whether an AI agent is behaving within the intent of the access it already has.

Key questions

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. An AI agent can remain within granted permissions while exfiltrating data, retrieving secrets, or assuming roles in unusual ways. Security teams need behavioural baselines and cross-event correlation, not just allow or deny decisions.

Q: Why do AI agents complicate IAM and PAM governance?

A: They complicate governance because access can be valid while intent is drifting. IAM and PAM tools are strong at defining entitlement boundaries, but AI agents can operate inside those boundaries in abnormal sequences that look legitimate event by event. That means identity assurance must include runtime behaviour, not only stored permissions.

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. A single event may be harmless, but a correlated sequence is often the signal that the agent is acting beyond intent.

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.

Technical breakdown

Authorised but anomalous AI agent behaviour

Traditional policy checks answer a narrow question: did the request match the permission set at the moment of evaluation? For AI agents, that is insufficient because the risk often emerges after authorisation, through unusual volume, unusual sequencing, or unusual role use. An agent may be technically allowed to read data, retrieve secrets, or assume a role, yet still operate outside the expected behavioural envelope. That is why permission state and behavioural state must be treated as separate control planes.

Practical implication: pair access policy with behavioural baselines so permitted actions can still trigger investigation when the pattern changes.

Why unmanaged agents evade identity governance

AuthMind's point is that a large share of AI apps and services operate outside IdP, PAM, or secrets management, which means the organisation has no authoritative inventory, no lifecycle control, and no baseline to compare against. In identity terms, an unmanaged agent is invisible to the very systems that would normally anchor recertification, offboarding, and scope review. That makes drift hard to detect and harder to explain after the fact.

Practical implication: inventory AI agents first, then attach them to an identity control plane before treating them as governed assets.

Correlation across the full access chain

Anomalous agent activity rarely appears as a single red flag. It is usually a sequence, such as an impersonation event, followed by secret retrieval, followed by an external connection that seems routine in isolation. Detection therefore depends on correlating identity events across the full execution context, not scoring individual events one by one. That is the architectural difference between basic monitoring and identity observability for agentic systems.

Practical implication: build detections that correlate sequence, role use, secret access, and destination together rather than alerting on each event independently.

Threat narrative

Attacker objective: The objective is to use valid AI agent access to move, retrieve, or exfiltrate data without crossing an explicit policy boundary.

1. Entry occurs when an AI agent operates with legitimate credentials and sanctioned access, so the initial request passes normal policy checks.
2. Escalation happens when the agent uses that access in an unexpected way, such as assuming an unused role, retrieving secrets, or expanding into paths outside its normal behavioural profile.
3. Impact follows when the same authorised identity quietly exfiltrates data, performs lateral reconnaissance, or reaches external endpoints without triggering a traditional access alert.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Unmanaged agent populations create governance blind spots, not just inventory gaps: When more than 65% of AI apps and services are outside IdP, PAM, or secrets management, the organisation loses the ability to baseline, recertify, or offboard them with confidence. This is a structural control failure because the system cannot govern what it cannot see. Practitioners should read this as a lifecycle and observability problem, not a tooling gap alone.

Authorized-but-dangerous behaviour is a named failure mode, not an edge case: The specific governance concept here is permitted-but-dangerous AI agent activity. That failure mode describes sessions that satisfy policy while violating intent through abnormal volume, unusual role selection, or secret retrieval through a misconfigured path. The implication is that identity programmes must distinguish permission validity from behavioural legitimacy.

Behavioural correlation is now part of identity assurance: Single-event evaluation is too weak for agentic systems because the real signal emerges across a chain of actions. Identity security for AI agents therefore depends on linking impersonation, role use, secret access, and egress into one interpretive model. Practitioners should assume the next material risk will look normal in isolation and abnormal only in sequence.

AI agent governance now sits at the intersection of NHI and autonomous risk: Even when the agent is not fully autonomous, its runtime behaviour can still outpace static access models. That creates a bridge issue across NHI governance, IAM controls, and emerging agentic oversight. The implication is that identity teams need a shared operating model for machine credentials, delegated access, and behavioural trust.

From our research:

• 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.
• From our research: 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.
• That is why OWASP Agentic AI Top 10 is a useful next reference for teams mapping agent behaviour, tool misuse, and identity abuse into one governance model.

What this signals

Permitted-but-dangerous AI agent behaviour is now a programme design issue, not a detection afterthought: if the control model only asks whether access was authorised, it will miss the cases that matter most. With more than 65% of AI apps and services unmanaged, the organisation may not even know which agents need behavioural baselines or lifecycle review.

The practical shift is toward identity observability for agentic systems. Teams should expect to connect behavioural telemetry to governance workflows, including recertification, exception handling, and offboarding for AI services that were previously treated as infrastructure.

The next maturity step is to treat agent access as both an entitlement and a pattern of behaviour, then align that model with OWASP Agentic AI Top 10 and NIST AI Risk Management Framework guidance where autonomous decision-making is in play.

For practitioners

• 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. Without that baseline, behavioural drift cannot be measured or explained.
• 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. Isolated alerts will miss the pattern.
• 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. The two controls answer different questions.
• Bring unmanaged AI services under identity control Attach AI apps and agent services to IdP, PAM, or secrets governance where possible so there is an authoritative control point for lifecycle, access scope, and revocation.

Key takeaways

• AI agents can be fully authorised and still represent an active security failure when their behaviour drifts beyond intended use.
• The biggest exposure is not only unauthorised access, but unmanaged agent populations that sit outside identity control planes.
• Identity teams need behavioural baselines, event correlation, and lifecycle control for agents, not just permission checks.

Key terms

• Permitted-but-dangerous behaviour: Access that remains within approved permissions but still creates security risk because the identity behaves in unexpected or malicious ways. For AI agents, this often means unusual sequencing, abnormal volume, secret retrieval, or role use that policy checks do not flag.
• Behavioural baseline: A reference profile of how an identity normally acts across access, sequence, destination, and resource use. For AI agents, the baseline must include runtime context so the programme can detect drift that ordinary allow or deny checks will miss.
• Identity observability: The practice of correlating identity events across systems so access can be understood as a sequence, not a collection of isolated alerts. In AI agent governance, it is the mechanism that exposes abuse hidden inside otherwise authorised sessions.

Deepen your knowledge

AI agent identity risk and behavioural governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for unmanaged agents or permitted-but-dangerous behaviour, it is worth exploring.

This post draws on content published by AuthMind: LLMjacking and anomalous AI agent behaviour. Read the original.