AI agent access handoff checklist for role changes

A role change is where an AI agent access model either proves itself or quietly falls apart. Teams often transfer repository permissions and forget the credential path that lets an agent call production APIs, open an SSH session, or trigger a deployment. The agent keeps working, but nobody can say who may approve it, who reads its record, or who can stop it at 2 a.m.

An AI agent access handoff checklist must transfer four separate duties: custody of credentials, authority to approve actions, responsibility for audit review, and authority to act during an incident. Treating those as one vague notion of “ownership” is how a departed developer remains the practical owner of a production path long after their role changed.

A role change transfers authority, not just secrets

The team must transfer the ability to authorize and account for agent actions, even when the credential itself never leaves its secure store. A secret may remain in the same vault, yet its owner, permitted use, approver, and reviewer can all change. Those are different facts, and each needs a recorded answer.

Start by separating the people who tend to get collapsed into one name:

• The credential custodian can rotate, disable, or replace the secret.
• The service owner decides whether the agent should retain access to that system.
• The approver accepts or rejects an attempted action when approval is required.
• The audit reviewer checks what the agent actually did and follows up on exceptions.
• The emergency revoker can stop access when the normal owner is unavailable.

Small teams often give all five duties to one engineer. That can be reasonable for a narrow development credential, but record it plainly and name a backup. Otherwise a holiday, an unexpected departure, or a permissions dispute turns one absent person into a hard operational dependency.

Do not confuse repository ownership with action authority. A developer might lose write access to a repository while an agent process they previously configured can still reach an issue tracker, a cloud API, or a production host. Conversely, a new team lead may own the repository but have no authority to approve the agent's use of a release credential. Review both planes separately.

I have seen handoffs fail because the incoming person received a list of API names but not the reason each credential existed. A record that says “deployment token” tells a successor almost nothing. State the target service, allowed action, environment, owner, approval mode, and rotation method. If nobody can explain a credential's purpose in one sentence, disable it until they can.

Freeze changes before you move responsibility

Pause new agent access changes while the handoff is underway. A moving target produces a handoff document that was already wrong when someone signed it.

The freeze does not mean shutting down every agent run for a week. It means that nobody adds credentials, broadens scopes, changes approval settings, or grants a new machine access without the outgoing and incoming owners recording the change. Keep the window short and explicit. For a planned role move, start when the date becomes known and finish before the person loses access. For an abrupt departure, revoke first and reconstruct the inventory from records.

Write down the boundary. Include agent processes that run on developer machines, scheduled automation, CI jobs that invoke an agent, and test environments that hold real credentials. Teams regularly forget local tools because they are not visible in the cloud console. Local access still reaches external systems.

A useful freeze notice answers four practical questions:

1. Which credentials and endpoints fall under the handoff.
2. Who may approve an exception during the freeze.
3. Where the current inventory and action records are stored.
4. When the incoming owner accepts responsibility.

Do not accept “we will clean it up later” for credentials that touch production or customer data. Later is when people discover an agent still has a token that no employee remembers creating. A short freeze costs less than an emergency rotation performed without knowing which automations will break.

One distinction matters here: revoking a person's account is not the same as revoking an agent's authority. A credential may belong to a shared service account. An approval may be attached to a local agent process. An SSH public key may authorize a host independently of the departing developer's identity provider account. The handoff has to find each route, not merely close the employee account.

Build a register that describes use, not secret values

Your handoff register should identify credentials without copying secret material into a spreadsheet or ticket. The incoming owner needs an operational map, not a second, less protected vault full of tokens.

Use an opaque identifier, fingerprint, or vault record name. For SSH material, record the public key fingerprint and its authorized hosts. A team can inspect a public fingerprint without exposing the private key:

ssh-keygen -lf ~/.ssh/agent_deploy.pub
256 SHA256:exampleFingerprint agent-deploy (ED25519)

The exact fingerprint will differ. What matters is that the register records the resulting identifier, the host account, and the reason the key exists. Never paste a private key or bearer token into the handoff artifact to make it “complete.” That creates a new leak site and makes rotation harder to verify.

Copy this record structure into the team's protected operational documentation for each credential or access path:

access_id: prod-release-api-01
channel: HTTP
service_and_environment: release API / production
allowed_action: create approved release
secret_reference: encrypted-vault record prod-release-api-01
credential_custodian: incoming platform owner
service_owner: release engineering lead
approval_mode: every use
approver_backup: operations manager
audit_reviewer: security duty engineer
emergency_revoker: platform on-call
rotation_method: replace token in service console, then test read-only endpoint
last_verified: 2025-03-08

