Agentic security at RSAC 2026 exposes the identity gap

At a glance

What this is: This analysis argues that agentic security has moved from concept to operational identity problem, with discovery, identity assignment, action-level control, and baselining emerging as the core challenges.

Why it matters: IAM, NHI, and security teams need this view because AI agents are now being treated as identities, and existing human-centric access models do not capture agent intent, tool chaining, or runtime drift.

By the numbers:

• Enterprise adoption of AI agents went from 1% of organisations to 91% between Q1 2024 and late 2025.
• The MCP server registry grew from 100 servers to over 6,000 in roughly twelve months.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

👉 Read Vorlon’s analysis of agentic security themes at RSAC 2026

Context

Agentic security is the identity governance problem that appears when software can choose actions, tools, and timing at runtime. The article frames the issue around AI agents already operating in enterprises, while most teams still lack discovery, identity assignment, and control over what those agents are actually doing. For identity programmes, this is no longer an experiment at the edge of the architecture; it is a live governance gap inside production workflows.

The primary failure is not that agents exist, but that organisations are still applying access models built for static users and conventional applications. Once an agent can chain tools, move across systems, and drift from intended use, the governance question becomes whether the identity model can describe intent, ownership, and action scope well enough to be enforceable. That is the baseline challenge this RSAC 2026 analysis puts in focus.

The article is typical of what security teams are now seeing across large enterprises: adoption has raced ahead of observability, and the resulting control gap is structural rather than incidental.

Key questions

Q: What breaks when AI agents are discovered too late or not at all?

A: When agents are not discovered early, teams cannot assign ownership, set scope, or prove what systems the agent can reach. That leaves shadow AI outside IAM, IGA, and PAM oversight. The result is unmanaged identity growth, weak auditability, and limited ability to contain misuse or offboard the agent cleanly.

Q: Why do AI agents need action-level authorisation instead of resource-level access?

A: Resource-level access tells you what an agent can reach, but not whether its runtime actions match its authorised purpose. Agents can chain tools, change direction mid-session, and still remain technically authenticated. Action-level authorisation is needed because the risk is often mission drift, not simple unauthorised login.

Q: How do security teams know if AI governance is working?

A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent. If the team cannot explain who owns an AI workflow, what it can reach, and when its access was last reviewed, governance is incomplete. Control maturity shows up in traceability, not adoption volume.

Q: What is the difference between human access review and AI agent access review?

A: Human access review focuses on stable job roles and periodic entitlement checks. AI agent access review must also account for runtime behaviour, changing integrations, token lifetimes, and delegated actions across SaaS systems. Agents can change what they touch faster than a standard access review cycle expects.

Technical breakdown

Why agent discovery is the first control

Discovery is the prerequisite because an identity control cannot govern what it cannot see. In the article, the gap is not theoretical: many organisations already have agents in production through IT, development teams, low-code tooling, and bundled SaaS features. For identity teams, discovery has to include both formally approved agents and shadow AI that arrived outside standard review. Without inventory, ownership, and environment mapping, every downstream control is operating blind.

Practical implication: build a discovery process that finds AI agents across SaaS, low-code, developer, and production environments before designing policy.

Why agents need identity, ownership, and lifecycle control

The article treats an agent as something that must be managed like an identity, not merely a workload. That means the agent needs an owner, a permission scope, an identity baseline, and a lifecycle that can absorb changes in job function or termination. This is the point where human IAM and NHI governance converge: the control objective is to prevent unowned access from persisting after business need changes. Treating agents as identities makes remediations, accountability, and decommissioning possible.

Practical implication: extend joiner-mover-leaver and access review processes to agent identities, not just people and service accounts.

Why Zero Trust must shift from identity verification to intent verification

The article makes a strong architectural point: authenticating an agent is not enough if the agent can decide which actions to chain at runtime. Traditional resource-level authorisation answers who the actor is, but not whether the specific action sequence matches the authorised purpose. That is why intent becomes a governance primitive. If an agent can technically remain within scope while functionally going off mission, access control has not failed at identity level, it has failed at action level.

Practical implication: define policy around permitted actions and context, not just resource access, for any agent operating in production.

Threat narrative

Attacker objective: The attacker objective is to use a trusted agent’s sanctioned access and runtime behaviour to move data or trigger actions that appear legitimate to normal controls.

1. Entry occurs when AI agents are introduced into enterprise workflows through approved SaaS tools, low-code platforms, or developer-built integrations without full security visibility. Escalation happens when those agents operate with valid credentials and enough permission to chain actions across systems. Impact follows when attackers or malicious tools influence agent behaviour, enabling data exfiltration, supply chain abuse, or business logic manipulation without traditional alerts.

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

