Access Reviews and Renewal Cycles

Imagine a team deploys an AI agent that reads incoming support tickets, looks up order records, and drafts refunds for a human to approve. Before the agent touches any system, someone has to answer a basic question: when this agent uses a system, which identity is it using, and who answers for what it does? This article follows one agent from the moment it is deployed to the moment its access is reviewed, and it introduces one requirement at each step.

Follow the support agent's access from the start. Access begins when the sponsor grants a scope. While the agent operates within that scope, its access stays active. When the access reaches a renewal point on the review cadence, the sponsor makes a deliberate choice. If the sponsor renews the access, it returns to active use and the cycle repeats. If the sponsor does not renew it, the access lapses. Notice that nothing in this path is permanent. The state of the access changes only when someone acts or the review point arrives.

The first requirement is the simplest to state and the easiest to skip: every agent a deployment introduces needs an identity. An agent running under a shared service account, or under a person's login, is not really identified at all. Its actions are attributed to whichever account it borrowed, so the agent cannot be granted, limited, or reviewed as its own thing.

This matters because the other three requirements all attach to an identity. Permissions, expiration, and audit records each hang off the identity. If the agent has no identity of its own, there is nothing for those controls to attach to. The identity is the anchor, and every control is a fact about that anchor.

Every deployed agent needs four things attached to its identity: the identity itself, a sponsor, scoped permissions, and an expiration with an audit trail. The identity is the root. The other three are facts recorded against it. Checking a proposed deployment means confirming that all four are present and that each one points back to the same agent identity.

The second requirement is a sponsor. A sponsor is a human inside the customer organization who is accountable for what the agent does. The sponsor is not necessarily the person who wrote the agent's code. What matters is that a named person with the authority and context to answer for the agent's behavior is tied to its identity.

Sponsorship matters because agents make decisions quickly and across many systems. When an agent does something unexpected, the organization needs a person to turn to. Without a sponsor, a question like who approved this agent to issue refunds has no answer in the identity record.

The third requirement is scoped permissions. Scoping means granting the agent only the access its job needs and stating that access precisely. The source frames scope as four questions the identity must answer: which data sources the agent can read, which systems it can write to, which tools it can invoke, and which humans it can escalate to. Anything not listed is outside the agent's access.

Each of these boundaries is part of the identity definition itself. They are not rules someone is expected to remember to apply later. That is why an unlisted system is simply outside the agent's reach rather than an exception someone has to catch.

The fourth requirement is expiration, and it changes how you should think about agent access. Access is not perpetual. Once granted, it does not stay valid indefinitely. The sponsor renews it on a cadence that matches the customer's standard access-review process. Renewal is a deliberate decision, repeated over time, rather than a one-time setup step.

Renewal is also the moment to check whether the scope still fits. An agent that was correctly scoped a year ago may no longer need the same tools or data. Because access is reviewed on a schedule, the same way other standing access is reviewed, that drift has a regular chance to be noticed rather than persisting silently.

The fifth requirement is an audit trail. Every action should be logged against the identity, and each log entry should capture the action, the result, and the context in which it happened. The identity is the thread that ties these records together, so all activity by one agent can be found in one place.

The log is useful only because each entry points back to an identity. A record that says a draft refund was created tells a reviewer very little. A record that says the support agent created this draft, for this ticket, and saved it to the queue lets a reviewer reconstruct what happened and why.