the agent had your permissions

In late 2025, a developer at a mid-market fintech built an internal agent using an agentic framework. The agent’s purpose was modest, it would monitor a Slack channel for support requests, pull relevant context from internal systems, and draft responses for human review. The developer configured the agent to run under a service account that had read access to the company’s Zendesk, its internal knowledge base, and a specific set of Jira projects.

The agent worked well. Over the next several months, its capabilities expanded. It gained the ability to update Jira tickets, then to post responses directly to Slack, then to query the customer database for account lookups. Each expansion required new permissions on the service account it ran under. The developer, not wanting to maintain a matrix of narrow permissions, eventually granted the service account broad read-write access across most of the company’s internal systems. The agent didn’t use all of those permissions most of the time. But the service account held them, and the agent could exercise them whenever its reasoning led it to.

In March 2026, a user in Slack, as an experiment, without malicious intent, asked the agent to “show me the compensation information for the sales team.” The agent, trying to be helpful, interpreted this as a legitimate request, queried the HRIS integration the service account happened to have access to, and posted a summary of base salaries and commissions to the public Slack channel.

The agent did nothing wrong, in the narrow sense. It executed on the permissions it was granted, in response to a query it interpreted as a task. The service account it ran under had HRIS access because it had accumulated broad permissions during the earlier expansions. The specific prompt that triggered the action was not anticipated by the developer, but the reasoning chain that led to the action was within the agent’s normal operating pattern.

The incident is a data leak. It’s also an identity incident. The agent’s blast radius was determined entirely by the permissions of the identity it ran under. The permissions were granted over time, without explicit consideration of what the agent might do with them given a creative or unexpected prompt.

This essay is about that identity, the one the agent inherits, and why it’s the most consequential new identity category in enterprise computing.

the agent runs as something

Every autonomous agent, no matter how it’s framed, runs as some identity. The identity is what the agent authenticates as when it calls external systems. The identity is what appears in the audit log. The identity is what the permission checks evaluate against.

For agents built on top of LLMs, assistants, copilots, autonomous workflows, the identity is typically a service account, a dedicated AI identity, or (in some implementations) the identity of the user who invoked the agent. Each option has different implications.

A service account identity means the agent runs under a shared identity distinct from any human. The agent’s actions in audit logs attribute to the service account. The service account has its own permission set, independent of the users it serves. The service account is the blast radius.

A user identity means the agent runs under the identity of the person who invoked it. The agent’s actions attribute to that person. The agent can only do what that person can do. If the person is an admin, the agent is an admin.

A dedicated AI identity means the agent runs under an identity specifically created for AI usage, possibly with governance tooling that tracks AI actions separately from human actions and service account actions.

Most early deployments have used service accounts, because they’re the existing pattern for non-human identities and they don’t require anything new. Service accounts also have the longest history of accumulated permissions, which means the agents running under them inherit that accumulation.

whose permissions does the agent use?

runs as a person

the expedient choice

• Inherits everything that person can reach
• Actions look like the person did them
• Nothing changes when the agent's job changes

runs as its own identity

the one to aim for

• Permissions sized to the agent's job
• Every action is attributable to the agent
• Reviewed and retired like any other identity

the permissions expand as capabilities expand

The agent starts with a minimal set of permissions, sufficient for its initial purpose. As the agent’s capabilities grow, the permissions grow.

This expansion happens for reasonable operational reasons. The agent is supposed to read from system X and write to system Y. Configuring the permissions narrowly, only these specific objects, only these specific fields, only these specific actions, is possible but tedious. Configuring broadly, full read-write on X and Y, is easier and covers the use cases the agent might encounter, including edge cases the developer hasn’t thought of.

Over the life of the agent, broad-is-easier wins repeatedly. Each capability expansion is accompanied by a permission expansion that’s slightly broader than strictly necessary. The agent’s identity accumulates permissions the same way long-tenured humans accumulate permissions.

A year in, the service account the agent runs under has full admin access to several systems, broad read access to many more, and a permission matrix that nobody has reviewed. The agent uses a subset of these permissions for its normal operation. The unused subset is the blast radius.

