What change control needs before agents touch it

Most change processes were written for two actors: a human deploying software, and an administrator editing configuration. An agent is neither, and it can do both. The process usually has nothing to say about it, which means the first agent-initiated change is governed by whatever the person who set it up assumed.

These are the eight things change control needs before an agent is allowed to touch production. None of them are exotic. Most of them are things the process should already have done for service accounts and never quite did.

1. A definition of change that includes what an agent does

If your policy defines a change as a deployment or a configuration edit, an agent transitioning an issue, editing a page, or updating a field falls outside it. That is not a loophole anyone chose. It is a definition written before the actor existed.

Widen the definition to any modification of a system of record, whoever or whatever makes it. Then decide which of those modifications are low enough risk to be pre-approved, because the alternative is a change queue that no longer functions.

The pre-approval list is the part worth spending time on. Done well it is short, specific, and phrased as a category rather than a permission: an agent may add a comment, may draft a page in a named space, may not transition an issue past a gate, may not edit a permission scheme. Done badly it is an implicit list nobody wrote down, discovered one item at a time as things go wrong.

2. An identity for the agent that is not a person

Change control depends on knowing who made a change. An agent acting under a human's credentials produces an audit trail that is accurate about the credential and wrong about the actor.

Only 23 percent of organizations report having an identity strategy that covers agents at all (Cloud Security Alliance and Strata, 2026). Until the agent has its own identity, every other control on this list is being applied to the wrong subject.

3. A named owner who is accountable for its behavior

Not the team that built it, and not the vendor. A person who answers when it does something unexpected, approves changes to its scope, and decides when it is retired.

This is the control that fails quietly. An agent without a named owner survives reorganizations, keeps its permissions, and becomes the thing nobody is willing to turn off because nobody is sure what depends on it.

Ownership also decides who carries the cost. Agent usage does not bill like seats, it moves with how much people use it, and an unowned agent has no one with a reason to care about that curve until it appears in a quarterly review.

4. A scope that was designed rather than inherited

The default is that an agent gets what its creator had. Eighty-one percent of security leaders worry about excessive access held by non-human identities (Okta Global CISO Insights, 2026), and this is the mechanism that produces it.

Change control should require the scope to be stated before the agent is enabled, in terms a reviewer can evaluate: which projects, which spaces, read or write, and what it is explicitly not permitted to reach. A scope that cannot be written down in five lines has not been designed.

5. Attribution that survives into the record

Six months after the fact, someone will ask why a field changed. The answer needs to say that an agent did it, which agent, and under whose ownership.

Test this before rollout rather than after. Have the agent perform a change, then read the history as a person would during an incident. If the record does not distinguish the agent from a human, the control does not exist, regardless of what the policy says.

6. A reversal path that does not depend on the agent

Every change process has a rollback story. For agents, the story has to work when the agent is the thing that is wrong, which means it cannot rely on the agent to undo its own work.

In practice this means two things: changes an agent makes should be individually reversible, and there should be a way to stop it acting at all that a duty manager can execute without a deployment. Revoking the identity is usually that mechanism, which is another reason item two comes first.

7. A blast radius that someone has estimated

A human making a bad change makes one bad change. An agent making a bad change can make several hundred before anyone notices, because it is fast and it does not get bored.

Change control should ask what the worst plausible run looks like. If the answer is that it could transition every issue in a project, then either the scope is too wide or there needs to be a rate limit and an alert. This is the question that most distinguishes agent change control from the human kind.

8. A review cadence that matches how fast this moves

Annual access reviews were designed for a population that changed slowly. There are now 109 machine identities per human in the enterprise, up from 45 to 1 two years earlier, and seventy-nine of the 109 are agents (Palo Alto Networks, 2026 Identity Security Landscape, 2,930 respondents).

A population growing at that rate needs a quarterly review at minimum, and the review has to cover scope and ownership rather than just existence. Ninety-two percent of security leaders say they lack full visibility into the machine identities already running in their environment (2026 CISO AI Risk Report, 235 large-enterprise leaders), which is what an annual cadence against a fast-moving population produces.

Where to put the controls

The temptation is to write all of this into policy, because policy is quick to produce and easy to circulate. Policy is also the version that depends on people remembering it under pressure.

Only 16 percent of security leaders say they govern access to their core platforms effectively, and the rest are managing by exception (2026 CISO AI Risk Report, 235 large-enterprise leaders). The difference between those two groups is usually not the quality of the policy. It is whether the control is expressed as configuration.

Most of this list can be. The identity is provisioned through the directory rather than created ad hoc. The scope is a permission scheme rather than a paragraph. The attribution is an audit setting. The reversal is a revocation. The review is a scheduled query against the directory. What remains as policy is the ownership record and the blast radius judgement, which are decisions rather than mechanisms.

The order to do it in

Identity first, because attribution, scope, and revocation all depend on it. Then scope and attribution together, because they are the pair that makes a change reviewable after the fact. Then blast radius and reversal, which are the incident controls. Then cadence, which is what keeps the other five true.

Only 18 percent of security leaders are confident their identity management can handle agent identities (Cloud Security Alliance and Strata, 2026). The gap between that number and the number of organizations already running agents is the space this list is meant to close, and it closes fastest for teams that already did the work for service accounts. If you did, this is an extension. If you did not, this is the same project, arriving with more urgency.