Meta Description: Borrowed credentials and shared service accounts create real risk for AI agents. Here’s why agents need their own identity — and how that changes access decisions.
Most enterprises rolling out AI initiatives today don’t give their agents a distinct identity. They borrow a user’s credentials, or run everything under a single shared service account. It’s the fastest way to get moving — and, according to Claude Zwicker, Product Manager at Immuta, it’s also where the risk starts.
We sat down with Zwicker to talk about what it actually means to treat an AI agent as its own identity, how that changes the way access decisions get made, and why it’s foundational to any serious agentic deployment.
The real risk of borrowed credentials
When an enterprise stands up an AI initiative using a shared service account, two problems show up immediately. The first is a loss of context and traceability. “In your audit logs, everything will show up as just being run by that service account,” Zwicker said. “All you see is that a service account ran a SQL query in your data warehouse, but you do not know who — and that more often might be a human user — actually interacted with data via an AI interface that was the trigger for that query.” The activity is real, but the identity behind it disappears.
The second problem is permission boundaries. Zwicker used a simple example: a finance analyst has access to finance data, but the shared service account running the AI initiative is an admin account across the entire data platform. That mismatch opens the door for that analyst to start asking questions about data they’d never normally be able to reach — what Zwicker calls data leakage. “That approach is not viable,” he said. “That’s why we need better approaches than that.”
Giving agents their own identity changes the security posture
The alternative, Zwicker explained, is treating an agent as its own identity type entirely — a net-new category, distinct from a human user or a generic service account. These agent identities act on behalf of the person who tasked them, and inherit that person’s privileges for the duration of the task.
That single shift solves both problems at once. First, it restores auditability and traceability: every agent identity is tracked along with exactly who it’s acting on behalf of, which Zwicker calls critical from a risk and compliance perspective. Second, because the agent only inherits the privileges of the person who tasked it, it can’t accidentally surface data that person wouldn’t have had access to in the first place.
Zero standing privileges: access for the session, not forever
Delegated privileges are only half the model. The other half is how long an agent holds onto them. “It’s this idea that when an agent acts on behalf of a user, they inherit privileges, but they don’t inherit those privileges permanently,” Zwicker said. “They inherit them for that particular session only. And at the end of it, those privileges get removed from the agent again.”
The baseline access for agents, in other words, is zero access. An agent only holds privileges at the session level, tied to the specific person and task it’s acting on behalf of. Zwicker points to the security upside directly: if an agent is compromised, it has minimal or no standing permissions for a bad actor to exploit.
Why enforcement has to live at the data layer
A lot of teams reach for prompt-level controls or application logic first, and Zwicker doesn’t dismiss that instinct — but he’s clear about its limits. Controls built into a prompt or an application are susceptible to being reverse-engineered by anyone determined enough to find the loophole. Enforcement at the data layer doesn’t have that weakness. “It doesn’t matter how many people ask the question, and in what way,” Zwicker said, “because it respects their data access.” Controlling access at the data layer, rather than trying to intercept it upstream, is what protects an organization against both prompt engineering and bad actors trying to work around application-level rules.
Getting identity and access right from day one
For teams building an agentic deployment from scratch, Zwicker’s advice starts with a mindset shift: security and access can’t be an afterthought. “The productivity gains AI unlocks are incredibly exciting,” he said. “But you have to do it in a safe manner, so that you don’t expose yourself to risk of compliance violations.” The practical starting point is a real plan — not slides, but a working technical implementation plan for how identity and access will actually be handled. From there, his guidance is straightforward: start small, scale up, and iterate.
The takeaway
Every risk Zwicker described — the audit trail that dead-ends at a service account, the analyst whose AI initiative can suddenly reach admin-level data, the standing access that lingers after a session should have ended — traces back to the same root cause: agents that were never given an identity of their own. Delegated authorization and zero standing privileges aren’t add-ons to an agentic deployment. They’re the foundation it has to be built on from day one.
FAQ
Why is it risky to run AI agents under a shared service account?
It erases traceability and ignores permission boundaries. Every action shows up in audit logs as the service account, not the human behind it, and if that account has broad access — say, admin-level access to an entire data platform — any user working through the agent can inadvertently reach data far beyond what they’re individually permitted to see.
What does it mean for an AI agent to have its own identity?
It means treating the agent as a distinct identity type, separate from any individual human user or shared service account. The agent acts on behalf of whoever tasked it, inheriting that person’s privileges for the duration of the task rather than operating under its own broad, standing permissions.
What is delegated authorization, and why does it matter?
Delegated authorization means an agent acts on behalf of a user rather than as that user. The distinction matters because it keeps the audit trail intact — every action can be traced to both the agent that performed it and the human who authorized it — and it prevents the agent from exposing data the requesting user wouldn’t otherwise be able to access.
What does “zero standing privileges” mean for AI agents?
It means an agent’s baseline access is zero. Privileges are inherited only for the length of a specific session or task, tied to the user it’s acting on behalf of, and removed automatically once that session ends. If the agent is ever compromised, there’s little to no standing access for an attacker to exploit.
Why isn’t enforcement at the prompt or application layer enough?
Prompt-level and application-level controls can be reverse-engineered — determined users can often find a way to phrase a request that slips past the rule. Enforcing access at the data layer removes that risk entirely, since it governs what data can actually be returned regardless of how the question was asked.