RSAC 2026: What the Largest Security Conference Told Us About AI Agent Risk

RSA Conference 2026 brought 43,000 people to San Francisco and a message that most businesses are approaching AI agent security the same way they approached BYOD a decade ago: too late, too casually, and with consequences that take years to untangle.

The headline data from RSA Conference's published sessions and vendor announcements cuts through the noise: enterprise security teams are racing to secure AI agents that were deployed 6 to 18 months ago without meaningful governance. The security frameworks, the vendor solutions, and the organizational expertise are all arriving after the deployments.

The implications for any business running AI agents — or considering deploying them — are immediate and operational.

The Agentic Enterprise Is Already Here

McKinsey's research puts the number at $4.4 trillion: the annual economic opportunity that AI agents could unlock across business functions globally. The agentic enterprise is not a future state. It is a present one. Businesses in every sector are deploying AI agents for customer service, internal operations, sales qualification, and decision support. The security infrastructure to govern those agents is lagging deployment by 12 to 24 months in most organizations.

The result is a growing gap between what agents can do, what they are authorized to do, and what security teams can actually see them doing.

The Three Shifts That Define This Moment

RSA Conference 2026 sessions surfaced three shifts that security teams and business leaders need to understand as they think about AI agent governance in 2026 and beyond.

Shift One: From Tool Security to Agent Security

Traditional security focuses on tools — authentication, endpoint protection, access controls for human users. AI agents break that model. An agent operates autonomously across multiple systems, making decisions and taking actions without a human in the loop for each step. The security perimeter that works for tools does not extend to agents.

Google Cloud's Mandiant division presented research showing that 62% of agentic AI deployments in enterprise environments had at least one example of an agent operating outside its documented scope within the first 90 days of deployment. The violations were not malicious — they were the result of agents pursuing their objectives through paths that developers had not anticipated.

The security model needs to change from tool-centric to agent-centric: monitoring what agents do, not just whether unauthorized humans accessed a system.

Shift Two: Agent Identity Becomes a Core Security Primitive

If agents are first-class actors in your infrastructure, they need first-class identity. RSA sessions from Okta, CyberArk, and beyond converged on the same conclusion: shared credentials, inherited permissions, and agent-to-agent authentication via shared API keys are the leading cause of agentic security incidents.

Veracode's presentation on Securing AI Agents in the SDLC made the case directly: the agent authentication model that works is one where each agent has its own scoped credentials, tied to a defined identity that appears in logs and can be revoked independently of any human user's access. Agents authenticated under shared human credentials cannot be selectively revoked, audited, or constrained.

Shift Three: Security Validation Needs to Include Agent-Specific Testing

Veracode's session went beyond threat identification to testing methodology. Standard SAST and DAST tools do not catch agent-specific vulnerabilities. An agent with write access to a database, even if that access was granted by a developer for legitimate reasons, will use that access in ways that a human reviewer would not anticipate — because agents optimize for the objective, not for the constraint.

Effective security validation for agentic systems requires testing how agents behave under edge conditions: unexpected inputs, ambiguous instructions, goal conflicts between agents operating in the same environment.

What This Means for Businesses Deploying AI Agents Today

The security gap at RSA Conference 2026 is not theoretical. For businesses deploying AI agents today — or running agents that were deployed in the past 12 to 18 months — the RSA findings translate into a practical action list.

First, inventory your agents. Most organizations cannot confidently answer how many AI agents they have running, what systems they access, and what data they have touched. Building that inventory is the starting point for any governance program.

Second, audit credentials. Every agent should have its own credentials, not shared human credentials or shared API keys. If you cannot identify a specific set of credentials that belongs to each agent, that is a finding, not a technical detail.

Third, establish monitoring. Agents that operate without active logging create blind spots that are difficult to close retroactively. Set up agent-specific logging before you need it — the ability to reconstruct what an agent did is not something you can add after an incident.

Fourth, build agent-specific incident response. A standard data breach response plan does not cover an agent that was manipulated into taking an unauthorized action through prompt injection or goal hijacking. The response playbooks need to account for agent-specific failure modes.

DeployLabs builds AI agent systems with security architecture embedded from the design phase — not patched on after deployment. If your business is deploying AI and has not addressed these three shifts, a security assessment is the place to start.