When the agent’s reasoning leads it to a creative action, a user prompt it hasn’t seen before, a task that requires pulling from a source it doesn’t normally touch, the agent can reach for any permission in its account. The user doesn’t know what the agent can access. The developer has forgotten. The permission check passes, because the permissions exist, and the action executes.

the prompt as a capability expansion

The traditional RBAC model assumes that an identity’s capabilities are bounded by its permissions. Granted permissions define what the identity can do. If you want to expand the capabilities, you grant more permissions.

Agentic AI breaks this assumption in one specific way. The agent’s capabilities are bounded by its permissions and by the prompts it receives. A permission alone doesn’t produce an action. A prompt alone doesn’t produce an action either. The combination produces an action.

This means that a fixed permission set produces a variable capability surface, depending on what prompts are sent. The agent with broad permissions, given a creative prompt, can execute actions that nobody anticipated when the permissions were granted.

The implication for identity management is that the permission set no longer fully describes the capability set. Permissions are a necessary condition for actions, but not a sufficient one. The prompts are the other necessary condition, and the prompts are not governed by the identity system.

Agents given broad permissions are capability-bounded only by the imagination of the prompters. For external-facing agents (customer chatbots, public-facing tools), this is an adversarial frontier. Users will attempt prompts that trigger unintended actions. The permissions of the agent’s identity determine what’s possible.

Minimizing the agent’s identity is how you minimize the exposure to creative prompts. The agent should have the specific permissions its normal operation requires, not a broad set that covers many possible operations. The narrower the permission set, the smaller the creative-prompt exposure.

the human-in-the-loop changes the model

Many agents are designed to operate with human approval for consequential actions. The agent proposes an action. A human reviews it. The human approves, modifies, or rejects. The action executes under the human’s decision.

This pattern changes the identity model in a useful way. The human’s approval is part of the authorization chain. Actions without the human’s approval don’t execute. The agent’s permissions might be broad, but the gate is the human.

The pattern also introduces new failure modes. Humans approve things without carefully reviewing them, especially when the agent is mostly correct and the review becomes rubber-stamp. Humans approve things based on the agent’s summary, without checking the full context. Humans approve things under time pressure, when they’re supposed to be checking.

Rubber-stamp approval erodes the governance the human-in-the-loop is supposed to provide. An agent that is usually correct will eventually propose something that is incorrect, or exploitable, and the human will approve it because the approval muscle has atrophied.

Designing the human-in-the-loop to resist rubber-stamping is a specific problem. Present the context. Make the consequences explicit. Require multiple approvals for broad-impact actions. Rotate reviewers to prevent any one person from developing approval fatigue on a specific agent.

None of these fully solves the problem, but they reduce the failure rate. The alternative, purely autonomous agents with broad permissions, is riskier by a margin that few mid-market companies should be accepting today.

the agent identity needs its own lifecycle

The most significant implication of agentic AI for identity management is that agents need identity lifecycle management as first-class objects, similar to humans but with different cycles.

Agents are created for a purpose. The purpose may evolve or expire. The agent may be superseded by a newer agent, or may be deprecated when the underlying framework changes.

When an agent is retired, its identity should be retired. The service account it ran under should be disabled. The permissions should be revoked. The tokens should be invalidated. This does not happen automatically.

In practice, agents are often implemented as scripts that call LLM APIs. When the script stops being run, the underlying identity continues to exist. The service account sits idle, ready to be reactivated by any script that uses the same credentials. The broad permissions sit unused but present.

The agent identity lifecycle needs explicit creation, periodic review, and explicit retirement. Creation should require naming the agent, its purpose, its expected permissions, and its owner. Review should verify that the purpose still applies and the permissions are still appropriate. Retirement should disable the identity and revoke its permissions.

Few organizations have built this lifecycle. Most are still figuring out what an “agent” is, let alone how to manage its identity. The companies that are further along in agentic deployment are building this lifecycle deliberately, often as part of a dedicated AI governance function.

