Agentic security platforms still depend on identity foundations

At a glance

What this is: This comparison argues that agentic security is still an identity problem first, with authentication, authorization, and lifecycle control doing the real work.

Why it matters: It matters because IAM, NHI, and autonomous-system programmes fail when teams bolt AI guardrails onto weak identity foundations instead of governing the actor that actually executes actions.

By the numbers:

• Noma Security says its platform integrates with 80+ AI services and tools to create a unified dashboard for tracking AI usage patterns.
• WorkOS states that its platform maintains 99.99% uptime SLAs for enterprise customers.

👉 Read WorkOS's comparison of Noma Security and agentic identity foundations

Context

Agentic security is the discipline of governing software actors that can act on behalf of users or systems. The key failure in this category is treating the agent as a special case while leaving authentication, authorization, and revocation fragmented across tools.

This article sits at the intersection of NHI governance and application identity. The practical question is not whether an AI agent needs monitoring, but whether its access is anchored to a governed identity model that can be reviewed, revoked, and audited consistently.

Key questions

Q: How should security teams govern AI agents that act on behalf of users?

A: Security teams should bind each agent to a governed identity, scope its permissions to the requesting principal, and enforce authorization at the application boundary. Monitoring is useful, but it cannot replace policy enforcement or revocation. If an agent can act, it must be auditable, least-privileged, and tied to lifecycle events that remove access when the underlying user or workflow changes.

Q: Why do AI agents complicate traditional IAM models?

A: AI agents complicate IAM because they can execute actions dynamically across tools and data sources, which makes static permission assumptions less reliable. Traditional IAM often assumes a stable human operator and a predictable request path. Agents break that model by combining delegation, tool access, and runtime decision-making, so teams need authorization that follows the actor, not the interface.

Q: What breaks when AI agent access is not tied to lifecycle events?

A: Access becomes orphaned when directory changes, offboarding, or role updates do not revoke agent permissions derived from those identities. That creates standing privilege for software actors that may continue to reach data or systems long after the original user relationship ends. The result is accountability loss, broader blast radius, and harder incident reconstruction.

Q: Should organisations use separate controls for AI agents and human users?

A: Most organisations should not build separate trust models unless the agent truly needs a distinct identity boundary. The better pattern is to extend established IAM, authorization, and audit controls so they apply consistently to humans, service identities, and agents. Separate layers can create policy drift, duplicate administration, and inconsistent enforcement.

Technical breakdown

Authentication and authorization for AI agents

AI agents do not become secure because they are observable. They become governable when requests are tied to a stable identity, permissions are scoped to the requesting actor, and policy enforcement happens at the application boundary. That is why enterprise SSO, token handling, and fine-grained authorization matter more than output filters. A system can watch an agent behave badly and still fail to stop it if the underlying identity grants too much access. In practice, the critical design choice is whether the agent inherits permissions from a human principal or operates through its own governed service identity.

Practical implication: bind every agent action to a verifiable principal and enforce authorization where the resource is actually accessed.

MCP tool access and delegated scope

Model Context Protocol expands what agents can reach by connecting them to tools and data sources, but that also expands the blast radius if scope is not constrained. The technical issue is not the protocol itself. It is the combination of dynamic tool selection, broad entitlements, and opaque delegation paths that can let an agent touch unintended systems. MCP server mapping is useful because it exposes those paths, but mapping alone is not enforcement. Security teams need to understand which tools an agent can invoke, which identities it can assume, and where policy is checked before action is taken.

Practical implication: inventory every MCP-connected tool and define explicit authorization boundaries before agent rollout.

Lifecycle revocation and audit logging

Agent governance breaks down when access outlives the user or workflow that created it. Directory sync, token rotation, and audit logging are the control plane that keeps delegated access from turning into standing privilege. If an employee leaves or a workflow changes, the associated agent permissions must collapse with it. Without that lifecycle coupling, agents become orphaned actors with hard-to-detect persistence. Audit trails also need to distinguish human-initiated actions from agent-executed actions so investigators can reconstruct accountability after the fact.

