The Day-One Permissions Nobody Revoked on Day Ninety

The IAM role you cut for the agent on day one was supposed to be temporary. The pilot needed momentum, the team needed the agent productive by the demo, and somebody — probably you — added a comment in the PR that said "tighten this after we ship." Ninety days later the pilot has shipped, the agent is in production with paying customers behind it, and the role still has write:* on three buckets the agent has never touched. On-call cannot tell you which of the eighteen scopes are load-bearing and which are vestigial, because the only person who knew is on a different team now, and the runtime telemetry that would prove the difference was never wired up.

This is not a story about a careless team. It is a story about how every team building agents arrives at the same place, because the lifecycle discipline that prevents it has not been invented yet at most companies. Human identity has thirty years of accumulated machinery for this — onboarding workflows, quarterly access reviews, automatic revocation when somebody transfers teams. Agent identity has a Slack message that said "I'll clean this up later." The day-one grant becomes the day-ninety inheritance, and the blast radius scales with every model upgrade, every new tool added to the agent's belt, every customer onboarded against the same role.

Why human-lifecycle reasoning doesn't transfer

The instinct most teams have is to model agent identity on service accounts, which were themselves modeled loosely on human identity. The reasoning sounds right: an agent is a principal, it authenticates, it makes API calls under a role, the role has a policy, the policy gets reviewed when somebody remembers. The problem is that none of the lifecycle hooks that keep human identity in check actually fire for agents.

A human's permissions expire because they switch teams, change managers, leave the company, or fail a quarterly review somebody on a calendar is responsible for running. An agent does not switch teams. It does not have a manager. It is owned by whichever engineer happened to deploy it, and when that engineer rotates onto a different project the agent inherits no new owner — it just keeps running with the scopes it had on the day it was provisioned. Industry data backs this up: roughly 97% of non-human identities carry more privilege than they need, and nearly half are over a year old with no credential rotation. Eight percent have no owner at all, which is a polite way of saying the access lives on after the human who could have revoked it has stopped paying attention.

What makes this worse is the speed. Privilege drift in human identity accumulates over years as people move around and reorgs forget to clean up. Privilege drift in agentic systems accumulates per sprint, because every new tool the agent learns to call, every retry path, every "let me give it write access too so it can fix its own mistakes" expands the scope in a direction nobody is reviewing. The compounding rate is the difference between a slow leak and a burst pipe.

The three failure modes that show up in production

The first failure mode is the one everybody anticipates and still ships: the agent's role accumulates scopes the way a senior engineer's account accumulates legacy permissions. Every new feature adds an iam:PassRole here, an s3:PutObject there, a Stripe webhook handler that needs customer:write. The PRs are small and individually defensible. The aggregate is a role that can do approximately anything, which nobody notices until an auditor asks for a justification per scope and the team realizes they cannot produce one.

The second failure mode is the one teams talk themselves out of worrying about. The argument goes: "The agent only does what its prompt tells it to do, and we control the prompt." This is correct exactly until the day a prompt-injection payload arrives — embedded in a customer support ticket, a retrieved document, a tool result — and the agent obediently does what the payload tells it to, using the legitimate write access it has had for ninety days. OWASP put prompt injection at the top of the 2025 LLM risk list precisely because the attack does not bypass infrastructure controls; it steers a system that already has the access. The 2025 Microsoft 365 Copilot vulnerability cataloged as EchoLeak was the in-production proof point. The agent's permissions are the blast radius, and the prompt was never the perimeter.

The third failure mode is the quietest. The agent makes API calls that are inside its policy, inside its declared purpose, and slightly outside what the product is supposed to do — and nobody is reading the audit log because the agent is "just doing its job." Audit pipelines built for human identity assume that policy violations are the interesting signal. For agents, the interesting signal is the in-policy call whose intent has drifted: the support agent that started writing to a database it has technically always been able to write to, the coding agent that began invoking a deployment endpoint nobody told it about. ACL-based auditing does not catch this. Intent-aware auditing catches it, and almost nobody has built it.

What the discipline looks like when teams actually build it

There is a small but growing body of practice from teams that have lived through the first incident and decided not to live through the second one. The patterns rhyme across vendors and writeups, and they are different enough from human-identity practice that they have to be built rather than borrowed.

