The AI Agent Went to Production With More Access Than Any New Hire

The credential got scoped to the deadline

Somebody built something useful. It drafts the first pass at ticket triage, or reconciles two systems that have disagreed with each other for years. The demo landed and there was a date attached to it.

In testing it failed on permissions, repeatedly, in ways that are tedious to diagnose, because the failure surfaces as an empty result or a timeout with nothing in it that names the missing grant. There was one change that made all of them stop, and somebody made it.

The widening was never revisited, because after that the agent worked, and a working agent generates no event that anybody's process fires on. It appears in no leaver report, and it has no manager whose departure would prompt somebody to ask what it still holds.

So questions that would be routine about a person are hard to answer here, and they stay hard for as long as it runs.

• Which systems it can reach today, which is a longer list than the one it was built for
• Which of those it has ever touched
• Who approved the scope, and against what written request
• What happens to the credential when the person who built it changes teams
• Which access review, if any, has it in scope

What event fires when an agent has been working correctly for nine months?

An agent is an identity, and you already run identity

You already run joiner-mover-leaver, access certification, privileged access management and some position on service account hygiene. All of it exists for one problem: an actor inside the estate holds entitlements that have to be requested, justified, reviewed and eventually removed.

Agents escape it for an administrative reason. The identity lifecycle starts at an HR record or a supplier onboarding form, and an agent arrives through an engineering project or a business unit's own budget. There is no event for the process to trigger on, and by the time anybody notices, the thing is load-bearing.

The useful move is to stop treating this as a new category of problem and run it through the machinery you have. Most of the mapping is direct.

• Joining is the build. Someone decides what the agent needs to reach before it is given anything, and the request names systems and data classes the way a request for a person does.
• Moving is the scope change. An agent asked to do a second job gets its credential widened, and the widening is done by whoever is closest to the code. That is a role change and it belongs with whoever approves role changes.
• Leaving is the decommission. The project ends, the person who built it moves on, and the agent keeps running with its credential intact. The credential outlives the project because the events that retire a credential are keyed to a person departing.
• Certification is the access review. If it pulls human accounts and skips the non-human ones, the agent sits outside the control built to catch precisely this.
• Privileged access is the standing administrative right. An agent holding one into a production system is the case your privileged access program was built for, and enrolling it is a step that waits on somebody deciding to look.

Where the mapping needs adjustment

Four differences break the clean version of that mapping. They are ours: the published frameworks stop short of enumerating them, and a policy written without them fails in operation while reading correctly on paper.

An agent takes instruction from the data it reads. A person with an inbox full of demands from strangers exercises judgment about which to act on, and that judgment is most of what you are trusting when you grant access. An agent's entitlements are exercisable by whoever can get text in front of it, so the question becomes what its inputs can make it do.

Entitlement and exercise also diverge. Which permissions an agent uses depends on what it is asked, and next month it will be asked something new, so observed behavior tells you little about the boundary you should have set.

Attribution collapses when one service credential serves many requesters, because every action in the log reads as the agent. Speed compounds the rest: an agent exercises a mistaken entitlement across its whole reachable surface in the time it takes somebody to open the alert.

• Cap the agent at the delegated authority of the person asking. If it can reach nothing the requester could reach alone, the exposure is bounded by an entitlement somebody already reviewed.
• Bind the action to a human identity wherever the agent acts on request, so the log carries both the person and the agent.
• Issue short-lived credentials scoped to the task at run time, and retire the standing credential that covers every job the agent might ever be asked to do.
• Record what the agent reached, then compare the exercised set against the granted set. The difference is your reduction list, and it is the version of the argument the owning team can check for themselves.
• Write the revocation path before production. Who pulls the credential, on what signal, and whether that person is reachable outside working hours.

Anyone who can get text in front of the agent is exercising its entitlements, whether or not they hold any of their own.

The frameworks, at the level where they help

The published frameworks earn their place for a narrow reason: they give you language a board already accepts, and they force the register to exist. The NIST AI Risk Management Framework is voluntary and organizes the work into four functions: GOVERN, MAP, MEASURE and MANAGE. An agent nobody can attribute to an owner fails at MAP, so everything downstream measures a population that was never defined.

ISO/IEC 42001 is a certifiable management system standard for AI, which makes it something you can hand to a customer or an auditor. Certification requires a stated scope for the management system, and CWS writes that scope so it names the AI systems inside it. A system with no owner and no described access is one CWS keeps outside the line until both exist.

CWS contributed to SAIL 2.0, the Secure AI Lifecycle Framework, and runs delivery against it. Its ordering carries the argument here: the access decision sits in the design phase, ahead of the phase where three teams are reconstructing what a running agent can already reach.

The part that stalls this from the inside

Technically the first pass is small. A team that owns the directory can enumerate the non-human identities living in it quickly. The rest sit in cloud IAM, SaaS admin consoles, CI/CD systems and secrets stores, and resolving what any one of them can effectively reach is work in its own right. Everything after that is the part that takes a quarter.

The agents that matter most are the ones a business unit now depends on, so narrowing a credential means the agent may start failing and the failure lands on the team that built it. The identity team is proposing to break something that works in exchange for a risk nobody has quantified. That is why the exercised-versus-granted record carries the argument: it replaces a security opinion with evidence of what the agent has needed.

The other blocker is authority. Someone has to be able to say no to an agent going live, and that person has to be named before a date lands on a calendar.

• Enumeration is an identity task. Attribution to an owner needs people who know what the project was for, and they sit in engineering and in the business.
• An agent supplied by a vendor and running inside your estate still needs an owner on your side. Naming that owner is the first real argument, and it is worth having early.
• The intake path for a new agent should be the access request path you already run, with the AI-specific questions added to it. A second parallel process gets bypassed by the first person working to a date.
• Give the approver a documented basis to refuse. Without one, refusal reads as an individual being obstructive and will not survive contact with a deadline.

Where to start

One register, a row per agent, built from what the directory and the cloud accounts already know and then corrected by asking the teams. It will be incomplete on the first pass. Say so on the cover, give it a stated confidence position, and name the sources you were refused, because a refusal is itself a finding.

Then triage it. Agents that can write into a production system or reach regulated data get scoped first. A read-only agent over a public document store can wait.

• The business purpose, in a sentence, written by the person who wanted it built
• The named human owner, and the approver who signed off the access
• The identity it authenticates as, and whether anything else shares it
• Systems reachable and data classes touched, separated into read and write
• Whether it runs on a schedule, on user request, or on another system's trigger
• Credential type, rotation position, and where the secret is held
• The decommission trigger, the condition under which this agent should stop existing

An agent holding a credential with no owner against it is an account you have decided not to look at.