In a previous post, we talked about agent access. Specifically, why most AI agents have too much of it, and how policy-enforced tool calling changes that equation.
Today we’re going one layer deeper: agent identity.
When an AI agent takes an action inside your enterprise systems, whose identity does it use? It seems like a simple question. For most enterprise AI deployments, the answer is surprisingly murky.
The service account trap
Here’s how it usually works. A developer sets up an AI agent and needs it to connect to a backend system, a CRM, an ERP, and a data warehouse. They create a service account with the necessary permissions. They give that credential to the agent. Done.
This is pragmatic, fast, and nearly universal. Unfortunately, this shortcut also introduces a fundamental identity problem. Worse, this is exactly the sort of problem that prevents functionally operational AI systems from getting the sign-off to be deployed in production. Let’s explore why that happens.
Service accounts aren’t people. They don’t have job roles, reporting lines, or data access policies tied to a specific human’s employment status. They don’t get deprovisioned when someone leaves the company. And when something goes wrong, when an agent accesses data it shouldn’t, or performs an action no one authorized, the audit trail leads to a service account, not the person who instigated that action.
“Agent accessed record X” is not useful forensic information. “Agent acted on behalf of Alice, who had read-only access to that record and did not authorize this action” is useful information. The difference matters enormously when you’re trying to explain an incident to a compliance team.
Impersonation vs. delegation
There are two models for how an AI agent can act on a user’s behalf.
1. Impersonation
Impersonation means the agent literally assumes the user’s identity. Credentials are shared or delegated in a way that the backend system sees the action as coming directly from the user. This is simple to implement. It also blurs the line between human actions and agent actions in ways that are hard to unravel after the fact.
2. Delegation
Delegation means the agent acts with a scoped, time-limited grant of the user’s authority. The backend system knows an agent is acting, knows which user authorized it, and knows exactly what the agent was permitted to do. This is harder to implement, but it’s the only model that gives you real accountability.
SnapLogic supports delegation through OAuth2 token exchange and token propagation. When a user triggers an AI agent through the MCP Server, their identity and their OAuth2 token flow through the entire execution chain.
By the time the SnapLogic pipeline reaches the backend system, it carries the original user’s identity, not an anonymous service account.
Why this matters for compliance
Identity propagation isn’t just a technical detail. For regulated industries, financial services, healthcare, and government, it’s an absolute compliance requirement when it comes to access to real-world data. And without that access, an AI agent is not useful.
Most enterprise systems already enforce access controls based on user identity. For example, your:
- CRM doesn’t let every employee see every customer record
- ERP has role-based permissions that have been carefully maintained for years
- Data warehouse has column-level security tied to specific user roles
When you send a generic service account through these systems, those controls don’t apply. The policies exist, but they’re being bypassed. The agent gets the service account’s access, which is often much broader than any individual user would have.
And no, the solution is not to use some narrowly-scoped account, because without access to specific data, the agent will be much less useful, restricting it to generic and low-impact use cases.
When you propagate the user’s identity, all of those existing controls apply automatically. The agent can do exactly what the user can do. You didn’t have to rebuild your security model for AI. You just have to thread the right identity through.
The standard SnapLogic implements: RFC 9728
SnapLogic’s MCP Server implements RFC 9728, the OAuth 2.0 Protected Resource Metadata specification. This is a standards-based approach to identity, not a proprietary mechanism that creates new security assumptions or locks you in.
When an AI agent connects to a SnapLogic MCP Server, it discovers the OAuth2 configuration automatically. The authentication handshake is standards-compliant. The identity token is propagated through SnapLogic’s data plane using SecurityContext propagation, all the way from the AI client to the pipeline to the backend.
The question to ask about your current AI agents
If you have AI agents running in your enterprise today, ask yourself: what identity are they using when they call backend systems?
If the answer is “a service account,” you have an identity problem. Your agents are operating outside the identity and access model you’ve spent years building.
In Part 3, we’ll talk about what happens after access and identity are handled correctly: control. Specifically, how do you prove to your security team, your compliance team, and your auditors that your AI agents are doing exactly what they’re supposed to be doing, and nothing more?
This is a 3-part series to explore our upcoming virtual discussion, “Governing AI Agents: Secure Access, Identity, and Control at Enterprise Scale.”Join us on June 10 in your region: register for the EMEA broadcast or the North America broadcast. See you there!
