Authorization Has Always Been Hard, and a New Generation of Builders Is Discovering Why

Broken access control has been the industry's longest-running unsolved problem. When OWASP refreshed its Top 10 in 2021, the category moved from the fifth slot to the first on the strength of a single line in the methodology: "94% of applications were tested for some form of broken access control with the average incidence rate of 3.81%, and has the most occurrences in the contributed dataset with over 318k."

Authorization climbed the list not because developers got worse, but because authorization is the layer where business logic and security collide, and that collision has been quietly defeating well-staffed engineering teams for two decades. What has changed in the last year or two is the audience. AI-assisted builders, citizen developers, and a wave of new entrants are now running headfirst into the same wall that staff engineers at recognized companies have always struggled to climb, except that there are simply more people in the line now.

The wall is well-documented

One of the more telling admissions comes not from a vendor blog or a thought leader's post, but from OWASP's own Authorization Cheat Sheet, in a passage advising engineers to vet their third-party tooling carefully: "Writing complex, secure software is hard. Even the most competent developers, working on high-quality libraries and frameworks, will make mistakes." The guidance is addressed to engineers shipping production systems, and it concedes that the most popular libraries and most senior practitioners get authorization wrong with regularity.

The operational consequence is unforgiving. The Cheat Sheet frames it as a single-strike budget: one missed access-control check is enough to compromise the confidentiality or integrity of a resource. The attacker only needs one path in, while the defender has to find all of them.

Authorization defeats senior engineers, too

The current discourse keeps wanting to make the story about inexperienced developers, but the receipts from inside enterprise consulting tell a less convenient version. Satish Kumar Anandhan is a senior architect at Salesforce on the MuleSoft and Data-Driven AI Solutions side, with prior architecture work across major banking systems including HSBC, Citi, Lloyds, and Barclays Card. He has watched well-funded engagements ship without proper authorization controls in place, including engagements run by firms whose entire commercial premise is doing this correctly.

"We get pulled into a lot of these engagements after the fact," Anandhan told The Read Replica. "I can say, even big consulting companies have screwed up the work. We go in to see what they've done, and they never put the guardrails in place."

What Anandhan describes is the empirical version of what OWASP says abstractly, and his framing for why it happens is architectural rather than psychological. "If you don't have the right guardrails in place and somebody asks the agent for confidential info from the database, and you haven't fed that instruction as a guardrail, the agent is going to get it, because the LLM is built to retrieve whatever you ask for," he said. "You need to guard the agent so it doesn't take actions outside the boundary you've defined."

The defense, Anandhan said, belongs in the system rather than in the prompt. "There has to be a common layer to handle authentication and authorization," he said.

The new audience is a scale signal

What Anandhan sees in his agent work is the same wall many have described for years, only with the surface area multiplying. Where a database used to be queried by a handful of services owned by a small team, it now answers to an expanding fleet of agents, each carrying its own implicit assumption about what it is allowed to see.

"Each agent should have the right level of control," Anandhan said. "Otherwise you're not bringing the right security controls in place, and you're exposing all sorts of data to the agent. And it's always a risk, because AI will always hallucinate."

The hallucination point tends to get argued past too quickly. The failure mode of probabilistic systems demands the same deny-by-default discipline that careful engineers have always applied to deterministic ones, only now the deterministic boundary has to do more work, because the thing operating against it is no longer constrained by intent.

"Querying the database directly, I would say, is 'the baby way'. The developer that is just starting out does the job that way. He gets it done, but that's not the right architecture design," Anandhan said. The mature pattern moves access control out of the application and into a mediation layer that the agent has to traverse. "It should go through MCP. MCP is your layer, and MCP can do the rest of the stuff," he said. What that layer permits is itself an architectural decision rather than a runtime accident. "There has to be a configuration layer that defines what data can be exposed to what type of audience, and what cannot. Those controls have to be strictly in place," he said.

When teams get that architecture right, the upside is unusually concrete: the risk-adjusted math improves on its own. "Let's say some misconfiguration happens, or some issue happens. Your blast radius isn't that big in terms of data leak," he said, especially with organizations that run their models against locally hosted infrastructure rather than shipping queries to a hosted model provider.

Move the line to the data, not the human

Where Anandhan's experience comes from cleaning up after consulting engagements, Ryan Hildebrand's comes from running a tech-enabled bank. Hildebrand is EVP and Chief Innovation Officer at Bankwell, where his job is to let 180 employees build with AI tooling without putting the bank's charter at risk. His architectural answer to the citizen-developer wave is to move the access-control line away from the human and onto the data itself.

