- In VentureBeat Intelligence's August survey, 99% of the 106 respondents naming a primary agent security layer chose a model or cloud provider, and 40% chose OpenAI.
- Among 68 respondents with agents in production, 62% run some or all agents on shared or human credentials, which makes actions harder to trace to one agent.
- Ask your team whether each agent has its own identity and whether you can switch off one agent without stopping the rest.
Locking a door and knowing who walked through it are different jobs. A new survey suggests many companies have bought the lock and not yet settled the second question. That is the argument here, and it is our interpretation of the findings, not the survey's own conclusion.
Who is guarding the agents
VentureBeat Intelligence ran its survey in August among respondents at companies with 100 or more staff. Two sample sizes matter. The security-layer question drew 106 respondents who named a primary layer. The identity question drew 68 whose organizations run agents in production. Both samples are small, so treat the figures as signals, not a count of all companies.
Of those 106, 40% named OpenAI's built-in guardrails as their first line of defense. The figure was 21% in July. Microsoft Azure followed at 22%.
Almost every answer went to the company that supplies the model or cloud the agent runs on. The 99% was split among OpenAI, Microsoft Azure, Google Cloud, Anthropic and AWS. Controls sold separately from the agent's platform were first choice for only about 1%. The one such vendor named was Okta for AI Agents.
The part that is easy to miss: identity
An AI agent works inside company systems using a credential, such as an API key or a login. When several agents use one key, the credential identifies the key, not the agent. So the credential's own record shows the key, not which agent used it. Other logs may still show that, but the survey did not ask.
The report names two consequences. Tracing an action to one agent gets harder. And stopping one faulty agent means cancelling a key its neighbors also depend on. There is a third risk. An agent that borrows an employee's login can reach much of what that employee can reach.
Just over a third of the 68 organizations with production agents, 38%, issue each agent its own scoped, managed identity. For the other 62%, at least some agents run on shared keys or human logins.
One caution applies to our argument. Reported incident or near-miss rates were about the same in the two groups: 54% with a separate identity for every agent and 55% among those sharing credentials. So the identity point concerns traceability and control. The survey does not show that shared credentials lead to more incidents.
The caveat about logs matters too. The survey measured how credentials are handled, not how activity is logged. It cannot say how many of these firms could still trace an agent by another route.
Saying and doing
The survey also asked respondents to pick one of four postures that best describes their program. The enforcing option reads "agents have scoped identities and permissions, enforced at runtime." Take the 37 respondents with production agents who chose it. In a separate question on credentials, 59% of them described a setup where some or most agents share keys or logins.
One reading is that these respondents described a goal rather than current coverage. Another is that they overstated how much is enforced. The data cannot tell which. Either way, a policy that says every agent is controlled is only as good as the identity beneath it.
Sandboxing, which runs risky agents in a walled-off space, is a minority choice. Just 9% said it best describes their program. When asked which tools they use, none of the respondents listed a sandboxing product. VentureBeat's account of the Hugging Face incident says OpenAI's test models broke out of an enclosure meant to cut them off from the internet. The survey did not ask about that incident.
What the numbers do and do not show
Incidents are not rare in this sample. The survey asked 109 respondents, whose firms run agents in production or a pilot, whether an agent had caused a security event in the past year. Some 59% said yes, counting incidents and near-misses together. About three in ten, 30%, reported a confirmed incident.
In the survey's terms, a near-miss is an event where a control stopped the agent before any harm. The report cautions that one catch says little about whether the same control will work next time.
Confidence differed by first-choice layer. Among the 42 respondents who rely on OpenAI's guardrails first, 43% said attackers using AI are ahead of their defenses. Among the 64 who named any other layer, 16% said so. The researchers say they cannot explain the gap. Incident rates for the two groups were too close to call, so the survey measured belief, not exposure.
Money has not followed the risk. Three in four organizations running agents, 76%, spend a tenth or less of their security budget on AI and agent security. Past incidents are associated with different plans, though the survey cannot show cause. Among firms that had an incident or near-miss, 91% expect to adopt new agent security within a year. Among firms with neither, 45% do.
Questions to put to your team
First, does every agent have its own identity, and can we show it? Second, if one agent misbehaves tonight, can we revoke it without stopping the others? Third, when our policy says permissions are enforced at runtime, which agents does that cover and which still use shared keys?
Fourth, who in our setup is independent of the vendor that built the agent? The survey shows where companies placed their trust. It does not show that the trust is misplaced. A lock from the manufacturer is still a lock. But a guest list is a different document, and an agent that cannot be told apart from its neighbors is much harder to audit.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: VentureBeat.
