Disconnecting an AI agent does not necessarily revoke the credentials, payment authority or tokens granted during setup. Treat removal as a permission audit: revoke access at every underlying service, rotate exposed secrets and verify the agent can no longer complete a real action.
At 4:47 on Friday afternoon, Mensah clicked “Disconnect” in the integrations panel. He was the technical founder of a three-person AI startup in Accra, working from a borrowed meeting room while the office air conditioner rattled above him. The team had connected Agent OS that morning to test an agent that could buy small software subscriptions with the company card.
Two minutes later, Mensah refreshed the dashboard. Agent OS had disappeared. The setup looked undone.
Then his co-founder Abena asked the question that changed the afternoon: “Can it still spend?”
The card charge that should have failed
They ran a controlled test using the same instruction the agent had handled earlier. The expected result was an authorization error.
Instead, the transaction went through.
The amount was small. The implication was not. An agent the team believed they had disconnected could still reach a payment path tied to the company card. If a queued task, copied prompt or unattended process triggered another purchase, they might discover it through a bank notification rather than their own logs.
Abena opened the card controls on her phone. Mensah searched the integration settings again. Their third teammate, Jonah, checked the agent’s stored configuration from his laptop. Nobody could yet say where the surviving authority lived.
That uncertainty was the incident.
The team had treated the integration as one object because the interface presented it that way. Underneath, several separate grants could exist: an Agent OS connection, a merchant account session, an API token, stored card details and a workflow that had already received permission to act. Removing one visible connection did not prove the others had disappeared.
This is the same operational trap that appears when a failed process could repeat a payment. In Kweku’s failed payroll, the difficult question was whether another attempt would recover the process or pay people twice. Here, Mensah faced the machine version of that problem: what had already been authorized, and what could still execute?
A connection label is not a permission boundary
Most integration screens make setup feel reversible. Connect. Authorize. Disconnect. The language suggests a single door that closes when you click the final button.
The actual system may contain several doors.
An OAuth grant can survive after an app disappears from a workspace view. A card token can remain with a payment provider. An API key can sit in an environment variable. A scheduled job may already hold the information it needs. A human administrator might also have approved access in a second service without recording it.
For a three-person company, this fragmentation is easy to miss. The founder who installs the tool is often the same person shipping product, answering customers and checking the bank balance. A two-minute experiment rarely receives the access review that a permanent system would.
Yet the financial authority is permanent until something explicitly removes it.
The useful question during setup is therefore: “Where would I revoke this if the integration vanished tomorrow?” If the team cannot name the service, credential and owner, the permission is already difficult to control.
I would also separate “connected” from “able to act” in the team’s language. A dashboard reports connection state. A controlled transaction, API request or access attempt reports capability. When money, production data or customer communication is involved, capability is the fact that matters.
Revocation needs its own runbook
At 5:26, Mensah stopped trying to reason from the integration screen. The team traced the payment path from the company card backwards.
They froze the card first, accepting that a legitimate subscription might fail. Then they revoked the payment authorization at its source, removed stored credentials from the agent configuration and rotated the relevant secret. Jonah checked scheduled tasks and cancelled the test workflow. Only after those steps did they repeat the controlled purchase.
It failed.
That failure was their evidence. The earlier “Disconnected” label had only been an interface state.
A practical revocation runbook can stay short:
- Freeze or restrict the financial instrument before investigating.
- Revoke access in every underlying service, including payment, identity and API providers.
- Rotate any secret the agent could read or store.
- Cancel queued, scheduled and retrying tasks.
- Test the exact action you need to prevent.
- Record who verified the failed test and when.
The sequence matters. Investigation can take longer than expected, while a frozen card or disabled key reduces what can happen during that uncertainty.
Teams should write this runbook when they connect the tool, not during the Friday incident. Installation is the moment when every permission is visible and the person granting it still remembers why it exists.
The next integration starts with the exit
On Monday morning, Mensah added one field to the startup’s integration register: “Proof of revocation.”
A screenshot of a disconnected app would no longer qualify. For payment access, proof meant a controlled purchase failing. For an API, it meant a request returning an authorization error. For a shared workspace, it meant the former identity could no longer retrieve a protected record.
He also assigned an owner to every credential and wrote down the approved location where each secret was managed. The team could now remove an integration without reconstructing its authority from browser tabs and memory.
Before your next agent receives a card, token or production account, perform the removal drill first. Disconnect it, revoke every grant, then attempt the action once more.
The safest result is a failure you planned.
Comments
No comments yet.