AI agent security best practices expose the identity gap

At a glance

What this is: This article argues that AI security best practices must be built around identity-first controls, least privilege, monitoring, and compliance because AI agents and LLMs create dynamic attack surfaces that traditional perimeter models cannot govern.

Why it matters: IAM, PAM, and NHI teams need to treat AI agents as governed identities because their access can expand, persist, and move across cloud services faster than human-centric review cycles can track.

By the numbers:

• AI related security incidents cost enterprises an average of $4.88 million per breach, with recovery times extending 38% longer than traditional attacks.
• A 2024 OWASP study found that 67% of deployed LLM applications contained at least one exploitable prompt injection vulnerability.
• 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.

👉 Read Obsidian Security's analysis of AI security best practices for enterprise agents

Context

AI security best practices are the set of controls that protect AI systems from unauthorized access, data leakage, model manipulation, and adversarial misuse. The primary identity question is not whether the model is intelligent, but whether the identities behind it can be governed with the same discipline as human users, service accounts, and other non-human identities.

The gap appears when AI systems move from passive tools to active actors across cloud platforms and SaaS environments. In that setting, static permissions, shared credentials, and weak auditability fail because the runtime behaviour of agents, prompts, and token usage changes the access pattern continuously, often faster than existing IAM and PAM review cycles can see.

For AI agent programmes, the issue is no longer only model safety. It is whether identity controls, authorization logic, and monitoring can keep pace with systems that request data, invoke tools, and persist across workflows while still producing an auditable chain of responsibility.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do AI agents create a different access-risk profile than traditional applications?

A: AI agents can chain actions, call multiple tools, and change behaviour based on context, so one credential can enable more than one operational path. That means the risk is not just whether the agent authenticates, but how far it can move once inside. The key measure is privilege scope, not token count.

Q: What breaks when AI agent access is not re-evaluated in real time?

A: The main failure is privilege drift. An agent can start with a valid purpose, then continue into higher-risk actions after the original context has changed. Without re-evaluation, defenders lose the chance to stop unsafe tool use, delegated escalation, or access to systems that were never meant to be in scope.

Q: Who is accountable when an AI agent accesses sensitive data it was not meant to use?

A: Accountability sits with the team that approved the agent, its connectors, and its policy boundaries, not with the runtime behaviour alone. Organisations need ownership for intent, permissions, monitoring, and validation so they can prove whether the agent stayed inside its approved purpose. Without that, audit and regulatory response become retrospective guesswork.

Technical breakdown

Why AI agent identity needs separate governance

AI agents are not just another workload because they can request data, call tools, and act across multiple systems with privileges that often outlive the original business task. That creates a governance problem for IAM and NHI controls built around stable subjects, predictable lifecycles, and human review. The correct unit of control is the agent identity, not the model alone, because identity is what determines what can be accessed, logged, and revoked. Without a distinct identity per agent, shared access becomes impossible to attribute or constrain.

Practical implication: Create a unique identity for each AI agent and treat it as a governed non-human identity with named ownership and revocation paths.

How least privilege changes when AI systems can act dynamically

Least privilege for AI agents is not a one-time provisioning decision. It must be evaluated against current task scope, current data sensitivity, current tool access, and current runtime context because agents may chain actions that were not explicitly anticipated at design time. This is why static roles alone are inadequate for AI workloads. A policy model that supports contextual authorization, short-lived access, and explicit action gating is closer to the actual risk profile than broad standing permissions.

Practical implication: Scope agent permissions to the task and time window, and require re-authorization when the agent changes context or access path.

What real-time monitoring must detect in AI workloads

AI security monitoring has to detect behavioural change, not just known bad indicators. Useful signals include unusual API call patterns, unexpected data access sequences, token spikes, and anomalous inference activity because compromised or misused agents often look legitimate at the credential layer. That makes SIEM and SOAR integration necessary but not sufficient. The security team needs telemetry that links identity, access, action, and output so that the runtime can be quarantined before data leaves the environment or the agent starts to operate outside intended policy boundaries.

Practical implication: Instrument AI platforms for identity-linked telemetry and trigger containment when access patterns diverge from baseline behaviour.

Threat narrative

Attacker objective: The attacker aims to turn AI agent access into a scalable route for data theft, unauthorized actions, and broader platform compromise.

1. Entry occurs when an attacker reaches an AI platform through a compromised API key, shadow SaaS deployment, or another unmanaged access path tied to the agent environment.
2. Escalation follows when the agent or associated token can query broader datasets, invoke tools, or move into systems beyond the intended task scope.
3. Impact is realised when the compromised access enables data leakage, model abuse, or lateral movement across cloud and SaaS services before detection can occur.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

AI agent governance is becoming an identity control problem before it is a model risk problem. The article makes clear that AI systems do not fail only because outputs are unsafe. They fail because identities, tokens, and access paths are easier to abuse than the models they protect. For IAM and NHI teams, that means governance starts at identity issuance, not at model review.

