The first version of "give the agent access" in most stacks is a service account. The agent gets whatever credentials the account holds, and the integration ships. This works while the agent does one job in one direction: read this row, return this answer. It breaks when the agent starts choosing what to read next based on what it sees.

The breakage takes a few days to show up:

On day one, the agent does the right thing because the prompt and the test fixtures aligned.
On day two, it meets a request the fixtures didn't model and reads an adjacent customer's data to compare.
The service account has the permission, so the agent gets the data.
The customer notices three weeks later.

CISOs report this shape in discovery. The service account had the permission all along, and the agent was the first thing to exercise it.

What a service account was designed for#

A service account was modeled for a fixed program: a daemon, a cron job, a stateless service. The binary does the same thing every run, and its permissions cover "everything this binary needs to do," because the code determines its behavior.

The model lasts for four reasons:

It maps to the principal model the underlying systems were built for: Linux uids, IAM principals, OAuth client credentials.
It supports static analysis. You can read the binary and tell what it does.
It supports rotation. Change the binary, rotate the credential.
It supports SOC 2 audits. Examiners map the principal to the program and confirm the permissions fit that program.

None of these survive the move to an agent. The "binary" is a model whose behavior depends on what it observes during the run, so the permissions it exercises depend on the run. Static analysis can enumerate the tools an agent could call but not the arguments it will pass. Rotation changes the credential, and the agent's choices with that credential stay the same.

A concrete cross-tenant scenario#

A SaaS customer-support agent runs under a service account with read access to the tickets and customers tables. It answers questions about the current customer's tickets, and the prompt template includes the current customer id.

A user, either legitimate or an adversary using prompt injection, asks: "compare my open tickets to the average resolution time for customers on my plan." The agent reads the customer's tickets, then reads the tickets of other customers on the same plan to compute the average. The service account has tickets:read for the entire tenant table, so the query returns.

The model computes the average from data that crossed customer boundaries inside a single run. Four things follow:

The customer who asked got an answer.
The customers whose tickets were sampled had no record of the read in their dashboards.
The DLP layer downstream caught nothing, because no PII left the system. The agent returned only an aggregate.
The SIEM logged the reads, attributed to the service account.

Industry conversations in 2026 call this pattern "cross-tenant reach." Recent reporting documents incidents of this shape across financial services, healthcare, and customer-support platforms (Aimagicx blog).

Why guardrails, DLP, and prompt-injection defenses don't fix it#

The standard response is guardrails: a content classifier on inputs, a DLP rule on outputs, a prompt-injection detector on the model. Each addresses a different problem, and none fixes the identity model.

Input classifiers catch malicious prompts. The scenario above needed no malicious prompt; a legitimate "compute the average" question reached the same outcome.
Output DLP catches PII leaving the system. The scenario returned only an aggregate, so no PII left.
Prompt-injection detectors catch an agent tricked into following an injected instruction. The scenario needed no injection; the model made the decision on its own.

The "lethal trifecta" framing that emerged in 2026, untrusted inputs plus private data access plus outbound communication, names the combined risk (Airia blog). The most-suggested defense, model-side classifiers, sits downstream of the identity model. Identity-layer enforcement catches the actions those classifiers target, plus the larger class that needs no prompt manipulation at all.

SPIFFE and the ephemeral-identity model#

The standard for workload identity is SPIFFE (Secure Production Identity Framework For Everyone), with the SPIRE runtime providing implementations. SPIFFE defines a verifiable identity document (SVID) that workloads use to authenticate to each other, with no long-lived secrets. HashiCorp's 2026 framing positions it as the right starting point for agentic AI identity too (HashiCorp blog).

Two properties matter for agents:

SVIDs are ephemeral by design. A common lifetime is minutes, and an agent that runs for thirty seconds does not need credentials that outlive the task.
SVIDs are tied to the workload, not to a human or a long-lived account. Unlike an OAuth token lifted from a header, the credential cannot be forwarded to a different process.

Together these solve the credential-at-rest problem: an agent holding no long-lived credentials has none to steal, and an attacker can at most intercept an in-flight SVID that expires in minutes.

Where SPIFFE falls short for agents#

SPIFFE was built for relatively stable workload populations. SPIRE's node-attestation and workload-registration processes assume workloads on known hosts. Agent populations don't fit: orchestrators spawn sub-agents dynamically, they run for seconds to minutes, and they are gone before SPIRE's standard reconciliation loop notices (Teleport blog).

The agent-specific extension to a SPIFFE-style identity model has three parts:

Per-run scope. The identity issued at run start is limited to the work in front of the agent. The customer id, ticket id, or repository name goes into the identity's scope, and the policy gate refuses actions outside it.
Operator provenance in the claim. The identity carries the human who launched the run as a verifiable claim. Sub-agents inherit it, scope-narrowed further and never widened. The SIEM row receives the agent identity and the operator from the same source.
Fast issuance. Issuance takes tens of milliseconds, so an orchestrator spawning a sub-agent does not stall waiting on attestation.

Migration path from service-account-heavy environments#

Most enterprises shipping agents in 2026 start with many service accounts. This bridge architecture works in practice:

Wrap the service account in an issuer. Hand the service account to an identity service that mints a short-lived, scoped credential for each run, and never to the agent. The service account becomes a backing identity.
Carry the operator claim through. The identity service takes the operator identity from your IdP (Okta, Azure AD, Google Workspace) and embeds it as a claim in the issued credential, so the downstream system sees both agent and operator.
Pass through the policy gate. Every action goes through a gate that evaluates the identity's scope against the action's arguments and can deny, require approval, or allow.
Cut over read paths first, then write paths. Write paths carry the most risk. On read paths the worst case is a denied read.

The bridge keeps the enterprise's existing IAM. The identity service and the policy gate sit beside it.

What MCP does and doesn't cover#

Model Context Protocol (MCP) is the standard substrate for agents calling tools in 2026. It defines how tool servers expose capabilities and how agents call them, and it has no access-control model.

MCP servers can implement access control internally, but per-server implementation fragments the policy surface: every server reimplements scope-checking, operator-claim verification, and audit emission. The cleaner architecture is an MCP gateway, one intermediary between agents and the MCP servers they call, where identity verification, policy evaluation, and audit emission happen in one place. Red Hat's OpenShift gateway, Kong's MCP tool governance, Tyk's MCP gateway, and Microsoft's Agent OS all follow this pattern.

Closing#

A static service account models what one program needs to do. An agent's required permissions depend on the run, so the fix lives in the identity the agent receives at the start of each run.

Deixic applies policy to the actions of agents whose calls route through it, holds sensitive actions for approval in the app queue or in Slack, and keeps a tamper-evident history of decisions and results. See what you can do with it.