The dates and names above are placeholders. Replace them with actual people and dates, then protect the record as operational metadata. It does not contain a secret, but it tells an attacker where authority sits.

Include scope, not just a label. “Cloud token” may mean read access to one test account or administrator access to several production accounts. Ask the service owner to confirm the scope rather than accepting the outgoing developer's memory. Vendor consoles drift, old integrations linger, and the name someone gave a credential two years ago often has little relationship to what it can do now.

The register also needs an explicit disposition: retain, rotate, reduce scope, or revoke. “Transfer” is not a disposition. If a credential has no current use, revoke it. Teams keep dormant access because rotation feels risky. Dormant access is harder to supervise and easier to forget.

Approval expectations need a named human decision

An approval setting only provides control when the team agrees what the approving person is taking responsibility for. “Someone will click allow” is not an expectation. It is a gap waiting for a rushed person.

Define whether the agent needs permission once for a run or on each credential use. A session approval says, “I recognize this agent process and allow it to make the class of actions it has been given during this run.” A per call approval says, “I have reviewed this particular attempted use now.” They answer different risks.

Use session approval for bounded work where repeated prompts would train people to approve blindly. For example, an agent repairing a test suite may need a sequence of read and write calls to a development service. The approver should still know which process requested access and when the authorization ends.

Use per call approval when an individual action can create a material consequence: deploying to production, deleting data, changing permissions, sending messages outside the organization, or using a credential with wide scope. The added pause is intentional. If the action is too routine to merit a human decision, reduce the credential scope or move the operation into a reviewed automation path. Do not solve prompt fatigue by giving every sensitive credential a broad session approval.

At handoff, record these expectations in plain language:

• The person or role that may approve each class of action.
• The situations that require per call approval.
• What evidence an approver must inspect before allowing it.
• The expiry condition for a session authorization.
• The backup approver when the normal owner is absent.

The evidence can be modest but concrete: target environment, requested operation, credential identity, originating agent process, and expected outcome. An approver cannot make a sound decision from a generic message that merely says an agent wants access.

A common bad recommendation says to turn approvals off after the team has “trusted” the agent. It is popular because prompts interrupt work. It is wrong because trust in an agent's code generation does not grant it authority to use every external credential. Reduce approvals where the action path has narrow scope and good testing. Keep them where the consequence needs a person who can explain why they allowed it.

Audit review belongs to a person and a schedule

Logs do not create accountability by existing. A handoff must name who reviews agent activity, what they look for, and what they do when an entry does not make sense.

NIST Special Publication 800-53 separates account management in control AC-2 from audit review in AU-6. That separation fits agent access well. The person who manages a credential can be the wrong person to judge whether an agent's use matched the approved work. Independent review catches both mistakes and convenient assumptions.

Set a review cadence that matches the access. A production credential used for releases may require review after every release and after any failed or denied attempt. A low impact development integration can use a scheduled review. Do not write “periodically.” That word survives every missed meeting because it promises nothing.

The reviewer should answer a small set of questions from the action record:

• Which agent process made the request, and who authorized that run?
• Which credential or access route did it use?
• What target did it reach, and what result came back?
• Did the request fit a named task or change record?
• Did any denied, repeated, or unexpected action need investigation?

Require the reviewer to record a disposition for unusual events: expected, corrected, escalated, or unresolved. A team does not need a ceremonial report for every harmless API read. It does need a visible decision when an agent hits production outside a planned window or repeatedly asks for a credential it should not need.

Preserve records before rotation or revocation if an incident is possible. Rotation fixes future exposure; it does not explain past actions. Make sure the incoming reviewer knows the retention location, who can export records, and how to verify their integrity. An audit trail that only one departing engineer can interpret is a private diary, not an operational record.

Rehearse revocation before the departure date

A revocation plan is incomplete until the team has tested it against a harmless request. The first attempt should not happen during an incident, when everyone is guessing whether a denial means the control worked or the service is broken.

Walk through a failure that occurs often. A developer changes teams and loses source control access. Their old agent setup still runs on a managed laptop with a shared deployment credential. The credential remains valid because it belongs to the release service account, not to the developer. A colleague asks the agent to “check release status,” and the agent can still call the production endpoint. The team thought offboarding had happened because the employee account was disabled. It had not closed the shared path.