Practical implication: connect agent entitlements to human lifecycle events and verify revocation is immediate, not eventual.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Agentic security still collapses into identity governance. The article is right to separate monitoring from access control, because watching an agent is not the same as governing it. AI systems acting in production need authenticated principals, scoped permissions, and revocation that follows the actor rather than the alert stream. The implication is that teams that treat agent security as a standalone category will duplicate controls and still miss the real authorization boundary.

Delegated access without lifecycle coupling is the failure mode this comparison exposes. The article shows how orphaned agent credentials can persist when directory state and application permissions are not synchronized. That is not an AI novelty, it is a governance break familiar from service-account sprawl and unoffboarded machine access. Practitioners should read this as a lifecycle problem, not a tooling preference.

MCP expands the attack surface by multiplying tool relationships faster than policy can keep up. Once an agent can call tools dynamically, the security model has to explain not only what the agent may do, but which downstream systems it can reach in each execution path. That is why mapping without enforcement is insufficient. The practitioner takeaway is to treat tool connectivity as an authorization design problem, not a visibility feature.

Enterprise AI will converge on identity-native controls, not parallel AI security stacks. Specialized guardrails can supplement governance, but they do not replace the base layer that determines who or what is allowed to act. The market is moving toward platforms that can extend existing IAM patterns to new actor types instead of creating a second policy universe. Teams should re-evaluate any architecture that requires separate trust models for human users and agents.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• In the same research, 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
• For the lifecycle angle, review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for how identity revocation and offboarding should work when the actor is not human.

What this signals

With 80% of organisations already reporting agent behaviour beyond intended scope, the governance problem is no longer speculative. Teams that rely on security monitoring alone will keep discovering the breach after the action has already happened, which is too late for containment or accountability.

Delegation drift: when AI agents inherit permissions from users but keep acting after the original context changes, accountability becomes detached from the actor. That is the operational signal to reassess whether your current IAM model can still distinguish initiation, execution, and ownership.

Programmes that already struggle with service-account sprawl will feel this pressure first because agent identities add another layer of delegated access to review. The right response is to align application authorization, directory lifecycle, and audit logging before agent adoption widens the gap.

For practitioners

• Anchor agent actions to a governed principal Tie every AI agent request to a stable user or service identity, and make authorization decisions at the resource boundary rather than in a separate monitoring layer.
• Map delegated tool paths before production rollout Document every MCP-connected tool, the identity used to reach it, and the maximum downstream scope each path can reach. Remove implicit access where policy is not explicit.
• Couple agent revocation to directory and lifecycle events Ensure that employee offboarding, role changes, and token rotation revoke any agent access derived from that identity without waiting for manual cleanup.
• Separate human and agent audit trails Log which principal initiated the request, which agent executed it, and which resource accepted it so investigations can reconstruct accountability without ambiguity.

Key takeaways

• Agent security is an identity problem first, because monitoring cannot replace authorization, revocation, or accountability.
• AI agent behaviour beyond intended scope is already widespread, which means governance gaps are being exploited in live environments now.
• Teams should extend existing IAM and lifecycle controls to agents rather than creating a separate security model that duplicates policy and increases drift.

Key terms

• Agentic security: The practice of governing software actors that can choose actions, tools, and timing in production workflows. It extends identity, authorization, logging, and lifecycle control to agents so their behaviour is tied to a verifiable principal and a revocable permission set.
• Delegated identity: An identity pattern where a software actor performs actions on behalf of a user or workflow. The critical governance question is whether the delegation is bounded, auditable, and revocable, or whether it becomes a persistent shortcut around normal access controls.
• Fine-grained authorization: Authorization that decides access at the level of specific relationships, resources, and actions instead of broad roles alone. For agentic systems, it is the control that stops a capable agent from turning broad application reach into unnecessary blast radius.
• Lifecycle coupling: The practice of binding access to joiner, mover, and leaver events so entitlements do not outlive their valid business context. In agent environments, lifecycle coupling must include service identities and delegated tokens, not only human accounts.

Deepen your knowledge

AI agent governance and delegated access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending identity controls from users to software actors, it is worth exploring.

This post draws on content published by WorkOS: Noma Security vs WorkOS, a comparison of platforms for securing AI agents and autonomous systems. Read the original.