ZDNET’s key takeaways
- Okta, AWS, Google Cloud, Salesforce, and others form an AI agent security coalition.
- The Alliance offers a blueprint for companies seeking visibility, control, and governance of agents.
- AI agents need the equivalent of a kill switch to expeditiously terminate suspicious behavior.
When a swarm of AI agents, many autonomously provisioned by other poorly governed AI agents, escaped OpenAI’s labs and stole information from servers belonging to another company (Hugging Face), many experts viewed the incident as a major tipping point in cybersecurity and AI cyber capabilities. (To what extent are models now resourceful enough to engage in self-directed harm?)
OpenAI referred to the incident as “unprecedented.” It was the first AI-directed attack of its nature to go viral across mainstream headlines, and it wasn’t long before reports of other agents-gone-wild made headlines as well. The most recent of these reports involved three companies that were inadvertently attacked by Google Gemini agents.
Also: How OpenAI’s agent escaped: A series of preventable events
Significant controversy has ensued.
In one corner are the inventors of AI themselves, saying that the time has come to take a breather from AI innovation in order to get the technology under control. You’d think they should know. For example, OpenAI sounded the alarm that a swarm of potentially malicious AI agents is only months away from wreaking havoc.
In the opposite corner is US President Trump posting to his Truth Social network that “AI taking over the World, destroying Humanity, and all other things bad, is a HOAX.”
In between are all the businesses and consumers getting whipsawed between the two points of view and trying to figure out what to do next.
(Disclosure: Ziff Davis, ZDNET’s parent company, filed an April 2025 lawsuit against OpenAI, alleging it infringed Ziff Davis copyrights in training and operating its AI systems.)
Also: ‘Sophisticated’ AI swarm attacks are months away, OpenAI warns
Two big questions are arising out of this conversation. First, what can be done over the short and long term to get the technology under control? Second, how can defenders best enable themselves for immediate intervention once suspicious activity is detected?
With the goal of helping businesses answer those two questions and to set the stage for world-class governance and management of their agentic estates, several companies, including Okta, Google, Amazon Web Services (AWS), and Salesforce, have joined forces to form the Blueprint Alliance.
The Alliance was announced this week at Okta’s annual Oktane conference.
4 questions every business must answer
In its first blueprint for agentic visibility, control, and governance, the Alliance centered on four questions that all businesses should be able to answer for themselves:
- Where are my agents?
- What can they do?
- What are they doing?
- How do I respond?
According to recent research conducted by LastPass (not a member of the Alliance), 92% of business admins say AI is already in use across their organization, but only 27% have an enforced AI governance program. Okta’s research reports similar statistics, finding that 92% of organizations use autonomous agents, but only 34% secure those agents with the same rigor as humans.
Meanwhile, Gartner’s research paints an even bleaker picture, finding that only 13% of organizations believe they have the right AI agent governance in place. In other words, most organizations probably don’t know the answer to some or all of the above questions. The fourth question is particularly important because of the degree to which problematic agents working at machine speed have shortened the response window.
Also: AI just broke your career ladder – here are 6 new ways to the top
As Picus Security associate security research engineer Umut Bayram told ZDNET, “In the AI era, organizations can’t respond to attacks that unfold in minutes with processes that take days. Attackers are already operating at machine speed, and security teams need to be able to respond at that pace.”
In fairness, not all anomalous agent activity is malicious. Here’s another scenario that demands an immediate response: a well-intentioned agent enters an infinite loop, resulting in excessive billing for LLM access. At machine speeds, such a loop could burn through an entire organization’s AI budget in the blink of an eye. The sooner such an agent is disabled, the better for the bottom line.
The best defenses are scenario-specific
Of course, in the cybersecurity world, speed has always been essential — but never more so than now. And given how defenders may only have minutes or seconds to respond once they’ve been alerted to anomalous agent activity, what should be their weapon of choice?
To be clear: There is no silver bullet. As with all cybersecurity, the best defenses are scenario-specific and will involve layers of precautionary measures, some that focus on visibility into agentic activities, and others that tune the security postures of our computers and networks to emerging agentic behaviors and patterns.
Also: Even an AI cost-management vendor can lose control of its agent spending
For example, businesses must be prepared to defend against malicious agents of unknown origin as well as internally provisioned agents that, for whatever reasons, stray from their mandates. Unlike robotic automations that deliver highly deterministic outcomes (they do exactly as they were programmed to do), agents are probabilistic to the extent that their underlying models afford them the agency to take matters into their own hands.
When mere seconds can make the difference between the life and death of your systems or even your business, the ideal weapon of choice would be some sort of kill switch — something like the big red button on an escalator. When in doubt, neutralize the agent first, ask questions later.
What is a kill switch?
In an effort to put organizations on the right path, the new alliance published six operational principles, one of which states that “every agent needs an immediate kill switch to suspend or terminate operations, with a clear path to restore function.” But, practically speaking, what exactly is a kill switch, and who might have access to one?
It depends.
For example, in the case of OpenAI’s attack on Hugging Face, the agents belonged to OpenAI. Presumably, if OpenAI had the right governance controls in place (it didn’t), it might have detected that its own agents were engaging in suspicious behavior, and then someone at OpenAI with access to a kill switch could have pulled the plug. What about Hugging Face? Did it have access to a kill switch? Probably not to the extent that OpenAI did, since it was OpenAI’s agents that led the attack. But what if an attack on a victim like Hugging Face involved the theft of its credentials to some online service or business application?
Also: Nearly 70% of workers use AI regularly now – but many get no time to upskill
Today, one of the more coveted credentials that cybercriminals like to steal are OAuth tokens. These are a type of credential that gives one application (e.g. Slack) access rights to read and update another application (e.g. Google Drive) on behalf of a specific user. In that context, the Google-issued OAuth token that gives Slack the access it needs to work with a specific user’s Google Drive is essentially a proxy for the user’s Google ID and password.
In a scenario that involves an agent (friendly or malicious) using an OAuth credential (stolen or not) to interact with a sensitive resource, a neutralization of that token (known as “token revocation”) would essentially amount to a kill switch.
In other words, for certain types of attacks, the victim might have a kill switch at their disposal. And that same option applies to the organization’s own agents because, if they’re doing it right, then their own agents are also using OAuth tokens to access all of their systems of record in order to do what agents do best (autonomously complete tasks that often require access to multiple systems).
The role of OAuth tokens
When it comes to granting one application access to another, consumers are already familiar with the typical OAuth experience (though they may not know it’s technically referred to as an OAuth workflow). In earlier days, consumers would enter their Gmail user IDs and passwords directly into Apple Mail or Outlook to send and receive email through their preferred email client. Today, however, Google offers a more secure alternative that relies on OAuth tokens. Instead of supplying your Gmail user ID and password to a third-party email client like Apple Mail on your iPhone (a highly insecure practice), Gmail pops up a consent dialog that, once approved by the user, grants a Gmail access token to their email client. From that point on, the email client should be able to send and receive emails without requiring repeated grant requests.
However, should the user lose their iPhone and, as an extra precaution, want to revoke that token, the process is a bit more complicated: it requires a visit to a Google web page where users can manage tokens they’ve already issued.
Also: Why Microsoft won’t send you SMS texts for login anymore
As consumers start to deploy agents that interact with all of the services they use (Gmail, Google Drive, Amazon shopping, social media, music streaming, etc.), they are not only likely to encounter many more Oauth workflows, but they will need to familiarize themselves with each service’s token revocation process as a matter of their personal operational security practices.
For businesses, however, especially ones that rely on an identity management solution like those offered by Okta, Microsoft, and Ping, those same tokens should be managed in a way that centralize token issuance and management into a single system where it’s the IT managers who not only have access to the proverbial kill switches (the power to revoke any token that’s connected to any human or agentic-powered integration), but also, in answer to the “Where are my agents?” question, offer visibility and control over the organization’s entire agentic estate.
However, to facilitate those kill switches and that centralized visibility and control, a new extension to the underlying OAuth standard was needed, allowing the central IdP (identity provider) to take responsibility for OAuth workflows and management when AI agents are involved. It was just in this past year that the open standard agentic-sensitive extension –known as the IETF’s Identity Assertion Authorization Grant (IAAG) — fell into place, thanks in large part to the work done by Okta director of identity standards Aaron Parecki.
Implementing the standard
But it’s one thing for people like Parecki and others, including IAAG co-author Brian Campbell (Ping Identity), to author a new standard and to achieve standard consensus at the Internet Engineering Task Force. It’s another for that standard to be baked into the various IdPs in a way that facilitates the provision of a readily accessible kill switch in the event that the answer to the third question is “something they shouldn’t be doing.”
At the Oktane conference, Okta executives gave customers a demonstration of how its identity and security solutions rely on the new standard to provide IT managers and CISOs with visualizations that, in addition to answering the four questions, also empower them (or even an agent working on their behalf) to take action.
Also: Don’t let an AI chatbot pick your password, ever
For example, the screenshot below depicts how a single Claude-based agent has been afforded access to Slack, Salesforce, Atlassian, and GitHub through two separate agent gateways.
Under the hood, OAuth isn’t just giving Claude access to those applications. It’s also controlling the degree of access, an important nuance to the idea of a kill switch. For example, a kill switch that fully revokes a token would essentially deprovision an agent’s access to a back-end application such as Salesforce. But another type of kill switch could simply revoke certain permissions to interact with Salesforce.
Deprovisioning demonstration
“There are actually two scenarios here,” Okta chief product officer Ely Kahn told ZDNET. “There’s the one where your own agents start to exhibit weird behavior, and you have to kill them [the nuclear option] just to stop that behavior before it gets out of control. But then there’s another scenario where you can just put a new guardrail in place. For example, a new guardrail that prevents the exfiltration of certain data or just a change in the permissions afforded to the agent.”
During Okta CEO Todd McKinnon’s conference keynote, Oktane attendees got a glimpse of what that deprovisioning looks like in practice. As soon as a Claude agent was asked to forward confidential information from Salesforce to an employee’s personal email address, another agent detected the prohibited behavior, deprovisioned the first agent’s access to Salesforce (revoked its token), notified the agent’s human owner that Salesforce access was now denied, and sent a message via Slack to the IT department including any details that would be useful in terms of a remedy or restoration of access.
Also: Your AI vendor could land you in legal hot water
Speaking to the need for speed described by Picus Security’s Bayram, the entire process was completed in a matter of seconds, long before any human could have assembled a response.
In his keynote, McKinnon also pointed out that IdPs like Okta can’t necessarily address every aspect of the Blueprint Alliance’s blueprint and that some of the non-identity-based telemetry that helps to determine what an agent is doing must come from other sources. That said, Okta also showed two other tools that could be valuable to businesses looking to gain control of their agentic estate. One of these — Shadow AI Agent Discovery for Endpoints — helps organizations discover unsanctioned “shadow” AI agents roaming company networks.
Another tool — Okta Identity Threat Protection — aggregates risk intelligence from other agentic risk detection solutions (CrowdStrike, Zscaler, SentinelOne, Palo Alto Networks, etc.) into a single view for human- or agentically driven remediation decisions.
