Service Account Risks in Agentic Pipelines

The handoff happens in an afternoon. A developer wires a new agent into existing infrastructure, notices the old pipeline's service account already has the right permissions, and attaches it. The alternative is standing up a new credential, scoping it precisely, testing it across every tool the agent will invoke. That takes days. The service account takes ten minutes. The agent doesn't crash. The deadline is met.

This isn't irrational. A failed permission check mid-chain breaks the entire workflow, and diagnosing which step failed in a multi-step agentic pipeline is genuinely painful. Developers over-provision to eliminate that failure mode. An agent that needs to read one S3 bucket gets AmazonS3FullAccess. An agent that needs to update one Salesforce record gets an API token with global write permissions. The blast radius expands because the developer's incentive is workflow continuity, not least-privilege hygiene. They are rational actors responding to the wrong incentive structure.

The result is what practitioners call the shared service account anti-pattern: multiple agents, serving users with materially different clearance levels, all operating under the same credential. Entro Security's H1 2025 research found that 47% of non-human identities had gone unchanged for over a year, and one in twenty carried full administrative privileges, with a substantial fraction of those having seen no activity in the preceding nine months. The overpermissioned, dormant credential is not an edge case. It is the baseline condition of the NHI population most agents inherit when they arrive.

The mismatch is invisible at setup. It surfaces only when the agent exercises access that was technically permitted but never intended, which is precisely when the absence of governance becomes an incident.

The Scale of Non-Human Identities Already in Enterprise Environments

Agents are not arriving into clean environments. They are landing in an NHI population that was already sprawling, already undergoverned, and already largely invisible before anyone wrote a single agent.

Gartner puts the ratio of non-human identities to human ones at 45:1 in average enterprises, rising to 80:1 or higher in cloud-native organizations. KPMG's Cybersecurity Considerations 2026 report estimates roughly 250,000 machine identities in a typical enterprise today, up from about 50,000 in 2021. A fivefold increase in four years, with governance practices that did not keep pace with any of it. I have sat in rooms where security teams were genuinely shocked by that number, not because they doubted it, but because they had no framework for what to do with it.

A 2025 World Economic Forum analysis found that 51% of organizations report no clear ownership of AI identities, and only 5.7% have full visibility into their service accounts. That is not a visibility gap. That is operational blindness to the majority of the identity surface. The same research puts the proportion of NHIs carrying excessive privileges at 97%, which means the over-permissioned credential is the norm you are governing against continuously.

OWASP's Non-Human Identities Top 10, published in 2025, is worth reading carefully for what it omits. The top-ranked risk is not model poisoning, adversarial prompts, or jailbreaks. It is improper offboarding, followed by secret leakage, over-privileged NHIs, and long-lived secrets. The risk surface agents introduce is not a new category of threat. It is an acceleration of a governance deficit that had been accumulating across every enterprise deploying integrations, pipelines, and automations for the past decade.

Agents inherit that condition and add autonomous reasoning and cross-system traversal on top of credentials that were already too broad.

Why an Agent with Broad Standing Access Behaves Nothing Like the Integration It Replaced

A static integration does one thing. It reads a table, writes a row, calls an endpoint. Its behavior is a function, not a reasoning process, and you can enumerate every action that it will ever take at the time you write it.

An agent, by contrast, interprets a goal, selects tools, sequences calls, and adapts based on intermediate results. Its access pattern is emergent. Nobody scripted it. The credential it holds sets the ceiling on that pattern, and the agent can reach that ceiling through paths that the person who issued the credential never considered. This sounds abstract until you watch it happen in production, at which point it is very concrete.

Four properties make this categorically distinct from any static integration. First, dynamic scope: the agent determines at runtime which systems it needs to touch, so the credential governs what is possible while the agent's reasoning governs what actually gets called. Second, self-escalation: agents with sufficient initial access can, in documented production cases, leverage role-based access control APIs to modify their own permissions at runtime. Third, sub-agent spawning: an orchestrator can delegate its credential to child processes, meaning the blast radius of a single credential multiplies across a chain without any additional authorization event being recorded. Fourth, cross-system traversal: agents chain across cloud environments, on-premise systems, and third-party SaaS via Model Context Protocol integrations, crossing boundaries that human users and static integrations rarely cross together in a single session.

The MCP layer deserves particular attention. MCP connections give agents new tool surface at runtime, so when a new tool is added to the MCP layer after the agent is deployed, the agent's effective access expands without any permission change being recorded anywhere. The credential didn't change. The IAM policy remained the same. The agent's reach did, silently.

