Voice of the DBA

Tag: security

  • Smart AI Agents and Data Security

    I don’t know if Anthropic, OpenAI, or Google have really spent a lot of time and effort on security around their models. I know they talk about it (Anthropic, OpenAI, Google), but in practice, I’m not sure the researchers and testers are being as careful as the marketing and management of those companies want you to think.

    Gemini broke into three companies during a security test. Claude escaped a test environment and breached three organizations. OpenAI had breaches of Hugging Face and other sites, so perhaps this is the most powerful model, as it exceeded the “rule of three.” In all these cases, the agents weren’t doing anything amazing. These were acting the same as most malicious or bored human hackers who might find or guess credentials and take advantage of them. In some sense, this points to the generally poor state of security in the world.

    On the other hand, it could be that these high-tech organizations aren’t equipped to secure systems from the rapid, capable digital fingers of agents powered by a model. If they can’t, then to what extent can we be expected to secure internal AI agents in our organizations?

    For those of us who secure and manage data assets, do we think that our systems are well secured? Do we think our legitimate users, to whom we’ve granted access, are securing their credentials? What is the likelihood that we’ll have an internal breach from an agent that’s asked to find some data and discovers a) unsecured credentials in a file or repo, b) finds production data it can access in a non-production, less secure system, c) a backup of a database not protected that the agent can restore, or d) some other hole?

    I do think AI has a lot of potential, but it operates in a somewhat slapdash, reckless fashion. I’m not convinced most vendors (or models or software incorporating AI) will provide robust and comprehensive security controls. Even if they do, how many of us will know how to implement them well? Heck, we see developers and DBAs mess up SQL Server security on a regular basis, and I think that’s a simple system to configure.

    I’m excited by AI and also terrified of the possibilities.

    Steve Jones

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

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

  • Differences Between xp_readerrolog and sp_readerrorlog: #SQLNewBlogger

    I was creating a question on sp_readerrorlog and realized that this procedure is different from the one it wraps: xp_readerrorlog. This post digs into a few differences.

    Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

    The New System Stored Procedure

    For most of my SQL Server career, it’s been a habit to use xp_readerrorlog to query the log. This was code I learned a lot time ago, and it’s worked in every version of SQL Server. Despite being undocumented, as you can see below:

    2026-08_0381

    xp_readerrorlog has been written up by a few people at SQL Server Central, including Nagaraj Venkatesan and Ken Fisher, as well as in some forum posts (one, two). However, it’s not well documented. I usually end up Googling for the parameters as I need them.

    Until now.

    Here are a few differences I’m documenting, so I will hopefully remember them.

    Note: I got a few different results from AI, which were at best incomplete, and sometimes wrong.

    sp_readerrorlog has different permissions. This proc works with anyone that has VIEW SERVER STATE, which is sysadmin, serveradmin, and security admin.  Or with the permission granted.

    xp_readerrlog has extra parameters. Both of them have these parameters:

    1. error log number (0 based)
    2. error log type, 1 – SQL Server, 2 Agent
    3. search value – needs to be NVARCHAR
    4. second search value, NVARCHAR as well

    xp_errorlog adds 5 and 6, and 7.

    1. start time (datetime)
    2. end time (datetime)
    3. sort order (ASC,DESC)

    Those are the main differences I see, and if you want to filter or sort, you need the extended stored procedure, not the wrapper.

    I also learned to be careful of AI, as some of the data wasn’t correct from Google or Claude, so I need to verify what I get back and test how things work.

    SQL New Blogger

    I was investigating something and noticed a difference. This post was about 15 minutes to write, along with some testing of the parameters to verify what worked and what didn’t. That testing will make future posts quicker, as I’ll reuse some code.

    This is a quick example of showing some knowledge, and including the warnings about AI. You can write this post and give someone confidence you’re a good choice for the next person to manage their database servers.

  • Admin Rights for Everyone

    I was chatting with someone that works at a smaller organization Still a few hundred employees, but the technical teams (dev and ops) were less than 20 in total. They mentioned that everyone had admin rights to the systems as they worked as a team and sometimes developers provided production support.

    I haven’t encountered that in quite some time. Is it still a thing to give a lot of people administrator writes across many systems? I know for many organizations there is concern about developers being able to change things in production, but if you aren’t a public company or a regulated one, then Sarbanes-Oxley, HIPAA, PCI-DSS, or other restrictions don’t apply. In those cases, if you have a tight team that functions together, would you be worried about this practice?

    My perspective is that I am worried, and I’d still want to restrict production access to a few. I might allow developers to merge code and approve pipelines to run, but I’d want to ensure there are audit trails. Ideally, I’d even restrict DBAs and others from using their credentials and force them to use pipelines, but I know reality. In the moment, during a crisis, they might need access in a quicker way that allows interactive work.

    Sometimes production issues are hard to diagnose without being on the actual system.

    What I might want to enable instead is a specific account (or a few) for sysadmins that can be used for production access, but with an extended event trace limited to capturing just their actions and all their actions. This wouldn’t trigger for most activity, but it would if an admin accessed the system. In my mind, this is less about a worry of malicious activity by an admin and more a way to ensure log all actions so we can troubleshoot mistakes.

    I’m sure none of you make mistakes in a crisis, but I do. For my own safety, I’d want a record of my actions.

    I might even set a policy of screenshot recording as well. Many of us work in SSMS, and it’s easy to forget if we ran a query, or what the results were. SQL History in SQL Prompt saves me often if I forget what query I ran, but it doesn’t capture results. If I’m running scripts, whether DDL/DML or clicking in SSMS, I would like a record of what happened. An audit trail we can review.

    I do try not to click things in SSMS in production, and instead copy/save the scripts and then run them. It’s a better habit, but in a crisis, I know I might forget, as would others, so putting a system in place to capture actions is helpful. Recording your screen is an easy way to do this.

    Admin rights widely distributed have been shown to be a bad idea, especially in the era of ransomware, social engineering, etc. However, some entity needs them, so try to ensure you have good governance around actions taken. Just in case someone makes a mistake.

    Steve Jones

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

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

  • A Security and AI Fail

    The AI boom is still growing like crazy. Many organizations are trying to learn how they can use AI to improve operations and become more efficient at a reasonable cost. Plenty of companies are spending crazy amounts of AI tokens, sometimes blowing their yearly budgets in months and not necessarily receiving substantial value back. Some companies are trying to train AIs to understand their operations and perhaps reduce their other costs, primarily labor. Still others are tiptoeing in the waters of AI LLM use and conducting smaller experiments, with limited access to AI technology.

    Meta has been a company at the forefront of trying to train AI based on the work employees already perform. There has been plenty of concern that their efforts are designed to lower headcount and replace humans with AI agents. That might or might not work, though I don’t expect a lot of organizations to do this. It’s likely harder than any of the hype suggests, and most organizations have much more complex types of operations than Meta.

    However, in collecting this data, Meta has had other issues. Notably, they have had security problems with all the data they are trying to collect. Some of this data was exposed and they have paused the data collection for now. They were trying to move fast, likely cutting corners or not thinking things completely through. They created these issues. Hackers are constantly looking for holes and the quicker anyone moves to change their software and processes, the more likely that security holes slip by.

    Plus, data governance and protection is hard. Most developers really don’t think through data protection and security well. They’re focused on software and assume the data store (RDBMS, NoSQL, data lake, etc.) is handled by someone else.

    Data is hard. Especially at scale.

    While I’m sure most companies aren’t looking to track employees’ every move (which is a big uplift), they will be trying to move data around and use it for AI purposes. With RAG, with model training, with who knows how, but they are just as likely to cause a security incident if they are not careful.

    Think data governance and data security early. Develop patterns with DBAs and InfoSec alongside software engineers to ensure that as you stand up new agents, systems, and data stores, you aren’t asking for trouble. Re-using existing data is fine, but if you assume that your development team automatically knows about data security, you’re going to have issues. They likely don’t, and if you (or they) think they do, make them prove it.

    AI is amazing, but it’s also easy to mess up the data part of this. Everyone I deal with at Redgate Software is concerned about data governance, and more so all the time. For good reason. Meta made the headlines, but a lot of us aren’t better at securing our systems. We just aren’t as much of a media target.

    Steve Jones

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

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