AI agent security ends where identity infrastructure begins

At a glance

What this is: This is a comparison of AI runtime security and identity infrastructure, with the central finding that model monitoring addresses model-layer threats while enterprise access control still depends on authentication and directory governance.

Why it matters: IAM, PAM, and NHI teams should treat AI security telemetry as complementary to identity controls, because runtime detection does not decide who is provisioned, deprovisioned, or authorised in the enterprise stack.

By the numbers:

• The company says it has raised $60 million in funding, including a $35 million Series A in March 2024 led by Evolution Equity Partners and Acrew Capital.
• WorkOS says its platform processes millions of authentication events monthly with 99.99% uptime SLAs.
• WorkOS states that its authentication platform supports 50+ identity providers for enterprise SSO.

Context

AI agent security has two different control planes: one for model behaviour and one for enterprise identity. Runtime detection can flag prompt injection, adversarial inputs, and model extraction, but those controls operate after the system has already started processing requests.

For enterprise applications, the governance gap is not just model compromise. It is whether the application has the authentication, directory sync, admin delegation, and auditability needed to decide who may use the system, who may provision access, and who is removed when access should end.

The article’s core distinction is architectural, not marketing-led: specialised AI security monitors the workload, while identity infrastructure governs access to the workload.

Key questions

Q: What breaks when AI runtime monitoring is treated as identity control?

A: The organisation loses the ability to govern who can access the application, provision tenants, or remove access when relationships change. Runtime monitoring may detect suspicious model behaviour, but it does not enforce sign-in policy, directory sync, or administrative accountability. That gap leaves access decisions outside the control layer that actually owns them.

Q: Why do autonomous agents increase identity risk even when the model is not compromised?

A: Because the risk sits in the permissions attached to the agent's identity, not only in the model's correctness. An overprivileged service account or token can let a normal agent perform damaging actions, and autonomy makes those actions faster and harder to unwind.

Q: How should security teams respond to the convergence of AI security and IAM?

A: They should treat AI security, cloud security, and IAM as one governance problem when identities can reach the same workloads. The first step is to map which humans, service accounts, and AI-enabled systems share access paths, then define ownership, review cadence, and expiry for each high-risk entitlement. Without that, the programme can see risk but not govern it.

Q: What is the difference between model-layer monitoring and access governance for AI systems?

A: Model-layer monitoring watches what the system does during execution, such as prompt injection or anomalous outputs. Access governance decides who may enter the system, what they may provision, and which tenant or service identity may act. The two controls are complementary, but they answer different security questions.

Technical breakdown

Runtime monitoring for AI agents and models

Runtime monitoring watches model inputs, outputs, and behavioural baselines to detect signs of compromise such as prompt injection, adversarial perturbations, data poisoning, or model extraction. In practice, this is a detection-and-response layer placed alongside model-serving infrastructure. It can block, sanitise, alert, or log when the request looks hostile or the model’s behaviour drifts from its expected profile. That makes it useful for ML workloads that process untrusted input or execute actions based on model output. It does not, however, establish who authenticated to the application or whether the caller should exist in the tenant at all.

Practical implication: Treat runtime monitoring as model-layer detection, not as a substitute for identity and access governance.

Enterprise authentication and directory sync

Enterprise authentication governs the human and organisational identity side of an application. SAML, OpenID Connect, and SCIM-style directory sync decide how users sign in, how groups are provisioned, and how access is removed when the source directory changes. This is the control plane that keeps application access aligned with the customer organisation’s source of truth. In B2B environments, that matters more than model security when the question is tenancy, admin responsibility, or offboarding. AI security tools do not replace these functions because they do not own the identity lifecycle, authorisation boundary, or admin delegation model.

Practical implication: Anchor enterprise AI applications in SSO, provisioning, and deprovisioning controls before adding model-specific tooling.

Why autonomous agents increase the identity burden

When AI systems take actions, call APIs, or interact with external systems, the identity problem expands beyond the model itself. The operational question becomes which application identity, tenant context, or delegated privilege allowed the action to happen. That is why AI agent security and identity infrastructure overlap only partially: the agent may be monitored for anomalous behaviour, but the permissions it uses still come from identity systems. In other words, runtime controls observe execution; identity controls determine whether execution was authorised. The two layers fail differently and must be governed differently.

