RSAC 2026 exposed the real AI security question for practitioners

At a glance

What this is: This is an event-driven analysis of RSAC 2026 that argues the real issue is AI security governance, not AI adoption hype.

Why it matters: It matters because IAM, PAM, and security teams are now responsible for defining how AI systems, agents, and supporting identities are governed before their attack surface outruns controls.

👉 Register for Expel's RSAC 2026 analysis of AI security messaging and attack surface growth

Context

AI security now spans more than model misuse or prompt tricks. It includes shadow AI, data leakage, agentic system access, MCP security, and the identity controls around the systems that can act on data and tools. At RSAC 2026, the gap was not whether AI would matter, but whether organisations can explain how they secure it.

The governance problem is familiar to identity teams even when the technology is new. When systems can access tools, data, and other services, they begin to behave like identities that need lifecycle control, accountability, and bounded privilege. That is why the AI discussion at RSAC 2026 belongs in identity governance as much as in broader cyber operations.

Key questions

Q: How should security teams govern AI workflows that use multiple tools and data sources?

A: Security teams should govern AI workflows by placing explicit authorization at each decision point, not by relying on the permissions attached to the surrounding application or service account. The practical goal is to scope read, retrieve, and execute access separately so the workflow cannot inherit broader reach than it needs for the task.

Q: Why do AI tools create new access governance risks for security teams?

A: AI tools often sit close to mail, data, and response systems, which makes their permissions unusually broad. The risk is not only misuse by attackers, but also scope creep as teams add more data, actions, and integrations without revisiting ownership, approval, and revocation. That is a classic identity governance failure.

Q: How can organisations tell whether their AI security model is actually working?

A: They should test whether the control stack can explain who acted, what data was touched, and what purpose the action served. If those three signals cannot be correlated in one incident view, the model is likely monitoring access without governing behaviour. That is a visibility gap, not a complete AI security posture.

Q: Who is accountable when an AI agent takes an unsafe action?

A: Accountability should sit with the business owner of the agent, the team that provisioned the access, and the control owners responsible for monitoring and revocation. If no one can answer who approved the identity, the scope, and the oversight model, the governance framework is not complete enough for production.

Technical breakdown

Why AI security is becoming an identity governance problem

As AI systems gain access to data, tools, and workflows, they start to look less like isolated software and more like governed entities with privileges. That changes the control question from simple model safety to access scope, accountability, and revocation. If an AI system can query records, trigger actions, or hand work to other services, it needs the same lifecycle discipline that security teams apply to service accounts and privileged integrations. The critical issue is not whether the system is intelligent. It is whether it is bounded, traceable, and removable when its behaviour changes.

Practical implication: treat AI systems that can act in the environment as identities with scoped access, not just as applications.

What operational defense in depth means for AI-enabled security teams

Operational defense in depth spreads AI across detection, enrichment, triage, response, and reporting instead of concentrating it in one autonomous control point. That matters because AI is strong at pattern recognition and workload reduction, but weak at guaranteed contextual judgment in unusual cases. A layered approach keeps humans in the loop for decisions that require risk tolerance, business context, or exception handling. It also makes failure less catastrophic because one model mistake does not become a full control-plane mistake. The architecture question is therefore about placement, not just capability.

Practical implication: map where AI supports analysts today and avoid putting irreversible decisions behind a single autonomous layer.

MCP security and agentic system security need explicit boundaries

Model Context Protocol connects agents to tools and data sources, which makes it useful and risky at the same time. Once an agent can invoke external systems, the security challenge moves from model output to delegated action and tool trust. That requires explicit policy enforcement, logging, and a clear view of which agents can reach which resources. In practice, this is a non-human identity problem as much as an AI problem, because the risk comes from what the system is allowed to do, not just what it can say.

Practical implication: inventory agent-to-tool connections and enforce policy at the integration layer, not only at the model layer.

Threat narrative

Attacker objective: The objective is to turn AI-enabled access into a repeatable path for data exposure, tool abuse, and control bypass.

1. Entry occurs when shadow AI, agentic apps, or exposed AI tool connectors gain access to enterprise data and services without being fully tracked by security teams.
2. Escalation follows when those systems inherit broader permissions than intended, allowing them to query sensitive data, invoke tools, or reveal credentials across workflows.
3. Impact occurs when agentic misuse, data leakage, or policy failure produces unauthorized access, business disruption, or compromised decision-making at scale.

