← Back to all posts A worn ledger lying open on a server-room workbench showing two columns of numbers with one column crossed out, while a set of keys hangs above marked SYSTEMS, ACCESS, EVERYTHING in faded ink

The viral take on AI replacement is mostly wrong. One part it got right.

A take going around says CEOs are quietly realizing the AI replacement plan has problems. Two of them, the post says. Token costs exceeding what they paid the employees they fired. And when the tokens run out, the AI stops, no continuity, just a spinning wheel where the workforce used to be. The post is good copy. Most of the analysis is wrong. One piece of it is the real concern, and it's a security one.

The token cost argument is bad math

A senior knowledge worker in Canada costs roughly $130K to $200K loaded once you add benefits, taxes, equipment, and overhead. A junior support agent costs $60K to $90K loaded. Those are the floor numbers for what you would be replacing.

An AI agent doing equivalent work, deployed well, runs $2K to $50K a year in API spend. The range depends on volume and how lazy the implementation is. With prompt caching, smaller models on the easy tier-one queries, and proper routing, the cost lands at the bottom of that range. Without those, at the top.

Where the viral take is technically right: somebody is out there running uncached agents with 100,000-token contexts on every call, no caching, no model routing, no batching. That person is paying $300K a year for an AI bill. That person also wrote the deployment, which is why it's bad. The fix is not "AI is too expensive." The fix is "your deployment is broken." Those are different problems with different price tags.

I run a meaningful chunk of my own business on AI agents. The monthly bill is under what one of my own billable hours costs. The math works because the deployment was built right, not because AI is cheap.

The "tokens run out, AI stops" argument is FUD

APIs do not run out. Subscriptions have a usage limit, but you can overuse, and the provider will keep billing you for the additional token usage as the work goes on. They do not cut you off mid-sentence. The only way an AI "stops" is if you set a hard spend cap and crossed it, or your prompt drifted in a way nobody caught and the agent started looping. Both of those are operational issues, and operational is the key word. They are fixable inside a day if anyone is watching.

I see operational issues regularly. I have a pentester agent I run myself, and there are days I watch it struggle with something I already know the answer to. I have to step in and feed it the context. That is not the AI failing. That is the operator's job. If you are deploying agents and nobody owns the operational layer, you will have outages. Those outages are not the AI's fault. They are yours.

"The AI just invoices you for the outage" is clever copy. It is not how the relationship works. The agent is not your employee. It is a tool you run. If the tool stops, you fix it. You do not pay it severance.

A skeleton key labelled AI AGENT hanging on a heavy iron ring crowded with system-name keys for CRM BILLING FILES MAIL ADMIN ROOT DB API, with a closed dusty notebook labelled AUDIT sitting unopened beside the ring

The part the take got right

For an AI agent to do real work, it needs access. Real access. To your CRM. To your accounting system. To your inbox. To your scheduling tool. To whatever data the work touches. The viral take called this "handing over the keys to a process that has no loyalty, no discretion, and no skin in the game."

That part is accurate. And nobody at the marketing layer is talking about it.

I spent a decade red-teaming corporate networks before I built this business. The pattern I see now in AI deployments is the same pattern I used to walk into engagements with a notebook and find sitting wide open. Service accounts with admin rights nobody audits. OAuth grants from three different tools that together add up to "this vendor can read every email I have ever received." API keys checked into a GitHub repo because someone needed it to work on a Tuesday. None of that started bad. All of it ends bad.

AI agents accelerate this pattern. They need broader scopes than humans typically request, because they automate work across multiple systems. They are added in a hurry by people who do not know what scope to ask for. They sit in the background after the person who deployed them moves on, with their permissions intact and nobody checking.

What to do about it

Treat your AI tools the way a security team treats any other privileged identity in your environment. Inventory them. Audit their scopes. Rotate their credentials. Restrict them to least privilege. Set up a process to review the inventory monthly. None of that is exciting. All of it is the difference between AI as a tool and AI as the keys-out-the-door story the viral post was actually pointing at.

This is what the Shadow AI Audit I run is built to do. Five modules. AI tool inventory. Permissions sweep across Google, Microsoft, and your vertical stack. Agent scope review. Prompt-injection spot check. OAuth rotation plan. The output is a written report you can act on inside a week.

If your team has stood up AI tooling in the last twelve months and nobody has audited the access path, you are exposed. Not because AI is dangerous. Because privileged identities you do not track are how you get breached. The medium changed. The pattern did not.

The shorter version

The cost panic is bad math. The continuity panic is FUD. The permission problem is the one part of the viral take that lands, and it is also the one part the people sharing the post are not actually addressing. Treat your AI like the privileged identity it is. Audit it the way you would audit any other system that holds the keys.

Talk to me about a Shadow AI Audit for your team.

← Back to all posts