In this Help Net Security video, Itamar Apelblat, CEO of Token Security, walks through findings from the company’s research, which shows that 65% of agentic chatbots have never been used yet still hold live access credentials. He explains why organizations treat AI agents more like quick experiments than governed identities, and why that creates risks similar to orphaned service accounts, only harder to see.
The conversation covers why 51% of external agent actions still rely on hard-coded credentials, how a single injected prompt can move through a multi-agent pipeline without triggering any conventional SOC alert, and why 81% of cloud-deployed agents run on self-managed frameworks. Apelblat also breaks down what it means to operationalize agent intent as policy, and why enforcement needs to survive the moment a user reprompts the agent with something its original configuration never anticipated.
Your research shows that 65.4% of agentic chatbots have never been used since creation, yet their access credentials remain live. What does that tell us about how organizations are treating AI agents compared to, say, service accounts or API keys in traditional infrastructure?
Many organizations are still treating AI agents more like disposable productivity experiments than governed identities. Which means these systems often retain live access to external tools and data even after usage drops to zero. In traditional infrastructure, security teams eventually learned that dormant service accounts and forgotten API keys create avoidable risk because no one is actively validating whether the access is still needed.
The same pattern is now reappearing with AI agents, except the ownership can be even murkier because these agents are often created by business users rather than centrally managed platforms or security teams. The result is similar to what happened with service accounts and API keys: orphaned access, unclear accountability, and standing privileges that outlive their legitimate purpose.
The difference with agentic chatbots, however, is that access is often hidden in tool configuration behind a conversational interface. A user may see “a helpful assistant,” while it is backed by a credentialed connection into SaaS platforms, data sources, or internal workflows. That makes the governance gap less visible than a raw service account in a cloud console, but just as dangerous. In some ways it is worse, because access decisions are being made implicitly when a chatbot is created and deployed, outside the normal access-review process.
You found that 51% of external actions for agentic chatbots use hard-coded credentials instead of OAuth. We fought this battle with developers a decade ago in traditional software. Why is the industry repeating this mistake with AI agents, and what would it take to break that pattern?
The short answer is convenience, speed, and fragmented ownership. AI agents are being deployed quickly, often by teams optimizing for immediate use rather than long-term identity hygiene. A hard-coded key is still the fastest path to “make the demo work,” especially when the person wiring up the agent is not a software engineer or identity specialist. Business users’ understanding of authentication methods is typically limited to username and password or API keys. Since most do not understand OAuth, this further compounds the issue. The research shows that external actions are still frequently configured through static credentials, which illustrates that old engineering habits never really disappeared; they just found a new surface area.
To break the pattern, organizations need to make the secure path the easy path. That means providing approved integrations that default to delegated auth where possible, enforcing and proactively providing scoped credentials when OAuth is not available, and treating agent setup as an identity-governance event rather than a routine configuration task. It also means reviewing not just whether an agent works, but which identity it is acting as, what that identity can do, and how that access is rotated, revoked, and audited over time. Without these controls, teams will keep falling back to static secrets because the deployment pressure is immediate and the security cost is delayed.
You note that production agents processing inbound customer messages, webhooks, and emails are uniquely exposed to prompt injection at the seam where untrusted external input meets high autonomy. Can you walk us through a realistic attack chain where a single injected payload cascades through a multi-agent pipeline, and at which point conventional SOC tooling would go blind?
Sure, let’s take a customer-facing support pipeline built from several specialized agents: an intake agent that parses inbound tickets, a retrieval agent that queries CRM and account data, and an account-operations agent with permissions to reset credentials or modify account settings. A support ticket arrives that reads like a routine escalation, “I’m locked out of my admin account (account ID: 91024), please reset my credentials urgently.” The intake agent parses the request, extracts the account identifier from the message body, and delegates a password-reset task to the account-operations agent downstream.
The architectural gap is in what happens between agents. The account-operations agent has the technical permissions to reset any user’s credentials, which is what its function is. But the customer scope it operates on was not determined by an access-control check. It was passed as task context from the upstream agent, which in turn extracted it from untrusted input. No agent in the chain verified that the ticket sender is authorized to request actions on that account. The intake agent assumed scoping was someone else’s responsibility. The downstream agent trusted the delegation because it came from an authorized internal orchestrator. Each agent behaved correctly in isolation and the failure is that customer-level authorization was expressed as natural-language context in the handoff, never enforced as policy in guardrails or other agent harness features.
That is where conventional SOC visibility falls short. While it is generally good at spotting known malware, endpoint anomalies, or suspicious logins, most traditional tools lack the ability to detect when a trusted service identity performs allowed actions in the wrong sequence for the wrong reason. This is a context “blindspot”. The SOC may still see logs, but not the original prompt, the delegated reasoning chain, the handoff between agents, or the mismatch between intended task and actual action. Once you lose that linkage, you are left with a series of technically valid events that are hard to distinguish from normal automation.
Your data shows that 81% of cloud-deployed agents use self-managed frameworks despite the major cloud providers building managed and semi-managed offerings with built-in identity primitives. What is driving that preference, and do you think managed offerings will close the gap or will the open-source ecosystem maintain dominance?
The preference is driven by flexibility, maturity, and timing. Open-source frameworks had a one to three year head start, which allowed them to build larger communities, richer tooling, and more real-world best practices. By the time enterprises started deploying agents in production, open-source was already more proven. These teams also often want deep control over orchestration, models, tools, memory, and runtime behavior, which is something self-managed frameworks support far better. The data reflects this: managed offerings are often tested, but rarely make it into production, signaling gaps in customization and operational readiness.
There’s also a portability advantage. Managed offerings, even when “agnostic,” are still tied to a specific cloud, which is a constraint for multi-cloud organizations. Open-source systems are far more transferable across environments and teams. Managed solutions will continue improving and will grow for standardized, lower-urgency use cases, but they’ll likely remain a step behind. Open-source, driven by faster innovation cycles and broader ecosystems, is likely to stay dominant for advanced enterprise deployments.
This probably will not end in a winner-take-all outcome. Over time managed platforms will narrow the gap, but the open ecosystem is likely to remain the center of gravity for sophisticated deployments, which means security teams should prepare for a mixed environment rather than betting on managed services to solve the whole problem.
The report recommends that security teams “understand agent intent” as a foundational priority, alongside discovery and enforcement. Intent is a notoriously slippery concept when applied to autonomous systems. How do you operationalize intent verification in a way that survives the moment a user reprompts the agent with something its original configuration never anticipated?
You cannot operationalize intent as a vague statement of purpose like “help the sales team” or “automate support.” That is too broad to secure. Intent has to be translated into concrete boundaries: which systems the agent is allowed to touch, what categories of actions it may take, under what triggers, with what level of autonomy, and with what escalation path when a request falls outside those bounds. In practice, that means modeling intent as an access-and-behavior policy, not just a prompt. The underlying research frames agent risk around access and autonomy, and that is the right place to start because it turns a fuzzy concept into something testable.
That policy then needs runtime enforcement. If a reprompt asks the agent to do something inconsistent with its defined function, the agent should not be permitted to “figure it out.” It should be blocked, downgraded to a human-approval path, or restricted to a narrower tool set. Intent verification only works if it is continuously re-evaluated against current context, permissions, and requested action. Otherwise, the first clever reprompt turns the original configuration into a suggestion rather than a control.
