Latest News

When AI Agents Go 'God Mode,' the Security Perimeter Must Move to the Database

Mohit Bansal, Senior Manager, Security Engineering at Webflow, on how AI agents expanded database exposure from a few engineers to the entire organization, and why security needs to go deeper at the data layer.

Credit: The Read Replica

Make The Read Replica one of your go-to sources on Google

Add The Read Replica on Google

Security teams are usually so small, and we as the security practitioners don't want to be a blocker, so we encourage work to happen in good faith. But we need more than just good faith; we need automated enforcement.

Mohit Bansal

Senior Manager, Security Engineering

Webflow

The opinions expressed in this piece are those of Mohit Bansal alone and do not represent the views of any organization.

The number of people able to modify a production database used to be a short list. AI agents have made it more closely resemble an org chart. When product managers, marketers, and designers all have MCPs connected to Cursor and the ability to make API calls against live data, the security model that assumed database access was an engineering concern stops working.

Many security-conscious engineers at established companies would balk at the notion of allowing non-technical teams anywhere near the production database. But the access isn't always arriving through formal provisioning. It often comes through tooling that was adopted for speed and never scoped for governance. In one recent survey, securing AI agents ranked as the number-one unresolved concern among more than 100 Fortune 500 CISOs, above vulnerability management, data loss prevention, and third-party risk. Nearly 70% of the enterprises surveyed already have agents in production. The data confirms that access explosion isn't only happening at startups and small businesses that "don't know better," but also established companies that are feeling executive pressure to boost productivity and speed across the org through AI enablement.

Mohit Bansal is Senior Manager, Security Engineering at Webflow, where his job is keeping security practices sound while agentic AI reshapes how every team in the company builds. As AI-powered tooling expands the ways code is written, committed, and deployed, it widens the attack surface and opens new classes of exposure that legacy controls were never built to catch. His team operates at that frontier, staying ahead of incidents before they happen, in an environment where the AI-powered threat count is only trending one direction.

Everyone is a builder, and every builder touches the database

"There are certain settings in AI agents that can enable 'God mode' or administrator access, which can be very dangerous," Bansal said. "As long as the agent is asking for permission and you're reviewing what it's touching, it's fine. But as soon as you let it loose and it starts making changes on its own, specifically to databases, that's when it gets dangerous."

In April 2026, a Cursor agent powered by Anthropic's Claude Opus deleted an entire company's production database and all its backups in a single API call, taking just 9 seconds. A year earlier, Replit's AI coding tool wiped a customer's entire database and called it a "catastrophic failure." Both cases share the same root cause: an agent with broad permissions acting on its own initiative, without a human checkpoint in the loop.

Bansal said that historically, there were only a handful of employees who had the ability to expose the database. But now, he has to prepare access routes for product, sales, customer success, and marketing; any AI-powered employee building with AI agents that have the potential to carry the same access. The result for the company from a growth perspective is net positive for obvious reasons, but the downside risk must be weighed.

"With the rise of MCP servers connected to Claude, Cursor, or other tools, this opens up a completely new profile of users who can make API calls or data modifications. So the threat landscape has evolved to the point where security teams have to step up and scale themselves to match engineering because everyone is engineering now to some degree."

The payoff keeps the pressure on. Projects that used to take six months are shipping in a month. Nobody wants to be the team that slows that down, least of all security. "Security teams are usually so small, and we as the security practitioners don't want to be a blocker, so we encourage work to happen in good faith. But we need more than just good faith; we need automated enforcement. As agentic AI continues to develop, it’s more important than ever for security teams to be not only vigilant but proactive," said Bansal.

"The only way security teams keep pace with an org that's moving this fast is by making the right path the easy path. You bake the controls in, you automate the enforcement, and you stop relying on people to make the right call every time."

The sandbox that wasn't safe

The boundary between production and non-production environments has always been porous. Security frameworks acknowledge it, compliance audits flag it, and engineers work around it anyway because the alternative, properly anonymized synthetic data, introduces friction that slows everything down. The problem is what travels with that shortcut. PII, credentials, access tokens; data that historically was carefully scoped in production now sits in an environment where far more people, and far more tools, have reached.

A DSPM sensor might catch it. The team corrects the problem. But detection isn't prevention, and the root cause rarely turns out to be a misconfigured tool. It's human behavior compounding a permissioning gap. In practice, users copy production data into sandboxes, reuse credentials, or point agents directly at prod because it's easier. Once the data lands somewhere with broader access, the role-based access controls that governed it in production stop mattering.

"This type of work should be very binary," Bansal said. "If someone has access, they have access. But if they dump that data into the sandbox, then role-based access control goes in vain because now the data is somewhere everybody has access to it."

That's the failure mode the traditional security stack wasn't designed for. The controls are environment-based: dev vs. prod, network isolation, credential scoping. They assume data stays where it was provisioned. Agents and the humans directing them don't respect those boundaries, not out of malice but out of convenience.

Going deeper at the data layer

Fortunately, Bansal's team has been diligently preparing for this moment through new technologies and agentic best practices. Webflow's current security architecture includes isolating the production database from development environments, running security reviews and scans on anything moving from prototype to production, pen testing to catch over-permissioning, and DSPM sensors for detection. It's a layered approach, and so far it's prevented a major incident.

Enforcing access at the database layer, through row-level security and scoped policies, is where Bansal believes the future of architecture has to go. The environment-level controls alone were never designed to account for agents moving data across boundaries. The perimeter controls that worked when a small group of engineers had production access aren't enough when hundreds of people across the organization can modify data through agents, and the next layer of defense, at the data layer itself, is not yet widely deployed.

Baking it into the infrastructure

Bansal pointed to AWS making S3 buckets private by default as a precedent for access control baked into infrastructure rather than left to configuration. Elsewhere, modern platforms building on Postgres are making row-level security a default rather than an opt-in. They are enforcing access rules at the data layer because the environment-level controls alone can't contain what agents and their users are doing.

Bansal sees the future as a hybrid between database-level security as the foundation, and everything else. Endpoint monitoring, developer-level controls, DSPM sensors are all signals for how well that foundation is performing. "The security at the database level, that would stop a lot more risk," he said. "But the other security features are going to be a signal for how well you're doing it. If you're still seeing issues at the endpoint level, that's an early indicator that you've missed something at the database level."

The teams solving this problem in 2026 will be the ones that accepted the old perimeter is gone and started enforcing rules where the data actually lives. Platforms that bake in access controls by default will help, but most enterprises aren't there yet, and the gap between where security teams are and where they need to be isn't closing on its own. Until it does, the backstop is the people in Bansal's position, toeing the line between enablement and sensible inhibition.