A Security and AI Fail

Posted on July 15, 2026 by way0utwest

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.

Posted in Editorial | Tagged , | Leave a comment

Changing the Owner Removes Permissions: #SQLNewBlogger

Posted on July 15, 2026 by way0utwest

This is actually inspired by an article SQL Server Central, which taught me something new. I decided to verify what was in the article and do some research. The summary

tl;dr if you change the schema owner, all permissions are dropped.

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

The Scenario

We start by creating three logins and their corresponding database users. Think of them as three colleagues with different roles:

  • User1 — will own the schema
  • User2 — will be granted access to a table
  • User3 — will eventually take over schema ownership

Imagine there are a lot of User2 variants, as different logins are granted access to this table. To me, this is a problem, and I would use a role if I managed the system.

CREATE LOGIN User1 WITH PASSWORD = 'Demo12#1'
CREATE USER User1 FOR LOGIN User1
GO
CREATE LOGIN User2 WITH PASSWORD = 'Demo12#2'
CREATE USER User2 FOR LOGIN User2
GO
CREATE LOGIN User3 WITH PASSWORD = 'Demo12#3'
CREATE USER User3 FOR LOGIN User3
GO

Next, we create a schema explicitly authorised to User1, then add a table to it and populate it with some sample data.

CREATE SCHEMA MySchema AUTHORIZATION User1
GO
CREATE TABLE MySchema.MyTable (myid INT)
GO
INSERT MySchema.MyTable (myid)
VALUES (1), (2), (3)
GO
SELECT * FROM MySchema.MyTable
GO

At this point, User1 owns MySchema. Any objects inside it — like MyTable — fall under that ownership.

Now we grant User2 SELECT permission on the table. This is straightforward, explicit, and intentional. I’ll perform an explicit grant of permissions here.

GRANT SELECT ON MySchema.MyTable TO User2
GO

We can verify it works by impersonating User2 and running the query:

SETUSER 'User2'
GO
SELECT * FROM MySchema.MyTable
GO
SETUSER
GO

The query succeeds and returns all three rows. So far, everything is working as expected, as we see below..

2026-06_0119

Now, the tricky part I didn’t know.

Here’s where things get interesting. A database administrator decides to transfer ownership of MySchema from User1 to User3:

ALTER AUTHORIZATION ON SCHEMA::MySchema TO User3;
GO

This might seem like a routine administrative change — just updating who “owns” the schema. No permissions were explicitly revoked. No error is raised. But something has quietly changed.

If I now run the code above, I can’t access the table as User2.

2026-06_0120

I’ve lost access. If I check the ALTER AUTHORIZATION docs, I see this, with the last sentence being the important one. Permissions are dropped.

2026-06_0122

Something to know, and glad that Prompt AI knows this:

2026-06_0121

Summary

If you change the owner (authorization) on an object, and it’s not a database, permissions are dropped. This should be a warning at the very least, though to be fair, I’ve never changed schema ownership. It could happen, but in general, I try to keep dbo as the owner of all schemas.

In any case, something good to know.

SQL New Blogger

I took some code from an article I read (edited, really) and then used it to setup a scenario to test the concept. I likely will never forget this, and if I an AI suggests this, or can’t figure out what went wrong, I’ll have some idea myself to verify or validate a fix.

This post took about 20 minutes, including running the code a few times to test things, but it was a good exercise to show what I know, how I can use AI, and how I can spot issues.

You could use something like this as a learning exercise and to showcase your skills, even in the age of AI.

Posted in Blog | Tagged , , | Leave a comment

Forward Deployed Engineers

Posted on July 13, 2026 by way0utwest

I recently recorded a session with Ken Muse and a Redgate Flyway Solution Engineer. It was a fun session using GitHub and AI, and better managing the code in an automated fashion to bring some determinism to AI coding. I’m hoping it will be released soon, and you can see a vision of how you can better wrangle your AI agents and reduce risk and increase reliability.

When we started our discussion, Ken noted that he is an AI forward deployed engineer for GitHub. His job is to work with teams in how to use agentic coding. When we were first prepping, I had never heard the Forward Deployed Engineer title, which is apparently getting popular. It was in an issue of the Pragmatic Engineer Deep Dives last year, and I must have missed that issue. Apparently, this is a role that works part of the time with customer teams and part of the time with product or engineering teams.

In other words, a software engineer with a new title who gets paid more than a software engineer.