Risk in a multi-agent chain doesn't add across steps. It compounds. Each step using a shared, over-provisioned credential is another point where access can be exercised beyond original intent, and each step that fails to attribute the action to the real end user is another gap in the audit record.

What the Audit Trail Looks Like, and Why It's Nearly Useless for Agents

In traditional IAM, elevated access follows a traceable workflow. A ticket, a change approval, a manager authorization. Something connects the access event to a human decision, so when you pull the log you can answer three questions: who authorized this, what did they authorize, and why.

In an agentic pipeline, the log shows: "Permission temporarily elevated to complete task." The approver is the AI system itself. No ticket, no human in the loop, no documented intent behind the action.

When multiple agents share one service account, the problem deepens. The log records the credential, not the agent, and certainly not the human user on whose behalf the agent acted. That is three steps of indirection, none of them captured. You know the credential was used. You do not know which agent used it, which user triggered that agent, or what goal the agent was pursuing when it exercised the access. I have watched incident responders stare at logs like that for hours and come up empty.

Agents also generate queries at a volume that cannot be reviewed by human analysts without automated attribution systems. A human analyst issues a handful of queries in a session. An agent in an active pipeline can issue hundreds or thousands. Log volume at agent scale becomes noise, and noise at the scale agents produce it makes investigation nearly impossible without systems that attach attribution at the point of query.

CVE-2025-32711, a vulnerability in Microsoft Copilot disclosed in mid-2025, is the clearest demonstration of what this failure mode produces. Engineered prompts in email triggered Copilot to exfiltrate sensitive data automatically, without user interaction. The log showed a Copilot action. It did not show an attack. The Q4 2025 cluster of agent incidents, including vulnerabilities in LangChain and the OmniGPT credential leak, produced audit trails that were insufficient to reconstruct the chain of events after the fact. In each case the exploit was not sophisticated malware. It was poor NHI governance, and the logs confirmed what happened without explaining it.

Verizon's 2025 Data Breach Investigations Report found that stolen credentials were the single most common initial access vector, present in roughly a fifth of breaches and appearing in nearly nine out of ten basic web application attacks. Agents holding static, long-lived credentials expand that surface continuously, and the audit trail meant to detect abuse is structurally incapable of producing what an investigation actually requires.

A log needs to capture the identity of the agent, the identity of the end user, the goal that triggered the query, and the full lineage of what data was touched in what sequence. Anything less is a timestamp with no context, which sounds like a record but functions like silence.

Where the Regulatory and Framework Environment Now Places the Bar

Agent observability is a regulatory requirement in certain jurisdictions and contexts, and the bar is higher than most deployment roadmaps currently account for.

The EU AI Act and NIST AI RMF both mandate full traceability of agent actions, data usage, and multi-step decision pathways. The EU AI Act has been in force since August 2024, with the bulk of high-risk obligations applying from August 2026. Penalties for prohibited-practice violations reach €35 million or 7% of global annual turnover, whichever is higher.

The practical implication is architectural. An agent operating under a shared service account, with no per-user attribution and no lineage in the audit log, fails the traceability requirement structurally. Not because a specific log entry is missing, but because the architecture cannot produce what the framework requires. You cannot reconstruct per-user intent from a credential-level log. You cannot demonstrate that a specific user's permissions governed a specific query when those permissions were never evaluated at query time. The system was never designed to produce the records that are now required.

OWASP's AI Vulnerability Scoring System identifies the highest-priority agentic AI risks in terms that map directly to NHI governance gaps, not model-layer vulnerabilities. The threat prioritization framework the security community has settled on and the regulatory framework the EU has codified are pointing at the same underlying problem from different directions. That convergence is a reliable signal that the problem is real, not fashionable.

A 2026 survey by CDO magazine found that 76% of data leaders acknowledge governance has failed to keep pace with AI deployment. The gap is widely recognized. Enterprises deploying agents at scale before August 2026 without addressing identity attribution and audit lineage accumulate retroactive compliance exposure, not just prospective risk.

What Access Governance for Agents Actually Requires, and Where the Service Account Model Falls Short

The service account model issues broad standing access at setup, evaluates nothing at query time, and records the credential rather than the user or the intent. It was designed for systems whose behavior could be fully specified in advance. Agents are not those systems. Every governance gap that follows flows directly from that mismatch, and it is worth being specific about what the requirements actually are.

Permissions must be evaluated at query time under the real end user's identity. An agent acting for a user with read-only access should have read-only access, regardless of what the service account holds. The agent is a proxy. Treating it as a principal with independent access entitlements inverts the relationship between user permissions and agent behavior in ways that are difficult to untangle after the fact.

