A few months ago, a team I was working with showed off their first real AI agent to leadership. It pulled live deal data from the CRM, summarized it, and drafted a follow-up plan. Smooth. Impressive. Everyone leaned in.
Then the head of security raised a hand: "Whose data is the agent seeing right now?"
The presenter paused. The agent was using a service account with read access to everything. Every deal, every rep, every region. The demo wasn't broken - but the auth model was. Two weeks later the project was on hold pending a "delegated identity design."
That conversation is happening in a lot of rooms right now.
AI agents are moving from notebooks into production workflows. They query CRMs, write to project boards, pull from data warehouses, and call internal APIs. Each of those systems already has a permission model - usually one built around human users, not autonomous software.
The moment your agent does real work across real systems, you inherit every one of those permission models at once. What makes this an AI problem, not just an integration problem: in a traditional app, the user's actions are explicit and pre-defined - every API call traces back to code a developer wrote. With an agent, the LLM chooses which API to call and with what arguments, at runtime - and adversarial input in the data the agent reads can steer those choices.
The agent must act on behalf of a specific user, with that user's exact permissions, across multiple external platforms - and prove it at every hop.
Two scenarios make this concrete:
A sales rep asks "What's the latest on the Acme deal?" Reps can only see deals they own. A service account either sees everything (security risk) or sees a different data surface entirely (wrong answers). The agent needs to hit the API as that rep.
"Create a follow-up task for every stale deal." Now the agent reads from a CRM and writes to a PM tool. It needs valid credentials for both platforms, scoped to that user, obtained through separate OAuth flows - and a write carries fundamentally different risk than a read.
Service accounts violate least privilege, destroy audit trails, and can't replicate per-user platform permissions. Your next SOC 2 audit will not be fun.
Passing the user's IdP token through doesn't work - that token authenticates them to your system, not to the CRM, the PM tool, or the data warehouse. Those are separate OAuth relationships.
Authenticating the agent itself solves the wrong problem. Proving the agent is legitimate doesn't tell the downstream platform whose data it should return. What's missing is delegated authorization - a way for the agent to act with a specific user's permissions, not just with valid credentials of its own.
Production solutions converge on four components:
One principle to remember: keep credentials away from the LLM. The agent processes untrusted input; it should not hold the keys.
In practice this maps to existing standards: OAuth 2.0 Token Exchange (RFC 8693) for the credential exchange step, and increasingly to MCP's auth spec for the agent-tool boundary.
OAuth scopes are too coarse to describe individual agent actions. A token with crm.write can update one record or wipe out the entire opportunity table - the scope alone doesn't distinguish them. That's why every credential exchange should also carry an action intent: a per-request declaration of what the agent is about to do, on which resource, in which context.
Concretely, intent is a structured payload sent alongside the identity token at the policy check step. It should include:
The policy enforcement point uses intent to decide more than just "is this user allowed?" It can compare the declared intent against what the user actually asked for, require step-up confirmation for high-risk actions, rate-limit by action type, and produce an audit log that captures what the agent was trying to do, not just which API it called.
Without intent, every authorized call looks the same. With intent, "user X tried to delete 5,000 records" is a different audit event from "user X read 5 records" - and your policy layer can treat them differently.
Everything above this section is classical security applied to a new context. This part is where AI genuinely breaks the auth model in a new way.
A correctly issued identity token proves who the user is. It cannot prove that the agent's next action reflects what the user actually wants. A malicious email subject line, a poisoned web page, a crafted CRM note - any untrusted text the agent reads can override the agent's instructions while it still holds the user's full permissions. The auth layer sees a perfectly authorized request. The user sees their inbox emptied.
This is where scope intent earns its keep. If every tool call must declare its intent before executing, the policy layer can check whether that intent matches what the user actually asked for - and flag the mismatch when prompt injection tries to steer the agent toward something the user never requested. Intent declaration alone won't stop PI, but it gives you a verifiable hook other defenses can build on: tool allowlists per agent, mandatory confirmation for writes, separate trust zones for tool execution, per-user rate limits. None are sufficient alone. This is the threat that justifies treating AI agent identity as a distinct discipline rather than an integration checkbox.
A short list, because every team rediscovers these the hard way:
Remember that team from the opening - the one whose demo died in the Q&A? They eventually shipped. But not before investing time in retrofitting an identity layer they should have built on day one. The agent didn't change. The auth model around it did.
Most teams building production agents are solving some version of this problem, and most are solving it from scratch. That's the same trajectory API gateways followed a decade ago.
The teams that skip identity work won't fail dramatically. They'll just never get past internal demos. The first security review will end the project.
Build the identity layer before you build the second agent. It's not the exciting part. But it's the part that separates production systems from demos.
At CloudZone, we help teams get this right from day one. Let’s talk.
When an AI agent works across multiple platforms - a CRM, a PM tool, a data warehouse - it has to act with a specific user's exact permissions on each one, and prove that identity at every hop. Service accounts can't replicate per-user permissions, and the user's IdP token only authenticates them to your system, not to the downstream platforms.
They violate least privilege, destroy audit trails, and can't replicate per-user platform permissions. The agent either sees everything (a security risk) or sees a completely different data surface than the user would in the platform directly (wrong answers).
Four components: (1) mint a signed, short-lived identity assertion at the edge when the user authenticates, (2) propagate the identity - not platform credentials - through every hop, (3) check policy and exchange the identity for a platform token via a credential broker, and (4) execute the call so the external platform enforces the permission boundary. The agent itself stays credential-blind.
OAuth scopes are too coarse - a token with crm.write can update one record or wipe out the entire opportunity table. Scope intent is a per-request declaration of the action, the target resource, and the triggering context, sent alongside the identity token at the policy check. It lets the policy layer compare what the agent intends to do against what the user actually asked for, require step-up confirmation for high-risk actions, and produce an audit log of intent, not just API calls.
A correctly issued token proves who the user is. It cannot prove that the agent's next action reflects what the user actually wants. Untrusted text the agent reads - a malicious email subject, a poisoned web page, a crafted CRM note - can override the agent's instructions while it still holds the user's full permissions. That's why intent declaration plus layered defenses (tool allowlists, mandatory confirmation for writes, separate trust zones, per-user rate limits) are needed alongside authentication.
Your datacenter contract ends in 42 days and is set for decommission. Over twenty percent of your VMs run operating systems that lost support before the COVID-19 pandemic began and haven't received security updates in nearly a decade.
As organizations increasingly adopt generative AI, Most teams discover the cost problem after they've already deployed. Here's how to get ahead of it. Teams working with Google Cloud Vertex AI often discover that without a structured approach, costs can scale quickly and unpredictably.
In the Amazon Aurora ecosystem, I/O (Input/Output) is often the silent budget killer. Every read and write operation adds up, and in the Standard configuration, those millions of requests create a bill that is as volatile as it is expensive.
