The AI agent handover checklist: 10 checks to run yourself

An AI agent handover is finished when you have done ten things yourself, not when the builder says it is finished. Log in with your own credentials, redeploy from a clean copy of the code, rotate a key, read a run log, change one instruction, stop the agent, and name the person who owns it. If any of those fail on handover day, you have received a demo, not a system.

Our statement of work post covers what a handover package should contain on paper. The handover test covers who owns the repositories before money moves. This post is the third piece: the day the package arrives and you check that it works.

Key Takeaways

• A list of delivered files proves nothing. Each item needs an action you perform and a result you can see
• 74% of organizations say agents routinely get more access than their task requires (Cloud Security Alliance and Aembit, January 2026)
• Model retirements arrive on a calendar, so the handover must record which model the agent runs on and when it ends
• Run the checks in one sitting, in order, with the builder available to answer written questions only

Why check instead of trust the package?

A handover package is a claim. Checking turns it into a fact, and the failures it finds are cheap on day one and expensive on day ninety.

The access problem is the clearest example. A Cloud Security Alliance and Aembit survey of 228 IT and security professionals, fielded in January 2026, found that 43% of organizations run AI agents on shared or generic service accounts, and only 36% give agents dedicated identities with their own permission sets (CSA and Aembit, 2026). The same survey found 33% of respondents unsure how often agent credentials are rotated.

A builder who ships an agent on a shared account is not necessarily careless. It is the fast way to make a demo work. The handover is where that shortcut either gets fixed or gets inherited by you.

OWASP names the underlying risk in its Top 10 for Agentic Applications for 2026: tools that carry more privilege than the task needs, and agents with no distinct identity (OWASP GenAI Security Project, 2026). It also recommends a kill switch and an audit trail as the countermeasures for an agent that misbehaves. Both appear in the list below.

What are the ten checks?

Here is the full list. Each check has one action and one pass condition.

#	Check	You do this	It passes when
1	Accounts	Log in to the code host, database, hosting and model provider with your own credentials	Every account is in your name, and the builder is a guest you can remove
2	Clean rebuild	Clone the repository to a fresh machine and deploy it	It runs without a file or secret only the builder had
3	Secrets	Rotate one API key and redeploy	The agent keeps working on the new key
4	Agent identity	Open the agent’s access list	The agent has its own credentials, scoped to its job
5	Instructions	Change one line of the agent’s written instructions	The next run reflects the change, and the change is in version history
6	Run log	Pick one run and trace it from trigger to result	You can see what it read, what it decided and what it did
7	Failure	Break an input on purpose	The agent stops, logs it and tells a named person
8	Stop	Switch the agent off, then on	It halts within one cycle and resumes cleanly
9	Model and cost	Find the model version, its retirement date and last month’s spend	All three are written down, with a spend cap in place
10	Owner	Read the runbook, then ask the named owner to confirm	One person has agreed in writing to be the owner

The sections below say what to look for in each group.

How do you check access, rebuild and secrets?

Checks 1 to 4 prove you hold the keys. They take an afternoon and they are the ones builders most often skip.

For check 1, the pass condition is stricter than “you have access.” The accounts must be created in your name from day one, so that handover means removing the builder rather than moving anything. We build on the buyer’s code host, database and hosting accounts for exactly this reason, and the AI Workforce Sprint ships that way.

Check 2 catches the hidden dependency. A clean clone on a fresh machine has no cached login, no local config file and no secret in anyone’s shell history. If the deploy fails, the error names the missing piece, and that piece belongs in the runbook. A failing clean rebuild is the single most useful finding a handover can produce.

Check 3 is a rotation drill. The same survey found 9% of organizations say agent credentials are rarely or never rotated, and that is only the ones who know. Assume yours are in that group until you have done it once. Rotate one key, redeploy, confirm the agent still works. If rotation needs the builder, you do not hold the key.

Check 4 asks whether the agent has its own identity. If it runs as the builder’s login, or as yours, every action it takes is indistinguishable from a human’s, and revoking it means revoking a person. Dedicated credentials, scoped to the one job, fix both problems.

How do you check that the agent can be changed and observed?

Checks 5 to 7 prove you can steer and watch the agent without the builder in the room.

Instructions are where an agent’s behaviour lives, so editing them is the real test of ownership. Change one line, trigger a run, and confirm the output moves. Then confirm the change shows in version history with a date and an author. If the instructions are baked into code that only the builder can safely edit, check 5 fails.

For check 6, pick a real run and follow it end to end. You should be able to answer three questions from the log alone: what did the agent read, what did it decide, and what did it do. A log that records only “success” or “failure” is a status light, not a record.

Check 7 is the one people resist, because it means breaking something on purpose. Send the agent a malformed file, or revoke one permission it needs. A good build stops, writes down why and notifies a named person. A fragile build either crashes silently or, worse, carries on with bad data. Better to learn which one you have while the builder still has context in their head.

How do you check the kill switch, the model and the owner?

Checks 8 to 10 cover the long tail: how to stop the agent, what it depends on, and who answers for it.

The stop check is simple. Switch it off, confirm nothing runs, switch it on, confirm it resumes without duplicating work. An agent you cannot stop cleanly is one you will be afraid to touch.

For check 9, write down three facts. First, the exact model version the agent calls. Second, that version’s retirement date. Anthropic’s deprecation page, checked on 6 October 2026, lists Claude Sonnet 4.5 as deprecated on 30 September with retirement on 30 November 2026, and states a minimum of 60 days’ notice before a publicly released model is retired (Anthropic model deprecations, October 2026). An agent pinned to a retiring version has a deadline nobody put in the plan. Third, last month’s spend, with a cap set at the provider so a loop cannot run up a bill overnight.

Check 10 is the human one. NIST’s AI Risk Management Framework Playbook asks organizations to identify and maintain documentation for third-party AI systems and components, and to put testing and verification processes around them (NIST AI RMF Playbook, MANAGE 3.1). A name on the runbook is that documentation in its simplest form. The owner reads the runbook, tries one thing from it, and confirms in writing. If nobody on your side will take the job, read who maintains your agents after delivery before you accept the handover, and when to retire an agent for what happens when the job ends.

What should you do when a check fails?

Write the failure down and send it to the builder as a written list, with each item numbered after the check it failed. Do not accept the handover until the list is closed.

That is the point of fixed scope and written acceptance: a failed check is a defect against the agreed scope, not a new request. Our sprint is from $9,500 for four to six weeks, with a recorded walkthrough and two weeks of written post-handover support (service page, as of October 2026), and the checks above are how we expect buyers to use that support window. Run them in the first week, while the questions are still cheap to answer.

Run the checks in order, because the early ones unblock the later ones. The whole list should fit in one working day for an agent with a single job. If it takes longer, that is information too: the system is more tangled than the walkthrough made it sound.

For scale, our own fleet had 41 registered agents, 9 live in production and 5 in beta as of 30 June 2026 (the agent fleet proof page). A fleet of that size only stays manageable because every agent passes a version of this list before it runs: its own identity, a log, a stop switch and a named owner.

Direct engagements are our core business. If you are an agency or software reseller checking a subcontracted build, the same ten checks apply, and they are what makes a handover to your client defensible.

Each agent we build is a tomte, our word for one production agent with one defined job. A tomte with a defined job is easy to check, because there is only one job to test the ten items against.

Start async

Have an agent you were handed and never verified? Send what you have at /start. You get a written reply within one business day, no meetings, naming which of the ten checks we would run first.