Least privilege for AI agents is not stable enough to be defined once at provisioning time. AI systems request data, tools, and downstream services in ways that shift with context and prompt content. That breaks the assumption that access scope can be fully understood before execution begins, which is why static entitlements are a weak fit for agentic workloads. Practitioners should treat authorization as a runtime discipline, not a provisioning artefact.

Runtime monitoring must be identity-linked or it will miss the real failure mode. The article's focus on anomaly detection, SIEM, and automated response is directionally correct, but the critical insight is that agent telemetry has to tie identity to action and action to data use. Without that chain, security teams can see noise without knowing which agent created it. The practical conclusion is that observability has to support attribution, not just alerting.

Shadow AI is the same governance failure pattern that NHI teams already know from unmanaged service accounts. Unreviewed AI tools, overly broad SaaS permissions, and weak lifecycle control create the same accountability gap that appears when machine identities are not inventoried or offboarded. The difference is that AI agents can expand their own access patterns faster, so the governance gap compounds in runtime. Organisations should treat unmanaged AI as an identity inventory and lifecycle failure, not just an application sprawl issue.

Identity blast radius is the right named concept for AI security programmes. A single compromised API key, token, or service account can expose models, data, and connected systems far beyond the original request boundary. That is the same structural issue NHI teams manage in other machine-identity contexts, but AI agents increase the speed and spread of abuse. The practitioner conclusion is that blast-radius reduction must be the primary design objective for AI identity governance.

From our research:

• 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.
• From our research: 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface.
• From our research: Use the OWASP NHI Top 10 to translate agent identity risk into controls that security, IAM, and governance teams can operationalise.

What this signals

Identity blast radius is becoming the deciding metric for AI programmes. With 80% of organisations already reporting AI agents acting beyond intended scope, the programme question is no longer whether agents should exist. It is whether your IAM and PAM model can absorb runtime access change without creating ungoverned spillover across SaaS and cloud services. For most teams, the answer will depend on how fast they can move from shared credentials to per-agent accountability.

Shadow AI now needs to be treated like shadow NHI. Unmanaged agents, hidden integrations, and unsanctioned SaaS tools are the same structural blind spot that machine identity programmes have been fighting for years. The difference is that AI can amplify the blast radius before anyone notices, which makes inventory, ownership, and revocation the first operational priorities, not the last.

Agentic AI identity should be aligned to external control frameworks early. The NIST AI Risk Management Framework and OWASP Agentic AI Top 10 both reinforce the need for governance, monitoring, and misuse resistance. Organisations that map these controls now will be better positioned to prove accountability when auditors ask who authorized the agent, what it touched, and when its access ended.

For practitioners

• Assign each AI agent a unique identity Bind every agent to a distinct non-human identity, never a shared API key or generic service account. Maintain ownership, scope, and revocation records so each action can be attributed and disabled without affecting unrelated workflows.
• Move authorization to runtime policy Evaluate each agent request against task scope, data sensitivity, and current risk rather than relying only on preassigned roles. Recheck permissions whenever the agent changes context, calls a new tool, or reaches a new dataset.
• Shorten credential lifetime aggressively Use task-scoped, short-lived credentials for AI platforms and service accounts, with immediate revocation paths for abnormal behaviour. Treat any persistent token as a standing privilege problem until proven otherwise.
• Link monitoring to identity and data use Correlate agent identity, API calls, accessed data, and output events in SIEM and SOAR workflows. Alert on anomalous access sequences, token spikes, or cross-system movement that indicate an agent has exceeded its intended scope.
• Inventory shadow AI alongside other NHIs Catalogue unsanctioned AI tools, hidden integrations, and unmanaged agent workflows in the same inventory used for service accounts and secrets. Without that inventory, you cannot offboard, certify, or monitor the full agent estate.

Key takeaways

• AI security is now an identity governance problem because agents can request, chain, and persist access in ways static controls were not designed to handle.
• The evidence points to a material control gap, with most organisations reporting agent behaviour outside intended scope and many still lacking full audit visibility.
• Teams that want to reduce AI risk need per-agent identity, runtime authorization, and identity-linked monitoring before the estate expands further.

Key terms

• AI Agent Identity: The digital identity used by an autonomous AI agent to authenticate to external systems, APIs, and services. Managing AI agent identities is an emerging and rapidly evolving area of NHI security.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

What's in the full article

Obsidian Security's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step control guidance for AI agent identity, least privilege, and token lifecycle management.
• Specific monitoring patterns for prompt injection, anomalous tool use, and runtime data access.
• Implementation examples for authentication, authorization, and compliance mapping across AI platforms.
• Practical deployment detail for integrating AI logs with SIEM and SOAR workflows.

👉 Obsidian Security's full article covers identity controls, runtime monitoring, and compliance mapping in more implementation detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM, PAM, or identity governance programme, it is worth exploring.