The biggest unlock for production AI agents isn't better models—it's accepting that agents are just applications.
That sounds obvious. Maybe even boring. But this one realization cuts through years of confusion, eliminates entire categories of "new" security problems, and makes multi-user agent deployment actually feasible.
Here's why it matters.
The Non-Human Identity Trap
When agents started hitting the enterprise conversation around 2023, identity companies rushed to define the problem. "Agents need non-human identity," they said. "These are silicon-based employees. They need their own user accounts, their own permissions, their own everything."
It made intuitive sense at the time. If agents are autonomous, intelligent, and making decisions, shouldn't they have their own identity? Their own seat in your IAM system?
No.
Because when you try to implement non-human identity in practice — for agents acting on behalf of users — you immediately hit a wall: who’s the identity when the agent accesses Gmail?
Is it the agent? Is it you? Is it some hybrid entity that exists in a quantum superposition of permissions? The answer gets messy fast—and that mess compounds when you're trying to build systems that need to work reliably, securely, and at scale.
The Insight That Changes Everything
Here's what we realized after building dozens of production agents: agents are just applications with large language models in specific parts of the workflow.
Not a new category. Not a revolutionary paradigm shift. Just really fancy workflow automation that happens to use non-deterministic reasoning in certain places.
Think about it:
- Cursor is VS Code with an agent inserted into the editing workflow
- ChatGPT is an app in the App Store (one of the most downloaded)
- Spotify uses models for recommendations—it's not an agent, but it has non-determinism built in
The line between "app" and "agent" is already blurring. Traditional apps are adding conversational interfaces. Agent-first products are beefing up into full applications. At the end of the day, it's all just workflow automation—the same thing software has been doing since mainframes.
Why This Matters for Security
Once you accept that agents are applications, your existing security infrastructure suddenly works. You don’t need new constructs. You don’t need to invent non-human identity. You already know how to do application security.
Here’s how OAuth works for agents: the application gets its own client ID and secret—this identifies the app itself, not the user. When a user authorizes the app to access a resource (like Gmail or Slack), they grant scopes that represent the intersection of two things: what the app wants to do and what the user is actually permitted to do. If the agent hasn’t been authorized yet, we trigger an OAuth flow. Once authorized, if the user is allowed to perform the action, we execute. If not, we block.
The important part isn’t just how authorization works, but when it happens. Instead of pre-approving every possible action up front—how most apps and agents still handle OAuth—Arcade authorizes after the model decides what it wants to do. This “post-prompt” approach enables just-in-time authorization: access is granted only for the specific action being taken, exactly when it’s needed. It’s faster, safer, and feels natural to the user. You don’t have to connect fifteen services before doing anything useful—the agent just asks for what it needs, when it needs it.
This is called delegated user authorization. It’s been working for web apps for over a decade. And it works just as well for agents.
The Problem Everyone Else Is Solving Wrong
Most agent builders today use one of two broken approaches:
1. Service Accounts (The RAG Problem)
You give the agent a service account with broad access. This creates a privilege escalation vulnerability. What happens when an intern uses the agent to access sensitive data they shouldn't see?
Most companies solve this by severely restricting the agent—limiting it to near-public information. That's why most support chatbots on websites can regurgitate their public knowledge base but can't tell you where your order is. It's because they don't have a way to guarantee that I can't prompt engineer my way to getting your account information—meaning there's no clear way to assert what I have access to through the agent.
2. Direct User Credentials
You store the user's credentials directly in the agent setup. This is how most desktop MCP servers work. This technically works for single-user scenarios, but it doesn't scale. And while it's secure, it's unsafe—if the agent has full inheritance of your credentials, it could delete files and emails because you also have that ability. In Cursor, I've seen it try to delete my root directory. Thankfully it didn't have sudo access and was blocked. It apologized profusely, which was very kind.
Retry
What Production-Grade Agent Auth Actually Looks Like
At Arcade.dev, we built the first system that lets agents go through OAuth flows inside the agent loop, after the user prompt.
This means:
- The agent has its own OAuth application registration
- The agent gets scoped permissions (read emails, not delete them)
- The user maintains their existing permissions
- Authorization happens in real-time, on every tool call
- No service accounts with god-mode access
- No hardcoded credentials waiting to leak
When an agent tries to access Slack on your behalf, we check: Can this agent, on behalf of this user, perform this action on this resource?
If the agent hasn't been authorized yet, we pause the request and trigger an OAuth flow—a standard authorization screen your security team already understands. Once authorized, we check the user's permissions. If the user is allowed to perform the action, we execute. If not, we block.
The agent never stores credentials. Neither does the model — it only receives authorized outputs, never the secrets themselves. The agent just makes requests, and we enforce policy based on the intersection of agent scopes and user permissions.
Why This Reduces Complexity
Treating agents as apps means:
Your security team doesn't need to learn new concepts. OAuth, OIDC, SAML—it all still works. No new identity paradigm to architect around.
Your agent doesn't need superuser access. Scoped permissions let you deploy agents into production without creating privilege escalation risks.
Your IAM stack doesn't need to change. Whether you're using Okta, Active Directory, or Saviynt, your existing access policies apply. We just help enforce them at the tool-calling layer.
Your developers can focus on building agents, not solving auth. Instead of spending six months figuring out how to securely connect an agent to Gmail, they wire up a toolkit and ship.
The Future Is Already Here
Enterprises building production agents are already converging on this model—often without realizing it.
They start by inserting a large language model into a workflow. Cool, now it's an agent. Then they realize it needs to connect securely to internal systems. So they implement OAuth. Then they build another agent that needs to talk to the first one. So they add an MCP interface. Then a tool needs more logic, so they add reasoning inside the tool itself.
Before long, they've built a sophisticated multi-agent system that's actually just a well-architected application with LLMs in specific places.
They didn't set out to prove a philosophical point. They just solved the problem in front of them. And the solution looked like... an app.
What This Means for You
If you're building agents:
- Stop trying to invent new identity constructs
- Use OAuth the way it was designed
- Treat your agent like an application in your security stack
- Scope permissions tightly and enforce them at runtime
If you're evaluating agent platforms:
- Ask how they handle multi-user auth
- Avoid anything that requires service accounts or hardcoded credentials
- Look for delegated authorization with real-time policy enforcement
If you're a security leader:
- The good news: your existing security model works
- The challenge: enforcing it at the tool-calling layer requires new infrastructure
- The win: no privilege escalation, no new identity paradigm, no rearchitecting IAM
The Bottom Line
Agents aren't a new category of identity. They're applications that happen to use non-deterministic reasoning in parts of their workflow.
Accepting this doesn't make agent security trivial—there's still real work to do around token management, scope enforcement, and runtime authorization. But it makes it solvable using patterns and infrastructure your team already understands.
You don't need to wait for the industry to invent non-human identity standards. You don't need to redesign your IAM stack. You just need to enforce application-level authorization at the tool-calling layer.
That's what we built Arcade.dev to do. And it's why companies are shipping production agents in weeks instead of waiting years for the "agent security" problem to be solved.
Want to see how this works in practice? Check out our docs or talk to us about deploying agents with real OAuth in your environment.
