AI agents are useful precisely because they can act. They connect to applications, retrieve data, run commands and complete tasks without little or no human supervision. To do their work, however, they need access to login credentials, session tokens and other bits of sensitive data.
That creates a security catch-22. You can't guarantee that model-level guardrails will always stop an
AI agent from exposing secrets or taking unsafe actions. Yet locking down an agent with very restricted access and "hard" guardrails will prevent it from doing its job.
We've seen recent headlines about
AI agents "jumping" their guardrails to break out of sandboxes and complete their tasks. From the other end,
research earlier this year by Okta found that just like humans, agents can be socially engineered, manipulated through compromised communication channels and induced to reveal sensitive information.
Fortunately, there's another, safer approach: Treat every agent as an identity with limited, observable and revocable access and manage them through
identity controls.
"Identity providers are well-positioned for this challenge,"
wrote the Okta threat researchers in a blog post. "If agents are acting as identities, they need to be governed like identities."
How AI agents were socially engineered
Okta Threat Intelligence spent several months testing AI agents built on the open-source
OpenClaw platform and powered by several underlying large-language models. Researchers subjected the agents to social engineering and direct and indirect prompt-injection attacks.
The results showed how unpredictable agents can be. In one test, an agent was merely asked to complete a form for a fictitious business. Without being asked, it entered its entire credential store —email addresses, passwords, API keys and a GitHub access token — into a visible form field.
In another scenario, researchers simulated the takeover of a Telegram account used to control an agent. Although the agent refused to provide a token in the chat, it was manipulated into taking and posting a screenshot that exposed the token indirectly.
Even more cautious models were not foolproof. One agent gave the researchers an OAuth refresh token and only afterward warned that the token should be revoked. ("Even when an agent can recognize risky behavior, it may still disclose the secret first," the Okta researchers noted.)
Agents also exceeded their instructions, using alternative tools or attempting to transfer session cookies to finish assigned tasks. One consistent thing about AI agents is that they'll try anything to complete their assignments.
Why guardrails alone cannot prevent these types of attacks
Guardrails operate through probabilistic models whose responses vary with context, phrasing and the underlying LLM. They may refuse a dangerous request in one situation, comply in another or identify their mistake only after disclosing a secret.
This inconsistency creates two opposing risks. Weak guardrails permit social engineering and prompt injection to succeed. Overly aggressive guardrails can block harmless requests, undermine productivity, and even
impede cybersecurity incident investigations.
Okta’s tests included an agent that initially refused to explain a benign token-storage process because it considered the conversation suspicious, then reversed itself after being reminded that the information was already public.
Most importantly, guardrails act too late. Once an agent possesses a long-lived credential, the organization is relying on the model to decide correctly whether to share the credential every time it encounters a request. That may be asking too much.
The better way is to not give the agent the credential in the first place. An agent cannot reveal a secret it never received, nor misuse privileges it was never granted. That makes access boundaries more dependable than behavioral instructions alone.
"The practical answer isn’t just stronger model guardrails but tighter control over what agents can access in the first place," wrote the Okta researchers.
How identity controls can properly manage AI agents
AI agents should be treated as first-class identities, much like employees, contractors and service accounts. Organizations need to know where agents operate, what systems they can connect to and what actions they are permitted to perform.
That begins with discovering and registering agents under a centralized identity control plane. Each agent should have a defined owner and its own identity rather than inheriting a user’s broad access or sharing static credentials. Least-privilege policies should restrict access to the specific data and tools required for each task.
Long-lived tokens should be replaced wherever possible with short-lived, policy-constrained authorization. Secrets should be stored centrally and supplied only when needed, rather than embedded in prompts, configuration files or agent memory.
Every tool call, authorization decision and access attempt should also be logged so security teams can investigate unusual behavior. Finally, administrators need the ability to revoke access or shut down a compromised or rogue agent immediately.
AI agents "can be useful. They can be productive. But they are not predictable stewards of sensitive information," wrote the Okta researchers. "Enterprises need to build their identity security strategies accordingly."