AI agents are hitting production faster than security teams can track them. They hold credentials and act on systems of record, yet most enterprises cannot say which agents run or who owns them. Gartner expects a typical Global Fortune 500 to operate about 150,000 agents by 2028, up from fewer than 15 in 2025. Against this backdrop, RSA introduced RSA Agent ID at The AI Conference in San Francisco, an identity security platform for agents. We spoke with Jim Taylor of RSA to unpack how it works.
Why do AI agents break the identity model?
Because agents are not service accounts. They are dynamic, autonomous, and accumulate access and data over time. Without an owner and lifecycle, control disappears. Many enterprises cannot say which agents are running, who is accountable, or whether anyone can stop them. Only 13% of organizations believe they have proper agent governance.
Agents do not pause or tire. You give a task, and they pursue it relentlessly. If the task is badly worded, they act on their own judgment within the rights they have. This breaks the traditional model of static roles and service accounts.
The scale surprises even regulated firms. A medium global bank claimed it had none due to policy. An audit found more than 4,000 shadow agents. Incidents involving shadow AI cost more: IBM reports an average of $670,000 extra compared to standard incidents.
Without an owner, agents accumulate entitlements and integrations, then slip out of view. No one checks when permissions change, and no one deletes idle instances. That creates an invisible zoo of risks that grows with autonomy.
“What changes with agents? Everything. They’re not a service account. They’re not static. They’re dynamic... Agents don’t get tired at two o’clock in the morning. They just go.”
When a prompt turns into a denial‑of‑service attack
One poorly framed instruction can stall the business without any attacker. An employee asks an agent to “go to Salesforce and get all the data” for health charts. The agent starts downloading the entire database. Salesforce defenses read the traffic as an attack and shut down the instance. The company is warned it appears under DoS.
From the operator’s view, he did nothing wrong. Yet maximal execution of the task triggered the cloud platform’s automated defenses. The result is a critical system outage caused by a normal business initiative.
The lesson is clear: you need enforcement at the tool‑call level, argument constraints, and risk‑aware escalation. And you need a true kill switch when behavior strays beyond policy.
When agents touch production CRM or ERP, even “legit” actions can look like attacks by volume or pace. Security must read context and intent, not only network patterns.
“One operator on the customer service desk took the whole company’s Salesforce instance down by essentially having an agent perform a denial-of-service attack. He didn’t do anything wrong.”
How RSA Agent ID works: Discover, Secure, Govern
RSA Agent ID ships with three modules — Discover, Secure, and Govern. They are available standalone or as one system on the RSA Unified Identity Platform. The goal is simple: find every agent, enforce policy at tool‑call depth, and produce evidence for regulators.
Discover scans endpoints (via connectors into tools such as CrowdStrike and Zscaler), devices, network, and applications in real time. It finds sanctioned and shadow agents and MCP servers, and registers each as a first‑class identity with an owner, risk tier, and lifecycle state. Records link to existing identity providers, including Microsoft Entra ID, Okta, and AWS IAM.
Secure is an inline AI/MCP Gateway that checks every tool call against policy at tool and argument depth. Calls within policy are allowed, calls against policy are denied, and high‑risk calls are escalated to the registered owner. Approvals go through an out‑of‑band, authenticated channel with phishing‑resistant credentials that agents cannot access.
Govern logs every governed action and maps evidence to ten regulatory and industry frameworks out of the box, streaming it to the customer’s SIEM. Regulators want to see that a policy existed at the time, who approved it, and what actions occurred — in indelible logs.
“Every agent should have an owner... It should be attached to a human identity.”
“Regulators want to know if you had a policy in place at the time of an incident, who approved it, what actions took place, and they want to see that in indelible logs.”
Human assurance, not endless human‑in‑the‑loop
RSA avoids approve/deny fatigue. Instead, a risk engine balances autonomy and control. Only actions that cross a defined risk threshold reach a human approver through a separate channel.
The scoring considers three dimensions: the user (is this expected behavior?), the action (read, write, or riskier), and the data with the endpoint (how sensitive is the target). A refund agent might auto‑process refunds under $500, while larger ones need the owner’s sign‑off or a second approver in a built‑in workflow.
Customers define what counts as high risk, with AI‑assisted suggestions. Each organization knows its business risk better than anyone. This tunes control to stop what truly matters without crushing useful autonomy.
The idea is to replace mindless “click yes” with targeted human assurance where it counts. That raises security without losing the speed agents bring to operations.
“A hundred prompts a day is just an invitation to say yes. It’s another form of denial-of-service attack.”
Layered defense, delegation, and a 30‑day pilot
Agent ID is not a silver bullet; it is a layer in defense‑in‑depth. Policy can catch malicious instructions at tool‑call depth, but a legitimate‑looking request from a stolen device is different. You also need API gateways, firewalls, fraud detection, and traffic inspection. A key design principle is to keep the authorization channel separate from the agent’s channel.
RSA is candid about gateway bypass too, like coding agents lifting another team’s API keys from a repository. Other enterprise controls must catch that. We do not need to reinvent security — we need an agentic layer on top of what already works.
It is also critical to close delegation‑based escalation. When agents spawn sub‑agents or hand off tasks, Agent ID enforces an inherited permission model at tool execution: an agent can only enable another with the entitlements it was granted. Attempts to leverage someone else’s permissions are blocked at runtime.
For CISOs, the 30‑day pilot starts with three questions: which agents actually run; who owns them; can you kill them. The recommendation is to connect a few key systems and run Discovery. Results usually surprise and create momentum to assign owners and build policy. Discover and Secure will be generally available on November 16, 2026, with Govern following in the first half of 2027. Before granting more autonomy, ensure you can discover, authorize, limit, and kill your agents.
“We don’t walk on water.”
“An agent can only enable another agent with the entitlements it was granted... He doesn’t have those permissions. Denied.”
Based on the provided material.