"We let people experiment too freely before we had data classification locked down," Hildebrand told The Read Replica. "You need to know where your sensitive data lives before you let AI tools anywhere near it. We fixed that fast."

The fix at Bankwell starts at the infrastructure layer. "Microsoft Purview handles data classification and access controls at the infrastructure level," Hildebrand said. "Approved tool list is short and intentional. We'd rather go deep on fewer tools than let people scatter across 30 platforms."

What Bankwell allows on the human side is then unusually permissive, precisely because the data layer is doing the work. "Any employee can use Microsoft Copilot today to build workflows, draft documents, analyze data. No special approval needed," Hildebrand said. "The line is clear: if it touches customer data or feeds into a decision that has regulatory weight, it moves into formal review."

The bar for what counts as production-ready is set with regulators in the room. "Production-ready at Bankwell means it can fail gracefully, it's logged, it's auditable, and a regulator could look at it and understand what it does and why," Hildebrand said. "If you can't explain it to an examiner, it's not ready."

Hildebrand's screen for which AI tools clear the door for any data work at all is just three questions, and they read like a deny-by-default checklist drafted for the regulated-bank context that OWASP has not had to write yet. Where does the data go? Can the tool be audited? Does the vendor's contract let them train on Bankwell's inputs? "If any of those answers are wrong, it's dead on arrival," Hildebrand said. "We don't care how good the tool is."

Hildebrand's team measures the value of these workflows the same way it measures everything else, in hours returned to higher-value work, net of the compliance cost of running them. "If a workflow saves 10 hours a week but introduces a compliance review that takes 8, that's 2 hours of real value, not 10," he said. "We've absolutely killed projects that looked promising. The warning sign is when the team can articulate the cool but not the why."

The platform layer is catching up

The Postgres community shipped the database-side primitive a decade ago. The PostgreSQL 9.5 release notes, dated January 2016, list among the major enhancements: "Add row-level security control (Craig Ringer, KaiGai Kohei, Adam Brightwell, Dean Rasheed, Stephen Frost). This feature allows row-by-row control over which users can add, modify, or even see rows in a table." Row Level Security has been in core Postgres for ten years, waiting for the rest of the stack to catch up.

Back in July 2020, Supabase co-founder Paul Copplestone immortalized on X that "for Authorization, we use PostgreSQL's Row Level security - it's about as programmable as you can get." Six years later in a post-AI world, the company announced that new tables in the public schema would no longer be automatically exposed to the Data API in new Supabase projects, with permissions now requiring explicit grants through the dashboard or via SQL. "Explicit Postgres grants are reviewable, diffable, and greppable," the company wrote. "This was always possible; now it's the default."

One platform's default change tells a smaller story than the trend around it. Postgres added the primitive in 2016, OWASP has been prescribing the posture since at least 2017, and the layer where applications actually meet the database is, slowly and unevenly, moving its defaults to match.

What better defaults unlock

The empathy frame the brief asks for has a sharp edge underneath it. Less-experienced builders are not to be coddled, and they are not the cause of broken access control. The same architectural moves that protect a senior engineer's code also protect a citizen developer's code, and the platforms that internalize this stop treating authorization as a question of operator discipline.

Anandhan's advice for the less-experienced developer pivots away from blame toward architecture. "Let's say you're a basic developer who just writes code and gets the stuff done. You don't know the complete aspect of how to do proper AI development. You're bringing a feast to the hackers," he said. The attack surface gets named, the person standing in front of it does not get blamed, and the fix lives upstream of any individual builder's judgment: a mediated access layer, deny-by-default behavior, and explicit grants that show up in code review.

The story the industry keeps trying to tell is that authorization is a tax on builders. Hildebrand's bar tells a different one. Every employee can use Microsoft Copilot, draft documents, and analyze data with no special approval needed, precisely because the line has been moved to the data. The production-readiness bar is what lets him say yes to the on-ramp. Authorization, when it is built into the platform rather than bolted onto the team, is the permission slip rather than the gate.

The platforms and teams treating this as a defaults problem will spend the next decade getting authorization quietly right. The ones still framing it as a competence problem with the new builders will spend that same decade re-learning what OWASP has been saying since 2017. The wall hasn't moved an inch. The line in front of it is what keeps getting longer.