Voice of the DBA

Tag: AI

  • Limit the Blast Radius

    You still need DBAs (that know how to back up systems and test restores). If you think you don’t, or if you manager does, then perhaps they ought to read this piece on how an AI agent deleted a production database. This wasn’t the case of an agent just running around with sysadmin access to all resources, or a lack of tests that allowed bad code to flow through a CI/CD process.

    This was a system design that had a hole in it. An API call to change infrastructure that could change both staging and production. Not something an AI set up, but humans did. A hole from both PocketOS and the API vendor that allowed the AI agent to make the same type of mistake we’ve seen humans make. A mistake of not double checking, not verifying, not following the rules of getting a second set of eyes, even a second set of virtual eyes, on the code that could drop resources.

    Reading this, I can imagine this is how some of the AWS and Azure outages occurred over the last decade. Not the 2025/2026 AI inspired ones, but the 2010-2015 human mistakes that didn’t expect a change to have such a far reaching blast radius,

    You still need guardrails, for both humans and AIs. Don’t get slack and assume either truly knows what they are doing and deserves rights everywhere. Don’t assume that your guardrails were setup correctly. AI agents make great helpers. Use some read only ones to examine your setup and look for holes. If/When we get the next Claude Mythos model (or the equivalents from Google/OpenAI/etc.) have it look for precisely the types of holes that come from bad code that looks to reset, redeploy, or re-anything in your environment.

    We separate out roles for different people to limit the blast radius of the mistakes we inevitably make. AIs aren’t necessarily smarter or better than humans. Just faster. We need separate roles, separate rights, and governance for AI agents, precisely because they can make decisions faster than humans.

    There’s tremendous potential, but and tremendous danger in allowing anyone, or anything, too many rights in any organizations. RBAC, audits, and all the other things we implement to try and reduce the number of silly mistakes are still needed. At some point we’re going to see amazing social engineered emails, messages, XSS, and other items that are designed to fool the AIs just like humans have been fooled in the past.

    We need to ensure we set good guardrails and limits when that starts to happen. Or we’re going to lose control much quicker than expected.

    PS If you want a fun and slightly scary read on how AI could go sideways, I enjoyed The Final System recently, which made me not want to deploy any sort of AI agent beyond tightly scoped ones with very, very limited rights.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • What Can AI Really Do?

    I wonder how many of you have tried vibe coding something with an AI tool. If you haven’t, I certainly recommend it. I’ve been a bit amazed with a few of my AI Experiments, including my loading of a lot of inconsistently formatted data into a database for USD$5.

    To be clear, there’s plenty of vibe coding that might not be production-ready, but have you ever been handed code from a human developer you didn’t think was production-ready? Or deployed code like that? Certainly, AI could exacerbate the situation, but it can also spark ideas, ease (and speed) development in small ways, and tackle the backlog of things your org needs.

    Especially small tools.

    How big a concern or help will this be? I ran across an interesting article from a semi-technical person trying to build a text analysis tool. This is the type of thing we may do as database pros, but we wouldn’t have time to service every request for this assistance. There is a mixed bag of success in the piece, and a recognition that software developers have skills and knowledge that AI tools can’t necessarily duplicate in the hands of a non-pro.

    However, that’s where I think software engineers and database professionals have to learn to leverage AI tools to become more efficient, prove their worth, and, honestly, get more done without working longer hours. It’s also a place where you might guide users in producing some useful, but less mission critical software for themselves with AI. That might lower the number of requests I get.

    To me, that’s the direction I want to go with AI. More productive, less stress, and the same (or fewer) hours.

    What do you think AI can do for you? Let us know today.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • The Dangers of Dependencies

    Many of us working with databases know the problems of a single point of failure. We build HA/DR technologies into a lot of systems precisely because many of us know if the database goes down, a lot of stuff goes down. Broken software is easier to fix and rollback, but a broken database can be a much bigger problem.

    We also know an overloaded server doesn’t handle a workload well, hence our quest for well-written SQL code, but we often lose that battle with developers.

    In any case, as we move to a world where AI technology is used by many organizations, who often have a contract with a vendor to provide services, there is a potential issue. Imagine that you’ve setup workflows, maybe agentic loads and you depend on a company, say Anthropic, to provide those services. What if your organization gets banned?

    That happened to a company (reported on Reddit). A user got a note from Anthropic, but his entire organization got banned. That’s quite a dependency where a user in your company could cause an issue. In some sense, that’s like someone in your company sending an email that gets your organization’s email blacklisted or has Google/Microsoft/etc. cutting off access. Imagine the disruption there?

    Some of these companies providing AI services aren’t that large, and aren’t suited for the enterprise. Some of you are using vendors that might be contracting with these AI firms. Imagine your monitoring, DevOps, etc. service suddenly not working because they lost access to their AI services?

    I’d like to assume this doesn’t happen with the very large cloud vendors, but who knows. I’d like to think that not only enterprises, but even smaller companies don’t lose access because of the actions of one person. Or if they do, there’s any way way to get a response from customer service. However, I also know that Google, Amazon, and Microsoft have made it harder to get an answer from a real person.

    I didn’t talk about this recently when presenting on local AI models, but I think the future might be companies having more control over their AI tech, running them the same way we run servers in the cloud, in IaaS, with more effort required, but more controllable by the organization.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • A Cloud Dependency Failure from Amazon

    I went to sleep while reading a Kindle book on my phone. I know because my hand dropped and the phone knocked me in the forehead. I set it on the nightstand and went to sleep again.

    I woke up and was planning on reading for a few minutes before starting my Monday. When I opened the Kindle app, it asked me to log in. When I did, Amazon said my account was locked and I needed to check an email. I did, and found one from Amazon.co.uk questioning a purchase I made and asking for me to very an order number and the last 2 digits of a card to charge.

    I wasn’t sure what to do, but since my wife was complaining about her Audible account, I knew I needed to do something.

    I didn’t like the email for multiple security reasons, including not giving me a way to verify the email online. Checking Amazon’s help page said I should have a link in the email to a form. Even when I called the Amazon help line, they said I should have a link when I logged in to do so. I didn’t on either the .com or .co.uk sites, but Amazon Customer Service eventually unlocked my account.

    I wrote about Dependencies in today’s editorial, inspired by this story and the Reddit story linked in there about losing access to Claude. That’s scrary, especially in this new automated world where AI agents might be examining activity and undertake this type of action to prevent other issues. It’s an overreaching type of judgment that starts to expose the dangers of a highly interconnected world.

    I get Amazon might want to ensure my purchase was legitimate and perhaps prevent future orders, but also locking my content away (books, movies, audio, etc.) because of a shopping issue seems extreme.

    It’s certainly my issue, and I’m not sure how I untangle things for the future, but it does make me think about limiting dependencies a bit more in the future. Or at least understanding the dangers of too much on one service.

    Whether that’s the books I read or the services my company gets from any one vendor.