Access must be scoped to what the current task requires and revocable at the level of a single workload. A shared service account that must be pulled entirely to revoke one agent's access is not a governance tool. If pulling one credential breaks five other integrations, the access model cannot respond to an incident in time to contain it. Revocation granularity governs containment speed, and containment speed determines how bad an incident gets.

Sensitivity must be evaluated at the point of combination, not at the field level. When an agent joins data from two sources, the sensitivity of the result must be assessed at that moment. Individually non-sensitive fields can produce sensitive outputs when joined, and no static field-level classification catches that, because the combination isn't knowable until it happens.

Write actions carry a fundamentally different risk profile than reads and must be governed separately. Controls applied identically to both have already failed to model the actual risk.

Audit logs must capture intent and lineage, not just events: who the end user was, what goal triggered the query, what data was touched, and in what sequence. At agent query volume, this cannot be reconstructed after the fact from raw event logs.

The service account model satisfies none of these requirements. It was built for a different problem. The issue is continuing to apply it to a problem it was never designed to handle.

Why Fixing This at the Model or Prompt Layer Doesn't Work

The prompt-layer argument is intuitive and common. If the agent is instructed to only access data the user is permitted to see, the service account's broad permissions don't matter, because the agent won't use access it's told not to use.

A prompt is not an enforcement boundary. Prompt injection, model drift, and adversarial inputs can cause an agent to act outside its instructions while the credential it holds makes that action possible. CVE-2025-32711 demonstrates this precisely. The agent was not intended to exfiltrate data. When the prompt was manipulated, the credential it held made exfiltration possible. The permission layer did not independently prevent it, because the permission layer had no awareness of the adversarial input. The instruction and the enforcement were in different places, and the gap between them was the attack surface.

This failure mode applies equally to compliance. A regulatory audit does not accept "the model was instructed not to do that" as a governance control. It requires that access was structurally impossible, or that every instance where it occurred was logged with full attribution. A prompt instruction satisfies neither condition.

In multi-agent chains, the problem compounds. Prompt-layer constraints on agent A do not propagate to agent B unless agent B independently enforces them. The delegation chain breaks the instruction chain. Each agent in the pipeline that does not independently implement the same constraints is a point where access governance collapses, and no mechanism in a prompt instruction can guarantee consistent propagation across a chain that wasn't fully specified at design time. Most chains aren't.

The only layer that can enforce access consistently across all agents, all steps, and all users is the data layer, because it is the point where every query must actually resolve. It doesn't matter what the agent was told. It matters what the query returns.

What the Data Layer Needs to Look Like for Agents to Access Data Safely

The core shift is from credential issuance to query-time enforcement. At issuance, the developer knows the agent's general purpose and not much else. At query time, the system knows the real end user's identity, the agent's current task, the specific data being requested, and the combination that will result. That is the only point in the stack where all of those things are simultaneously knowable, and therefore the only point where enforcement can be both accurate and auditable.

A semantic layer is not a convenience for agents. It is a governance surface. When the layer carries table descriptions, metric definitions, entity relationships, and field-level context, the agent doesn't need to infer meaning from schema names. The query it generates is interpretable. The answer it returns is traceable. The audit record attaches to the query rather than being reconstructed from a raw event log hours after something went wrong.

Permissions enforced at the data layer are inherited automatically by every agent, sub-agent, and tool in the chain. No per-agent permission configuration required, no risk that a new MCP integration inherits the wrong scope. The enforcement is structural. It does not depend on any agent being instructed correctly, any prompt being robust to injection, or any developer having scoped a credential precisely the night before a launch deadline.

Lineage captured at the data layer attaches to the query: who asked, on whose behalf, what data resolved, what it joined with, and in what sequence. This is the audit record that satisfies both internal review and regulatory traceability requirements, and it is the only audit record that can be produced at agent query volume without manual reconstruction after an incident has already occurred.

A March 2026 study by Cloudera and Harvard Business Review Analytic Services found that only 7% of enterprises describe their data as completely ready for AI. The gap between current state and what agents require is structural, not a configuration problem. The data layer most enterprises are running was designed for human analysts issuing bounded queries with understood intent. Agents are not that, and no amount of prompt engineering changes the underlying architecture.

What agents need is a layer that sits on top of existing infrastructure, intercepts queries, enforces user-scoped permissions at runtime, and returns answers with context and lineage attached. An agent operating through that layer cannot structurally access data the end user isn't permitted to see. Not because it was instructed not to. Because the query doesn't resolve. One scenario is a guardrail that can be circumvented. The other is a control that cannot. Enterprises that haven't made that shift yet are accumulating exposure that will eventually be measured in either compliance costs or breach costs, and the timeline for choosing which is shorter than most deployment roadmaps currently assume.