Evidence at a glance
The mechanism in one line
Compress the visual or contextual input before the main reasoning path.
Route or verify the expensive step instead of repeating the full path.
Translate the mechanism into a bounded deployment or evaluation check.
RSA Is Not Simply Adding Another Agent Dashboard
RSA announced RSA Agent ID at The AI Conference in San Francisco. The platform is designed for regulated sectors such as finance, government, healthcare, and critical infrastructure. Its stated purpose is to discover AI agents and MCP servers, enforce policy over their tool calls, and preserve evidence of governed actions for audit. RSA says Discover and Secure are scheduled to ship on November 16, 2026, while the three modules can be used separately or together on the RSA Unified Identity Platform.
The important change is not that enterprises are getting another AI security product. Agents are pushing identity into a space that existing models were not designed to handle. They can hold credentials, inherit entitlements, access data, and write to systems of record. The question is no longer only whether an employee has access. It is who this changing and autonomous actor is, who owns it, and who can stop it.
An Agent Can Turn a Misread Instruction into an Infrastructure Incident
The most useful part of Jim Taylor’s example is that it required no attacker. A customer success employee asked an agent to go to Salesforce and get all the data in order to build customer health charts. The agent began downloading the entire Salesforce database. Salesforce’s defenses interpreted the traffic as an attack, shut down the instance, and warned the company that it appeared to be facing a denial-of-service attack.
This was not a conventional malicious privilege escalation, nor was the employee deliberately bypassing controls. The natural-language task failed to specify data scope, request rate, purpose, or acceptable boundaries, while the agent optimized for completing the task. In a conventional account model, this might look like a permissions problem. With an agent that can call tools repeatedly, it becomes an execution chain from an ambiguous objective to a large-scale operation. The source also cites an IBM estimate that shadow-AI incidents cost $670,000 more on average than standard incidents. The material does not provide the study’s sample or methodology, so the figure is better treated as a risk signal than as a precise budgeting input.
Discover, Secure, Govern Map to Three Different Gaps
Agent ID can be understood as three connected but distinct actions. Discover uses connectors into tools such as CrowdStrike and Zscaler to scan endpoints, devices, networks, and applications in real time. It looks for sanctioned and shadow agents as well as MCP servers, then registers each agent as a first-class identity with a named owner, risk tier, and lifecycle state. It links those records to existing identity providers such as Microsoft Entra ID, Okta, and AWS IAM. Its job is to answer what is running in the enterprise.
Secure places enforcement at the agent’s tool calls. As an inline AI and MCP Gateway, it evaluates each call down to the argument level, allows calls that fit policy, denies calls that do not, and escalates high-risk actions to the registered owner. Govern records governed actions, maps the evidence to ten regulatory and industry frameworks, and streams it to the customer’s SIEM. The separation matters. Without Discover, policy has no reliable subject. Without Secure, registration is only an inventory. Without Govern, an organization may struggle to show what policy existed, who approved an action, and what the agent actually did.
The Trade-Off Is Not Automation versus Humans, but Which Actions Need Humans
RSA is not placing a human approval step after every prompt or tool call. Taylor argues that asking people to process one hundred approvals a day would encourage mechanical approval and create another form of denial-of-service. Agent ID instead uses a risk engine that considers three dimensions: whether the user’s behavior is expected, whether the action is a read, a write, or something more dangerous, and how sensitive the target data and endpoint are. Only actions above a threshold are sent to a human.
The design changes the goal from keeping a human in every loop to providing human assurance for high-risk actions. The source gives a directional example: a refund agent might process refunds below $500 automatically, while more consequential actions are escalated. Approval takes place through an out-of-band authenticated channel using phishing-resistant credentials that agents cannot access. The operational judgment is clear. If policy depends on employees watching every action, the control will fail under volume. If thresholds are too permissive, automation becomes an access path without a clear accountable operator.
Scale Will Break Inventory Before It Breaks Policy
The scale comparison explains why registering a few service accounts is no longer enough. Gartner expects a typical Global Fortune 500 enterprise to run roughly 150,000 AI agents by 2028, up from fewer than 15 in 2025. At the same time, only 13% of organizations believe they have the right agent governance in place. The forecast should not be converted directly into a deployment count for every company, but it does identify a clear direction: agents may be created faster than security teams can inventory them.
A medium-sized global bank told RSA that it had no agents because policy prohibited them. RSA’s audit found more than 4,000 agents running in the enterprise. The contrast shows why “no approved agents” does not mean “no agents.” Employees may create agents to meet a deadline, then leave them running without anyone reviewing their permissions, data access, or ownership. For technical leaders, lifecycle management is not a compliance add-on. Creation, assignment, permission changes, suspension, and deletion must all be traceable if the organization is to establish a real control boundary.
The Boundary of Agent ID Is Coverage and Policy Quality
RSA’s design puts an often-missed fact at the center: agent governance is first an identity problem, not only a model-safety problem. Binding an agent to a person, routing calls through a gateway, and sending evidence to a SIEM can establish accountability and reduce the chance that an ambiguous instruction reaches a system of record unchecked. But the material describes the product’s design and release plan. It does not establish that the platform will discover every agent, cover every runtime, or correctly understand business context for every call.
Organizations evaluating such a system should ask three operational questions. What endpoints, networks, and applications can Discover cover, and how will agents outside that coverage be found? Can Secure express data scope, call frequency, arguments, and target resources rather than relying mainly on read-versus-write categories? Can Govern preserve the complete chain needed to reconstruct an action, including the agent owner, approver, policy version, and outcome? Until those questions are answered, Agent ID should be viewed as a starting point for an agent governance boundary, not as proof that agent runaway risk has been solved.