TL;DR: RSAC 2026 showed that AI security messaging is outpacing practitioner confidence, with Expel arguing that the harder question is not how to use AI but how to secure it as shadow AI, GenAI leakage, agentic identity compromise, and MCP security expand the attack surface. The implication is that security teams need governance and accountability models for AI systems now, not later.
At a glance
What this is: Expel’s RSAC 2026 analysis says the show floor was saturated with AI messaging, but practitioners responded by asking harder questions about accountability, scope, and how AI security is actually governed.
Why it matters: This matters because AI adoption is widening attack surface faster than many security programmes can classify, assign ownership, or control, especially where agentic systems and machine identities intersect.
Context
RSAC 2026 was not just another security conference; it was a signal test for how the market talks about AI security. The underlying governance gap is simple: teams can hear claims about automation and agentic capability, but still not know what is being secured, who owns it, or where the control boundary sits.
In practical terms, AI security now spans shadow AI, GenAI data leakage, agentic identity compromise, and MCP-related exposure. Those are different risk surfaces with different failure modes, which means a single “AI-powered” label tells practitioners almost nothing about control design or accountability.
For identity and security teams, the important shift is not whether AI exists in the stack. It is whether the organisation can govern the identities, permissions, tools, and data paths that AI systems rely on. That is typical of the current market: the language moved faster than the controls.
Key questions
Q: What breaks when AI adoption outpaces governance?
A: What breaks first is attribution. Teams lose visibility into which tools are in use, which data they can reach, and which actions were taken automatically versus manually. Once adoption is ahead of control design, security teams end up retrofitting policy around live workflows instead of governing them from the start.
Q: Why do agentic AI systems create more security risk than standard chatbots?
A: Agentic systems can turn model output into action, which means a bad instruction can affect code flow, tool use, and downstream state. Standard chatbots usually stop at text generation. Agentic AI adds execution authority, so compromise can lead to disclosure, unauthorized changes, or misuse of credentials.
Q: How can security teams tell whether AI lifecycle controls are working?
A: They should look for evidence that access requests, policy enforcement, and usage visibility are centrally recorded and current. If those signals are fragmented across platforms, the programme may be documenting governance rather than enforcing it. Continuous traceability is the practical test.
Q: What is the difference between agentic AI governance and traditional automation governance?
A: Traditional automation governance assumes a fixed script with predictable inputs and outputs. Agentic AI governance must control a system that can plan, adapt, and choose different execution paths. That means identity scoping, approval rules, and audit trails matter more, because the same agent may behave differently across similar tasks.
Technical breakdown
Why AI messaging collapses without control boundaries
Security buyers do not evaluate AI claims in a vacuum. They evaluate whether the system has a clear operating boundary, an accountable owner, and observable control points. When a product says it is “AI-powered” without specifying where the model acts, what data it can access, and how outputs are constrained, the claim becomes marketing noise rather than an architectural description. That is especially true in security operations, where false confidence creates operational risk. The issue is not whether AI can assist analysts. The issue is whether AI is embedded in a governed workflow or left free to create decisions without traceability.
Practical implication: Practitioners should demand a control map for every AI capability before accepting any AI security claim.
Agentic systems change the identity problem, not just the automation model
An AI agent is not just a feature with autonomy; it is a software actor that may request tools, access data, and act across sessions. That makes identity and privilege central. If an agent can authenticate, inherit context, or use delegated permissions, then its security posture depends on the same governance questions that apply to any high-risk non-human identity: who created it, what it can touch, how long access lasts, and how it is revoked. The article’s mention of agentic identity compromise and MCP security shows why this is no longer theoretical. The governance challenge is not simply AI misuse. It is uncontrolled delegation.
Practical implication: Treat agent identities as governed access subjects with scoped permissions, lifecycle ownership, and revocation paths.
Operational defense-in-depth is the right answer to AI hype
The article’s strongest idea is that AI should support analysts inside the workflow, not replace them at the edge of the workflow. That aligns with a defense-in-depth model where AI is applied to enrichment, correlation, triage, and reporting, while humans retain judgment where context and risk tolerance matter. This is not a purity argument against autonomy. It is a recognition that security operations still depend on explainability, escalation, and accountable decisions. The deeper point is that consistency without context is not a control strategy; it is an efficiency claim that can fail at the wrong moment.
Practical implication: Design AI into human-led security workflows where decisions remain explainable and reversible.
NHI Mgmt Group analysis
AI security is now an identity governance problem as much as a model problem. The article makes clear that practitioners are no longer persuaded by generic AI claims; they want to know what is being controlled, by whom, and across which access paths. That is the right instinct. Once AI systems can act, delegate, or call tools, the governance question moves from model quality to identity, privilege, and lifecycle control. Practitioners should treat AI systems as governed actors, not just capabilities.
Shadow AI creates unmanaged control debt. The article’s list of real-world categories, including shadow AI, GenAI leakage, and agentic identity compromise, shows that many organisations are already carrying risk they cannot see fully. That is not a visibility problem in the abstract. It is a control problem where discovery, ownership, and policy enforcement are out of sync. The named concept here is AI governance debt: the growing gap between AI adoption and the controls needed to govern it. Practitioners should reduce that debt before it becomes operationally expensive.
Agentic identity compromise is the emerging failure mode that traditional AI messaging understates. The more important question is not whether AI can automate tasks, but whether an agent can be trusted with delegated identity, tool use, and contextual authority. If the organisation cannot answer that, the attack surface is already broader than the roadmap suggests. This is the point where IAM, PAM, and AI governance meet. Practitioners should make agent identity a first-class governance object.
MCP security turns integration design into security design. Once AI systems use MCP to reach tools and data, the connection itself becomes part of the trust boundary. That means security teams need to govern tool registration, permission scope, and revocation with the same seriousness they apply to other privileged integrations. The practical conclusion is simple: if the agent can use the tool, the tool path must be treated as a governed control surface.
What this signals
AI governance debt: the most visible risk in the article is the gap between rapid AI adoption and the controls needed to govern access, delegation, and accountability. Security teams should assume that every unmanaged agent or copilot is adding debt until its identity and permissions are explicitly defined.
Practitioners should expect the AI security conversation to shift from feature claims to control evidence. That means asking where the agent lives, what it can reach, how tool access is approved, and what happens when the workflow must be revoked or constrained.
The most practical response is to move AI security into the same governance rhythm used for high-risk identities and privileged integrations. If that does not happen, the organisation will keep scaling AI faster than it can explain or contain it.
For practitioners
- Inventory shadow AI and agentic integrations Build a live register of AI tools, copilots, and agents that can access internal systems, then assign an accountable owner to each one.
- Define agent identity governance rules Require every agent to have a scoped identity, named business purpose, approved tool set, and explicit revocation process.
- Map MCP-connected tool paths Review which tools and data sources are reachable through MCP connections and remove any path that exceeds the agent’s intended task scope.
- Separate AI assistance from AI autonomy Keep human approval in the loop for high-risk actions such as access changes, data movement, and containment steps.
- Measure AI control coverage, not AI volume Track how many AI systems have approved ownership, logged actions, and enforced policy controls rather than counting deployments or demos.
Key takeaways
- The article argues that the real AI security problem is governance, not messaging, because practitioners now want clear control boundaries and accountability.
- Shadow AI, agentic identity compromise, MCP security, and GenAI leakage show that the attack surface is already widening faster than many programmes can track.
- The control answer is to treat AI systems as governed actors, with scoped identity, enforced permissions, and human accountability for high-risk actions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article focuses on AI systems inheriting and using delegated authority. |
| ASI02 — Tool Misuse | RSAC discussions highlighted agents acting through tools without enough control clarity. | |
| Recommendation — Constrain agent identities to least-privilege tool use and revoke delegated access when scope changes. Restrict tool execution paths and require approval for high-risk agent actions. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article argues that ownership and accountability are the real gap in AI security. |
| Recommendation — Establish clear AI accountability, approval, and oversight processes before scaling deployments. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The piece repeatedly returns to who can access what in AI-enabled workflows. |
| Recommendation — Apply entitlement controls to AI systems and their connected tools just as you would other privileged access. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Agentic misuse and delegated access can become paths to broader internal movement. |
| Recommendation — Map AI-related abuse paths to credential access and lateral movement tactics in detection engineering. | ||
Key terms
- Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
- 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.
- 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.
- 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.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and workload identity. It helps practitioners connect identity control to modern security operations and AI governance.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org