Titles are always a funny thing to me. I’ve seen people who write computer code go from programmers to developers to software engineers to forward deployed engineers. The job is the same. I work with a team of others who write code, or I work with a customer who wants code and might need help writing it. Or, if I’m working at a company that works with outside customers, this is really a consultant role renamed.

DBAs have had a similar change. I started as a DBA because they made a lot of money at the time. I moved from programmer to DBA, without much change in skill, but with a nice pay rise at a new company. I left that role before we got Data Engineers, Site Reliability Engineers, Database Reliability Engineers, and who knows what else. However, if I had stayed in a company, I’m sure I would have been changing my title periodically to earn more money.

Certainly, I’d still have been adding skills that give me a reason to change my title, but I’m not sure the job would have changed. Instead, I’d be trying to grow my career not only with seniority and time, but with new skills and title changes.

Maybe that’s a good reason to keep learning new skills. New skills let you claim you need a new title. Hopefully, you pick a title that HR doesn’t have any data about, so they have to set a new range for the position that’s above your current range.

Viola! Instant raise.

Not a bad career plan. Just make sure you’re adding some skills that are asked for in job descriptions, including soft skills. After all, a forward deployed engineer is going to be working with others, so communication is going to be key.

Steve Jones

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

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

Posted in Editorial | Tagged | Leave a comment

Flyway Tips: Immediate Code Review for Developers

Posted on July 13, 2026 by way0utwest

At the Redgate Summits this year, we’ve highlighted a few things in the Flyway solution that help developers improve their ability to get work done safely and quickly. While lots of developers are moving to automated systems and catching issues in pipelines, plenty of you are still working in an IDE.

This post looks at the new code analysis feature in Flyway Desktop that can help warn you of potential issues before you create that PR.

I’ve been working with Flyway and Flyway Desktop and helping customers improve their database development. This series looks at some tips I’ve gotten along the way.

Generating Good Migration Scripts

Flyway gives you determinism and consistent scripting when you generate migration scripts. Plenty of developers still do this manually, often after a lot of work and testing is done on the schema model. Once you’re sure of the changes you want to make, you can select those changes to include in a deployment.

As you can see below, I have a lot of changes, but I want to just pick one to put into a deployment.

2026-07_0253

If I click on the change, you will see that this is simply adding a new column, something developers do all the time. I’ll select that and click “Generate Migrations”2026-07_0254

When the tab changes, the default screen shows the next numbered migration script, based on my patterns and a default description of my name. Note that there is also a “Code review checks in progress” item to the left, which is running as the code is generated.

2026-07_0256

Once this completes, you can see my code rules passed, and the Flyway AI has generated a better description of the changes than I might have typed in.

2026-07_0257

There are a number of rules by default, and these are run when the migration script is generated. You can change, add, disable, customize, etc. for these rules as appropriate for your project.

Let’s go back and select a different change. In this case, I’m selecting the “Grant” table and dropping it. It’s in the current view of the db, but not the next one.

2026-07_0255

When I click Generate Migrations and go to the next tab, you can see that the code review shows me two things: a high severity error and a warning. These are summarized at the top next to the “2 issues” button (which hides or reveals the details) as dots. If I had a lot of issues, and some of you do, this gives me a quick look.

2026-07_0258

Below that I get the details. Both of these are for the same line, which is highlighted in the middle by a triangle next to that line.

If I click the High Severity item, I have the options to learn more, which links to the actual rule on the Redgate documentation site. Or I can ignore it. This allows me to comment in the code to not run this review again.

2026-07_0259

For the warning, since this wouldn’t stop a deployment anyway, I just have a Learn more link.

2026-07_0260

There are certainly times this might be the desired action, so I like the ignore button. However, much of the time developers might be making changes to objects and not thinking about potential future issues. Code review here catches things early, before others have to get involved, and helps educate developers about the styles and standards we want enforced in our projects.

If you work with Flyway, update your desktop and give it a try. We would love to hear your feedback.

Flyway is an incredible way of deploying changes from one database to another, and now includes both migration-based and state-based deployments. You get the flexibility you need to control database changes in your environment. If you’ve never used it, give it a try today. It works for SQL Server, Oracle, PostgreSQL and nearly 50 other platforms.

Video Walkthrough

Watch me do this in video:

Posted in Blog | Tagged , , , | Leave a comment