The first pattern is time-boxed grants by default. Every scope an agent is given carries an expiration — thirty days, ninety days, end-of-sprint, whatever fits the cadence — and is renewed only when somebody on-call signs off on a justification they can read. This sounds bureaucratic and is, in practice, the only mechanism that survives a team rotation. The justification is the artifact; without it, the next engineer cannot tell vestigial from load-bearing, so they renew everything, and the discipline collapses back to standing privilege wearing a clock.

The second pattern is zero standing privileges enforced through just-in-time access. The agent does not hold the credential. It requests the credential at the moment of action, scoped to the task and the tool and the authority of whichever user (or system) initiated the request, and the credential is invalidated when the task ends. Industry coverage in 2026 puts this as the baseline for agentic IAM, and the data behind it is the relevant lever: organizations granting excessive permissions to AI systems experience roughly four-and-a-half times the security incidents of those that do not. JIT collapses the exploitable window from "indefinite" to "the duration of the call," which is the right order of magnitude for the threat model.

The third pattern is a least-privilege calibration pass on a known cadence. Thirty days in, ninety days in, every quarter — the role is diff'd against runtime usage, and any scope the agent has not actually exercised in the window is removed. AWS IAM Access Analyzer, Google Cloud's IAM Recommender, and a half-dozen ISPM vendors now offer this as a primitive; the gap is organizational, not technical. The calibration only works if somebody owns running it and somebody else owns acting on the output, and most teams have neither role assigned.

The fourth pattern is an agent identity registry that is separate from the human identity registry. Agents are first-class principals, not service accounts wearing a costume, and their lifecycle hooks are designed for the events that actually happen to agents: team reorgs, product retirements, model version upgrades, capability expansions. The CoSAI Workstream 4 publication from early 2026 and NIST's AI Agent Standards Initiative are the upstream of this conversation, and Google Cloud's first-class Agent Identity primitive built on SPIFFE is the most-visible production implementation. SPIFFE itself is the right substrate because it was already designed for short-lived, automatically-rotated workload credentials — the X.509-SVIDs renew at 50% of their validity window with no human in the loop, which matches the cadence agent identity actually needs.

The fifth pattern is intent-aware auditing. The audit pipeline does not flag policy violations; it flags API calls whose pattern is outside the agent's declared purpose. This requires the agent to have a declared purpose that is structured enough to be auditable — a job description, in Trustle's framing, complete with a workplace and a contract. The discipline is closer to anomaly detection than to access review, and it is the only one of the five patterns that actually catches the third failure mode above.

The org chart is the real obstacle

The reason this is hard is not that the controls are missing. The controls exist, the vendors sell them, the standards bodies are publishing the frameworks. The reason it is hard is that no team in the typical org chart owns the agent's permissions end-to-end.

The AI team granted the scopes during the pilot and considered the work done when the demo worked. The security team owns the IAM policy abstractly but has no domain context for what the agent actually needs. The on-call team owns the runtime but inherits the role without the history. The platform team owns the identity provider but treats agents as service accounts. The agent is the only entity whose access spans all four jurisdictions, and the agent is not in any of the meetings.

The fix is not a new tool. It is an explicit owner — a single team, ideally the team running the agent in production — with the authority to deny renewal, force calibration, and sunset the agent when its product is retired. Without that owner the time-boxed grant becomes a renewal rubber-stamp, the calibration pass becomes a quarterly meeting nobody attends, and the registry becomes a CSV that nobody reads.

What to take away

An agent without a permission expiration policy is a sudo grant with a friendly name. The day-one note that said "tighten this after the pilot" is, in retrospect, a commitment to do work that no calendar in your organization is going to remind you about. The agent will not transfer teams. The role will not expire. The audit log will not raise its hand.

The teams that will look back on 2026 as the year they got this right are the ones building, today, the lifecycle machinery that human identity has had for decades — and acknowledging that the cadence and the failure modes are different enough that the machinery has to be designed for agents, not adapted from people. The teams that do not will discover, sometime around day one hundred and twenty, that the blast radius of every credential they ever issued has scaled with their agent count, and the only thing standing between a prompt-injection payload and a production write is the discipline they decided to defer.

Day one is the only day the grant is cheap to make narrow. Every day after, the grant gets harder to revoke and easier to forget. The cleanup the team promised on day one is not a backlog item; it is the permission policy itself, and writing it down on day one is the version of the discipline that actually survives.