Test the actual route instead. The service owner can arrange a non destructive request, such as a status read to a test target, under the outgoing authorization. Then revoke the old authorization, disable the credential, or remove the allowed route as the handoff requires. Repeat the request and confirm three facts: access fails, the failure has the expected reason, and the audit record identifies the attempt.

This test finds more than a forgotten credential. It catches stale local configuration, a second copy of an SSH authorization, automation using an unexpected service account, and a reviewer who cannot find the corresponding record.

Keep the test narrow. You do not need to run destructive operations to prove revocation. A denied status call or a rejected connection attempt provides enough evidence when the access gateway records it properly. Document the command or request used, the expected result, the actual result, and the person who witnessed it.

If the test fails, do not close the handoff with a promise to investigate. Treat that credential as active under unclear ownership. Escalate to the emergency revoker, restrict the access path, and identify every place that cached or reused the authorization. The failed test is doing its job by exposing the route while the outgoing person can still answer questions.

Emergency contacts need authority and a live path

Emergency contacts are not a directory field. They are the people who can make a time sensitive decision when an agent is attempting an unsafe action or when the normal owner cannot respond.

Name a primary contact and a backup for each sensitive access group. Include the route to reach them during an incident, the scope they may revoke, and the service owner who decides whether to restore access later. Do not list a general team mailbox as the only emergency contact. Mailboxes collect messages; they do not accept responsibility.

Define the trigger conditions in operational terms. Examples include an agent action outside an approved change, repeated failed authorizations, an unexpected new agent process requesting a production credential, or an audit record that cannot be matched to work. The contact should know whether to pause all agent actions, revoke a single credential, disable a single host account, or call the service owner.

A good handoff also handles the awkward case where the emergency revoker is the person changing roles. Transfer that ability before the role change takes effect, then test the replacement's ability to act. Avoid a shared “break glass” secret passed around in chat. It destroys attribution and usually remains in somebody's history long after the emergency ends.

Write the restoration rule too. Emergency revocation should be easy; restoration should require the service owner to confirm scope, the audit reviewer to inspect the event, and the new custodian to accept the credential. Teams that skip this rule often restore broad access just to make a blocked task disappear.

A gateway should make the handoff visible

A local action gateway can reduce the number of places where this handoff fails, but it does not replace the ownership decisions. Sallyport keeps credentials in an encrypted vault, requires its vault to be open before actions run, and records both agent runs and individual calls, which gives a handoff reviewer concrete places to inspect.

Its distinction between session authorization and per call approval is useful when writing the expectations above. The incoming owner should decide which credentials need a fresh human decision on every use rather than inheriting whatever convenience setting the outgoing developer chose.

For its encrypted hash chained audit record, an incoming reviewer can run this offline verification command:

sp audit verify

A successful result should report that verification completed successfully; a failed result should identify that verification failed rather than silently treating the record as trustworthy. Run it as part of the handoff evidence and save the result with the handoff record. The command verifies the chain over ciphertext and does not need the vault key, which is useful when the reviewer must verify records without receiving credential access.

Do not turn a gateway into a general policy project. A long rules document with exceptions for every team will age badly and make handoffs harder. Keep the decision points understandable: can the vault permit any action, does this agent run have authorization, and does this credential require a person each time? Then make sure named people own the answers.

Signoff should prove the team can operate without the departing person

Close the handoff only after the incoming team has demonstrated control of each active path. A signed document without a revocation test, named reviewer, and working escalation route is paperwork, not evidence.

Use this closing checklist for every credential group in scope:

1. The register identifies the service, scope, custodian, approver, reviewer, backup, and emergency revoker.
2. The service owner chose retain, rotate, reduce scope, or revoke, and the team recorded the result.
3. The incoming approver accepted the session and per call expectations in writing.
4. The audit reviewer located recent action records and verified the integrity check where available.
5. The team tested revocation or denial with a harmless request and recorded the outcome.

Have the outgoing developer sign only for the accuracy of what they disclosed, not for future actions after their role ends. Have the incoming custodian and service owner accept their duties separately. That division matters when a later incident exposes a stale access path: the team can see whether the failure came from an undisclosed credential, an unperformed rotation, or an owner who never accepted the work.

The final test is simple. Ask the incoming people to answer, without calling the departing developer: which agent can reach this service, who may approve it, who reads the record, and who can stop it tonight? If any answer is vague, the handoff is still open.