NHI Mgmt Group analysis

AI security is now an identity governance problem, not just a model risk problem. Once AI systems can access tools, data, or downstream services, they need lifecycle controls that resemble non-human identity governance. That means explicit ownership, scoped privilege, revocation paths, and logging across the full access chain. Organisations that treat AI as only a software feature will miss the governance layer that determines whether it becomes an attack surface.

Operational defense in depth is the right response to AI hype because it preserves human accountability. The article’s central insight is that placing AI across the workflow is safer than giving one system end-to-end authority. This aligns with NIST AI RMF GOVERN and MEASURE thinking, where accountability and monitoring stay visible even as automation increases. Practitioners should use AI to compress workload, not to eliminate decision ownership.

MCP creates a named governance gap we can call tool delegation trust. The protocol itself is not the problem. The problem is that once agents can call tools and data sources, the organisation must decide which actions are allowed, recorded, and reversible. That boundary belongs in governance, not in marketing language about autonomy. Security teams should treat tool delegation as a privileged access issue.

Shadow AI is becoming the next unmanaged identity population. The article’s repeated emphasis on unseen or poorly tracked AI use points to the same structural failure identity teams have seen with service accounts and hidden integrations. If an organisation cannot inventory who or what can act, it cannot govern access or investigate misuse. The practical conclusion is to extend identity inventory discipline into AI discovery and policy enforcement.

What this signals

Agentic governance debt: the longer organisations deploy AI systems before assigning ownership, access boundaries, and revocation paths, the harder it becomes to retrofit control. The practical signal for security teams is whether AI inventory, policy enforcement, and audit logging are being built together or treated as separate workstreams.

The mix of shadow AI, MCP-enabled access, and agentic workflows means identity teams will increasingly need to govern machine action, not just machine authentication. That is a direct extension of non-human identity discipline into AI operations, especially where tools can change state or expose sensitive data. Teams should expect more pressure to prove who or what acted, when, and under which policy.

For practitioners

• Inventory AI systems that can act on data or tools Build a register of AI assistants, agents, MCP connectors, and workflow automations that can read, write, or trigger enterprise systems. Capture owner, purpose, data access, and revocation path so discovery supports governance rather than just visibility.
• Classify agent permissions as privileged access Map each AI system to the exact tools and datasets it can reach, then apply least privilege, separation of duties, and approval boundaries where actions can change state or expose sensitive data.
• Measure where AI changes analyst decisions Track whether AI reduces triage noise, improves evidence quality, or only accelerates output volume. Use those measures to decide which steps stay human-led and which can remain machine-assisted.
• Add policy enforcement at the MCP and integration layer Do not rely on prompts or model guardrails alone. Enforce allowlists, logging, and conditional access where agents connect to tools, because that is where delegated action becomes real risk.

Key takeaways

• AI security is becoming an access governance issue because systems that can act also need lifecycle control.
• The article’s core warning is not that AI is everywhere, but that most organisations still cannot explain or audit what their AI systems can touch.
• Security teams should govern AI like privileged infrastructure, with scoped access, traceability, and revocation paths built in from the start.

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.
• MCP Security: MCP security is the set of controls that protect Model Context Protocol connections between agents, tools, and data sources. It covers connector permissions, secret handling, and policy enforcement because the protocol can become a direct path from agent intent to enterprise action.
• 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.
• Tool Delegation Trust: The assumption that an agent may safely call external tools or services once the model appears authorised. This is a governance failure if the delegation boundary is not explicitly scoped, monitored, and revocable.

What's in the full article

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

• The specific RSAC 2026 examples behind the AI messaging problem and how practitioners reacted on the floor.
• The five SOC architecture questions Dave Merkel used to test whether AI is actually supporting defenders.
• The article’s examples of AI attack surface categories, including shadow AI, prompt injection, and MCP security.
• The vendor’s description of operational defense in depth across enrichment, triage, response, and reporting.

👉 The full Expel article covers the RSAC observations, SOC architecture questions, and AI attack surface categories in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is a practical fit for teams extending identity controls into AI systems and other non-human actors.