Bottom Line Studio
The pilot ended. The access didn’t.
An AI agent can outlive the pilot that gave it a key. Before another one gets access, give it what you’d expect for a new hire: a named owner, its own identity, and an end date.
Your next AI hire needs an offboarding plan.
Sound familiar? Someone gave an agent a service account “just for the pilot.” The pilot ended. The account didn’t, and nobody can say exactly what it can write to.
The access gap is already visible
In the 2026 CISO AI Risk Report from Cybersecurity Insiders, a survey of 235 security and IT leaders at large US and UK companies, sponsored by the identity vendor Saviynt, 71% said AI tools now have access to core systems like Salesforce and SAP. Only 16% said that access is governed effectively. Just 5% felt confident they could contain a compromised agent.
This is a vendor-sponsored survey of large enterprises, not a census of every company. It measures respondents’ assessments. The useful question for your own stack is concrete: can you identify and revoke each agent’s access?
A temporary pilot can leave permanent permissions
Nobody sits down and decides an agent should be able to write to the CRM forever. It happens in steps. A pilot needs data, so it gets a key. The key belongs to whoever set it up. The pilot works, so it keeps running. Six months later, the agent has more reach than most of the people on the team, and none of the paperwork.
I’ve written about this from the inside: an agent that changed production when it should have proposed a change, and one that walked straight around dashboard permissions by reading the warehouse underneath them. Neither was malicious. Both had access nobody had looked at since the day it was granted.
In GTM systems the stakes are specific. An agent that can write to the CRM can move a stage, change an owner or overwrite a close date. Each of those changes a forecast, a commission or a territory, and none of them looks unusual in the record afterwards. A shared key makes attribution harder: the credential alone cannot distinguish an agent’s edit from a person’s.
Treat every agent like a new hire, on purpose
You already know how to give a new person access safely. You don’t hand a new hire the admin password on day one and hope. They get a role, a manager and a login with their name on it, and HR turns it off when they leave. The same five questions work for an agent.
| A new hire | An unmanaged pilot agent | A governed AI agent | |
|---|---|---|---|
| Who approved the access | A manager signed off | Whoever ran the pilot | A named owner signed off |
| What it can touch | Starts narrow, grows with the role | Whatever the key had | Read-only by default |
| Whose name is on the activity | Their own login | A shared or personal key | Its own identity, every action logged |
| Who reviews its work | A manager, weekly | Nobody, until something breaks | The owner approves every write |
| When access ends | On the last day | It outlives the pilot | An end date, renewed on purpose |
Five checks you can run this week
- Name an owner for every agent. A person, not a team.
- Give each agent its own identity. No shared keys, no borrowed logins, so every action has a name on it.
- Make read-only the default. Writes go out as proposals a person approves.
- Put an end date on every grant. Renewing it should be a decision, not an accident.
- Keep an access ledger, the same one you’d keep when a contractor leaves: who holds what, why, and until when.
If an agent started writing the wrong data today, who could turn it off?