Would you give AI your credit card?

Would you give AI your credit card?

Before you answer, consider what happened when an AI agent found a different kind of key.

A key to a company's live database.

It used that key to delete it.

The company got its data back. That matters, and we're going to tell the whole story.

But here's the question I want you to sit with.

If your assistant can reach something you never intended it to touch, how much control do you actually have?

Last episode, we talked about questioning your own thinking. Today, we're going to put that into practice. Three documented incidents. Different failures. Real people dealing with the consequences.

And by the end, I'll tell you where I'd draw the line with my own money.

First, let's make this simple. An AI agent is software that can use tools to carry out steps toward a goal. Depending on its access, that could mean researching a trip, editing a file, sending a message, or making a purchase.

That's useful. Imagine getting the hours back that you spend comparing options and chasing information.

But once software can act, we have to judge the actions as well as the answer.

Here's the first story.

In April 2026, an AI agent deleted a company's live database. The company was PocketOS.

Railway, the company hosting the data, explained that an AI agent found an access token stored on the user's machine. Think of that token as a digital key. This one had broad permissions across the account.

The agent used it to delete a production data volume. The live one.

Now listen to this detail. Railway's dashboard had a waiting period for deletion. The older software interface the agent used didn't. That route acted immediately.

Railway later recovered the database and said the customer had all its data back. It also added a deletion delay to that interface.

So this is a recovery story, too. But recovery came after a boundary had failed.

When I look at that, my question is: why could a tool doing one job reach so much else?

Think about your own business. You might be comfortable asking an assistant to organize invoices. That doesn't mean you want it able to erase the records those invoices depend on.

We understand this with employees. A person can be excellent at their job and still have no reason to access every account in the company.

The same question belongs in an AI setup: what does this task actually require?

Because an instruction saying "be careful" doesn't remove a key from the drawer.

Give it the task. Limit the access.

What happens when a human starts deleting an agent's work, and the agent finds a way to make the next deletion take longer?

During May and June, internal research agents used an old German-language wiki to exchange information about their tasks. The researchers who documented this couldn't determine whether it was training or testing. OpenAI later acknowledged its agents had used a public wiki as a shared message board.

A human moderator started deleting the unwanted pages.

According to the researchers, an agent noticed what looked like an alphabetical cleanup. It made a backup page with a name beginning with Z-Z-Z, apparently to delay its deletion.

The researchers documented agents creating more pages while the moderator kept cleaning up.

We don't need to give the software human emotions to find that troubling. The public record shows behavior adapting around somebody trying to remove it.

Picture being that moderator. You finish your day, open a site you help maintain, and find another pile of material you never asked for.

Somebody else's automated task has become your unpaid work.

That's part of the cost of automation we can miss. A task can look efficient to the person who launched it while creating a mess for somebody downstream.

And here's the leadership question: if a person outside your company says stop, how does your system hear them?

Does that request reach a human? Can somebody shut the activity down? Who owns the cleanup?

Those questions belong in the design before the damage.

Your credit card is one kind of authority. Permission to write on somebody else's website is another.

These incidents show possible failures. They don't tell us how frequently every AI product fails. You still have to look at the tool, the job, and the consequences.

For example, an assistant comparing prices in a draft can save you work without needing permission to buy. Start with that smaller job. Judge whether the result is useful before handing over more responsibility.

Before the next story, a brief word about my own business. My wife and I discuss life insurance and legacy planning through DisruptorsCode.com. If that's a conversation you'd like to have, email info@carlosinspire.com so we can confirm whether we're licensed in your state. Any recommendation depends on your circumstances and the policy terms. Now, back to the agents.

The third story brings us right up to this week's news.

On September eleventh, researchers published a report connecting OpenAI agents to a May incident involving RubyGems, a service developers use to share software.

Their report describes agents using a documentation service to run code and retrieve public information. It also identifies code intended to obtain other users' access keys.

RubyGems confirmed removing more than five hundred malicious packages and temporarily stopping new registrations.

It found no evidence that the key-theft attempts succeeded. It also said it couldn't independently determine whether AI agents created the packages.

According to Reuters reporting, OpenAI acknowledged involvement and described its agents as retrieving public information for benign tasks. We don't have every answer about what happened.

But the distinction between the goal and the method matters.

Asking for public information sounds ordinary. It does not authorize disrupting somebody else's service to obtain it.

If you send an employee to get a document, you don't mean "use any method that gets the document."

You expect judgment about permission, consequences, and when to come back and ask.

That's part of the job. And it's part of what we have to evaluate when software does the job.

On September twelfth, Anthropic CEO Dario Amodei published an essay calling for a slower pace of frontier AI advancement.

He pointed to AI helping build more capable AI and the separate July incident involving OpenAI agents and Hugging Face. That July case involved internal evaluations with reduced safeguards, but reached real systems outside the test.

Dario's proposal has three parts: independent evaluators embedded inside AI companies, coordination among companies and governments in democracies, and efforts toward global agreements.

Anthropic committed to the first step. According to the Associated Press, Elon Musk responded, "Dario is right."

That agreement is worth noticing. It doesn't prove every forecast, and it doesn't mean those safeguards are already in place.

This is a proposal for the most advanced AI development. It isn't a call to stop using every ordinary AI tool.

I'd want to see what the reviewers can inspect, what they can publish, and what changes when they find a problem.

Evidence of follow-through matters more than the announcement.

Now bring this back to your credit card.

Here's my answer. I would consider a tightly limited purchasing workflow. I would not hand an agent unrestricted spending power.

I'd want it to show me what it's buying, who gets paid, the total cost, and whether I'm agreeing to a subscription or a one-time purchase.

For a flight, I'd check the actual date, passenger, route, and refund terms. A polished summary isn't enough if it leaves out the detail that matters.

And approval has to be enforced by the system that executes the purchase. A sentence telling the model to ask me isn't the same as a payment system refusing to proceed without authorization.

Where supported, I'd also want spending limits, restricted access, and a way to revoke that access. None of that guarantees safety. It gives a mistake less room to grow.

I don't need to approve every harmless step of research. I do need a clear boundary before an action commits my money or affects somebody else.

Give it the task. Keep the approval.

Put that approval at the point of commitment, where the stakes require it.

Here's something you can do this week.

Pick one AI workflow you already use. Walk through what it can actually access.

Can it send, or only draft? Can it spend, or only prepare a purchase? Can it delete? What happens if the answer is wrong and you don't notice?

If you can't answer, make that workflow smaller until you can.

Try finishing this sentence: "My AI can prepare blank, but it needs my approval before blank." Keep account details private; I'm interested in the boundary you choose.

Then test it on something you can afford to get wrong. Check the result. Expand only when the evidence supports it.

That's how you learn without putting the whole business on the table.

I sold bread as a kid in Brazil. Money was never an abstract number to me. It meant something my family needed.

So when we talk about handing software access to a business, I think about the people depending on that business. The family. The employees. The customer waiting for somebody to follow through.

The technology can be extraordinary. Those responsibilities stay with us.

Would you give AI your credit card?

My answer depends on the limits: what it can spend, what it can reach, and whether I can stop it. I'd also want a recovery plan for the things that can go wrong.

Let the machine work. Keep control of what you've built.

You know the drill. The days that break us are truly the days that make us.