Practical implication: Separate agent-behaviour monitoring from delegated access control, and review both before permitting production automation.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI security stops at the model boundary; identity governance starts at the access boundary. That distinction matters because runtime monitoring can see malicious prompts, adversarial inputs, and anomalous model behaviour only after a session begins. It cannot tell you whether the user, tenant admin, or service account should have been present in the first place. The implication is that practitioners must treat AI security as a workload-layer control, not a governance substitute.

Enterprise AI applications inherit the same identity architecture requirements as any other B2B system. SSO, directory sync, admin delegation, and audit logs are not optional add-ons when the application serves enterprise customers. They establish who is entitled to access, who manages the tenant, and how offboarding actually happens. That makes identity infrastructure foundational, while AI runtime monitoring remains a specialised control for a narrower risk class.

Autonomous behaviour creates an authorisation problem, not just a detection problem. A model can be monitored for suspicious output and still operate with excessive delegated access if the underlying identity is over-scoped. This is where AI agent governance intersects with NHI practice: the runtime layer can describe what the agent did, but identity determines what it was allowed to do. Practitioners should not collapse those into one control domain.

Runtime observability and access governance solve different failure modes. The article’s most useful contribution is the boundary it draws between specialised AI threat detection and enterprise identity infrastructure. That boundary is where procurement, architecture, and control ownership should be decided. Teams that blur it risk buying the wrong control for the problem they actually have.

Identity infrastructure is the control plane that makes AI usable in enterprise settings. If the application cannot provision users, enforce tenant boundaries, and remove access cleanly, model security alone cannot make it enterprise-ready. For practitioners, the decisive question is not whether the model can be monitored, but whether identity governance can still explain and constrain who is acting.

From our research library:

• Gartner predicts that more than 50% of successful cyberattacks against AI agents through 2029 will exploit access control weaknesses.
• Read next: AI Agent Identity Security Buyer's Guide

What this signals

Identity infrastructure remains the foundation of enterprise AI readiness. The practical decision is not whether runtime detection is useful, but whether the application can still prove who authenticated, who administered the tenant, and how access was removed. That is an identity governance question first, and an AI security question second.

Runtime monitoring is valuable only when it is layered under enforceable access control. If an AI system can be observed but not governed, the organisation can detect compromise without being able to explain authorisation. That leaves incident response with telemetry but not accountability.

Access control and agent behaviour should be reviewed as separate control domains. The more an AI system can call external APIs or take autonomous action, the more important it becomes to verify delegated privilege, not just model output. Practitioners should plan for both controls from the start.

For practitioners

• Define the control boundary between model monitoring and identity governance Document which risks are handled by AI runtime detection and which belong to authentication, provisioning, tenant administration, and offboarding. Use that boundary in architecture reviews so AI security tools are not mistaken for access-control infrastructure.
• Require enterprise identity controls before AI rollout Make SSO, SCIM-based directory sync, admin controls, and audit logging part of the minimum architecture for customer-facing AI applications. If those are missing, the application is not ready for enterprise procurement regardless of model security features.
• Review delegated permissions used by AI agents Inventory the application identities, API scopes, and tenant-level permissions that AI agents use to act on behalf of users or administrators. The goal is to ensure the agent’s runtime behaviour cannot outgrow the access granted to it.
• Separate security monitoring from authorisation evidence Preserve logs from model telemetry and identity events as distinct evidence streams so investigations can tell what the AI system did from who authorised the action. That separation helps with incident scoping, tenant accountability, and compliance reporting.

Key takeaways

• AI runtime detection helps with prompt injection, adversarial inputs, and model behaviour, but it does not govern access to the enterprise application itself.
• Enterprise AI deployments still need authentication, directory sync, admin delegation, and auditability to manage the identity side of the system.
• The architectural mistake is to treat model security and access governance as one control, when they protect different layers of risk.

Key terms

• AI Runtime Operations: AI runtime operations are the live execution processes that let a model respond to prompts, process inputs, and interact with data or tools. This phase matters for security because runtime access determines what the model can reach, what it can expose, and how much damage a compromised workflow can do.
• Enterprise Authentication Stack: The set of identity components an application uses to authenticate users, federate logins, and manage access at scale. In practice, it combines application login, directory integration, session handling, and administrative controls so the application can support enterprise requirements without ad hoc workarounds.
• Directory Sync: Directory sync is the operational process of moving identity changes from a source directory into downstream applications. The important distinction is that sync must preserve both data quality and governance scope, otherwise the application receives incomplete or mis-scoped lifecycle events that create access drift.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 programme, it is worth exploring.