Discovery is now the control plane for agent governance: the field cannot govern what it has not enumerated. That means inventory is no longer a documentation exercise, but the prerequisite for identity, policy, and response. In practice, discovery has to cover sanctioned, shadow, and embedded agents across all business units.

Agent identity governance is an NHI problem before it becomes an AI problem: once an agent has valid credentials, lifecycle ownership matters more than model sophistication. The same discipline used for service accounts now has to extend to software entities that can act, chain tools, and outlive the team that created them.

Action-level authorisation is the named concept here: resource-level permissioning is too blunt for agents that decide what to do next at runtime. The article shows why verifying identity is insufficient when the real risk is mission drift, tool chaining, or prompt-shaped behaviour inside an authenticated session. Practitioners need to rethink control scope, not just tighten access lists.

Behavioral baselines for agents are still an unfinished governance assumption. The industry knows it needs normal-pattern detection, but current baselining logic was built for deterministic systems or human users. That assumption fails when the actor reasons differently on each run, because there is no stable behavioural fixed point to certify. The implication is that identity programmes must stop assuming static normality.

MCP is becoming a supply chain surface, not just a protocol choice: once an agent can connect to thousands of tools, the trust boundary shifts to every registered server and dependency. This widens the identity attack surface from credential management alone to tool provenance, registration, and runtime trust. Practitioners need supply chain discipline for agent connectors.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
• For lifecycle and rotation governance, see Ultimate Guide to NHIs , 2025 Outlook and Predictions for how non-human identity discipline is evolving.

What this signals

Action-level authorization is the next identity control frontier for agentic systems, because permissioning the resource is no longer enough when the actor can select and sequence tools at runtime. Teams that keep treating agents as enhanced applications will miss the governance point entirely, and the gap will widen as more platforms embed autonomous workflows into ordinary business processes.

With 43% of security professionals already worried about AI systems learning and reproducing sensitive information patterns from codebases, the trust problem now spans both identity and data handling. That is where NIST AI Risk Management Framework thinking becomes relevant for identity teams: define scope, measure behaviour, and map accountability before agents become operationally invisible.

MCP connector sprawl: the article’s supply chain warning is really about tool provenance becoming part of identity governance. If a connector can change behaviour without visibly compromising the core agent, then connector approval, sandboxing, and registration need to sit beside IAM and PAM controls, not outside them.

For practitioners

• Map every deployed agent before writing policy Build a discovery inventory that includes enterprise-sanctioned agents, shadow AI, low-code deployments, and SaaS-bundled assistants. Capture owner, data access, connected tools, and production touchpoints so identity policy starts from evidence rather than assumption.
• Assign identity and ownership to each agent Create a named owner, scope, and lifecycle record for every agent just as you would for a privileged service account. If ownership changes or the use case ends, transfer responsibility or decommission the agent instead of leaving credentials and permissions in place.
• Shift authorization from resources to actions Define which actions an agent may take, in which contexts, and for which business purpose. Resource access alone is too coarse when an agent can chain workflows, query new systems, or repurpose itself mid-session.
• Treat MCP servers as third-party dependencies Review every tool connector before it reaches production, because a malicious or poorly governed server can alter agent behaviour even if the main agent looks legitimate. Use registration, sandboxing, and approval gates before connection, especially for systems that touch production data.
• Build behavioural baselines only after intent is defined Set expected behaviour from the agent’s authorised purpose, not from generic telemetry. Baselines that ignore intent will miss mission drift, tool misuse, and off-scope actions that still look normal at the protocol level.

Key takeaways

• AI agent governance has become an identity problem, not just an AI feature problem.
• The hardest gap is not adoption volume but runtime control over what agents are allowed to do.
• Practitioners should treat discovery, ownership, action scope, and connector trust as the core controls for agentic systems.

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Sequence-Level Authorisation: Sequence-level authorisation is control over the full chain of actions an autonomous agent can take, not just the permissions on each individual request. It matters because an agent can combine several valid calls into an outcome that no single policy check would flag.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

What's in the full article

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

• Direct session-by-session notes from Cisco, CrowdStrike, Microsoft, and Okta with the specific framing each speaker used
• The exact examples behind agent discovery, action-level authorization, and MCP supply chain risk
• The session footnotes and transcript references that support the article’s interpretation
• The conference context around how enterprise teams are currently talking about AI agent governance

👉 Vorlon’s full post covers the session evidence, architecture arguments, and open problem of behavioural baselines.

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 responsible for identity security strategy or programme maturity, it is worth exploring.