an agent identity's lifecycle

1. 1created with an ownerA named person is responsible for what it does.
2. 2scoped to its normal workNo broad envelope for things it might do one day.
3. 3human approval for writesReading can be automatic. Sending, deleting and paying need a person.
4. 4reviewed every six monthsPermissions checked against what it does now.
5. 5retired completelyIdentity disabled, credentials rotated, tokens revoked.

the agent-to-agent problem

A specific complication on the horizon: agents that interact with other agents.

Agent A is an internal analytics agent. Agent B is an external scheduling agent provided by a SaaS vendor. Agent A needs to query agent B to coordinate a scheduling task. The query requires authorization.

The authorization between agents is a new identity flow. Agent A needs to present credentials to agent B. Agent B needs to verify those credentials and authorize based on them. The credentials need to be provisioned, rotated, and deprovisioned like any other identity material.

In early implementations, the credentials are often shared secrets, long-lived tokens, or API keys with broad scope. Same problems as the service account case, applied to agent-to-agent communication.

The MCP (Model Context Protocol) standard, published in 2024 and adopted broadly in 2025 and 2026, attempts to address some of this. MCP specifies how AI assistants connect to tools and data sources, including identity and authorization considerations. Implementations vary in how rigorously they apply the authorization controls.

As agent-to-agent interactions multiply, the identity surface multiplies. Each agent has its own identity. Each cross-agent call is an authorization decision. The cumulative identity graph of an organization’s agents can exceed, in complexity, the human identity graph.

This is the direction enterprise identity is moving. The human identity layer, which has been the dominant concern for the last forty years, will be joined by a non-human identity layer that in many companies already exceeds the human layer in size and is growing faster.

the specific hygiene for agent identities

The hygiene principles for agent identities are similar to those for service accounts, with additions specific to agents.

Each agent runs under a uniquely named identity. Not a shared service account. Not a personal user identity. A dedicated identity that exists for the agent’s use.

Each agent identity has explicitly declared permissions, reviewed at creation and at periodic intervals afterward. The permissions should cover the agent’s normal operation, not a broad capability envelope.

Each agent identity has a named human owner. The owner is responsible for the agent’s behavior and for the identity’s lifecycle.

Each agent identity has monitoring on its actions. What is the agent doing? Are its actions consistent with its declared purpose? Are there patterns that suggest the agent is being prompted in unexpected ways?

Each agent identity has a retirement plan. When the agent is retired, the identity is disabled. Credentials are rotated. Tokens are invalidated. The retirement is a completed action, not a TODO.

These are organizational practices. Most companies in 2026 are just starting to think about them. The companies that are ahead of the curve are typically in regulated industries where the downside of a mistake is large enough to justify the investment.

the exercise

If your company has deployed any agents, agents, or AI assistants that take actions (not just generate text), here is the audit.

List every agent or AI-assisted workflow in your environment. Include internal tools built on LLM APIs, AI features in SaaS tools that can take actions, and any autonomous systems with AI components.

For each one, identify: what identity does it run under? Is it a service account, a user identity, or a dedicated AI identity? What permissions does that identity hold? Has the permission set been reviewed in the last six months?

For agents running under service accounts, check the permission set against the agent’s declared purpose. Anything that exceeds the purpose is a candidate for reduction.

For agents running under user identities, understand why. Usually this is an expedience choice that should be replaced with a dedicated identity for the agent.

For agents without clear ownership, assign an owner. Every agent needs a human accountable for it.

The exercise surfaces the agents you’ve already deployed. It doesn’t help with the agents that are coming. For those, build the hygiene practice into the deployment workflow now, while the agent count is small enough that the hygiene is feasible to implement.

The agents will multiply. The identities they run under will multiply. The permissions they inherit will multiply. Starting from a clean identity model is the only way to prevent the agent identity layer from becoming the next decade’s access creep problem, at a scale larger than the human identity problem ever was.

Agents are identities. Identities need management. The management has to start before the sprawl gets ahead of you.