Source: Westend61 GmbH via Alamy Stock Photo

COMMENTARY

Say you're working on an important financial report for your company, with a strict deadline. You need to share it with external financial advisers, but security restrictions are preventing you from adding them directly. You grab the report, open your personal email, upload the report — and just before you hit send, you realize this is probably not a wise decision. You delete your draft.

I'm sure you can think of many other examples where you got into a similar situation in the heat of the moment; hopefully you bumped into a security guardrail that made you think twice. Sometimes some friction is needed to slow us down and get us to rethink.

Low-Code/No-Code Makes Things Too Easy

Business units can't wait around for IT and development units to get to their items on an ever-growing backlog. Low-code/no-code platforms have really made a difference in large enterprises in the past few years, and generative artificial intelligence has turbocharged this trend. Nontechnical users are empowered to create applications by describing them to a chatbot that does everything from generate the database to the user interface. They are also creating automations to streamline business processes, either by chatting with a chatbot or using drag-and-drop. This is all happening at the heart of the enterprise and is wonderful for productivity.

Security controls provided by low-code/no-code platforms typically focus on the point that an application inherits its user's permissions. That means that, theoretically, a user could manually do everything the application or automation does on their behalf. So what's the problem?

People are not robots. We don't move the same amount of data, we are not consistent when we do something again and again, and — most importantly — we have common sense. A human can understand that sharing a financial report externally is not a good idea, while sharing nonsensitive files might be all right. But if an automation is set up to sync data between you and your external vendors, with the intent of sharing nonsensitive files, no one is going to be there to flag it or second-guess when sensitive files are also transferred unintentionally.

You could say that the person who created the automation should have thought about it, and you're right. But that requires them to stop and think. If you can create an automation by talking to a chatbot, then you quickly get into a situation where you're creating automations left and right without fully thinking through the consequences. Low-code/no-code platforms are lowering the bar to be creative within the enterprise, which is wonderful but also dangerous.

Tapping the Brakes, Not Taking the Keys

Some friction could make all the difference in the world, if carefully used. Allowing citizen developers to create automations and applications is great, but perhaps if there are external data sources or vendors, somebody needs to take a second look. Low-code/no-code doesn't really follow the software development life cycle process, but notifying the security team or center of excellence for selective reviews where it matters is feasible. We must be careful not to add too much friction, however, or we'll lose the productivity benefits that citizen development brings — or people are going to find ways around our controls.

To hit the right balance, we should let citizen developers build freely but intervene where needed. We should set up automated guardrails that catch when developers go outside of our approved risk zone and intervene — even if just by nudging them to stop and rethink.