Marcus: Security you haven't tested is quite literally just decoration.
Devon: Exactly.
Marcus: I mean, think about it. If you have a system with perfect, impenetrable steel locks, and another system right next to it with padlocks that are just painted on the doors, from the outside, they look absolutely identical.
Devon: They do. You cannot see security.
Marcus: Right. You cannot sense it. You can only test it. And that test always takes the exact same shape. You try the wrong key on purpose, and you watch the door refuse to open.
Devon: We rely entirely too much on the word protected as if it were some sort of magic spell. A team writes a requirements document, someone stamps it secure, and we just assume the locks are functional.
Marcus: Which is wildly optimistic.
Devon: It is. But until you have physically pushed against that door with the wrong credentials and watched the mechanism hold firm, you do not have security. You have a wish with a padlock drawn on it.
Marcus: That is a brilliant way to put it. Let's really unpack the reality of that, because this is the seventh instalment in our 10-part series on building software with AI. And this is all custom-tailored for the non-coder who is directing the build. In our previous deep dive, we focused on meaning-based memory, so how systems find things. We are now asking the inevitable, slightly terrifying next question.
Devon: Which is, once your system can find those things, who else can find them?
Marcus: Exactly.
Devon: The natural progression of building any filing cabinet is teaching your agent how to pull the right files, and then immediately ensuring the wrong people cannot pull those exact same files. The common story we are sold is that security is a dark art that clever engineers quietly weave into the background.
Marcus: Right. The old leave it to the experts routine.
Devon: Precisely. You write a specification, they work their magic, and you trust the label on the tin.
Marcus: But if we look at who actually pays when that label is blindly trusted, the narrative completely flips. If you are directing the software build and the isolation silently fails, the AI agent doesn't pay the price.
Devon: No, it doesn't.
Marcus: The engineers move on to the next project. The people who actually pay are the real users. It is their private folders, their personal data, you know, their daily tasks being exposed to the world.
Devon: It's devastating for them.
Marcus: The person on the hook isn't the software. It is the person directing the build. It is you, the listener, if you believed that protected label without ever actually checking it.
Devon: Because when a breach happens, holding up a specifications document and saying, "But it said it was secure right here," well, that offers zero comfort to the users whose data is just gone. The liability rests with the person who accepted the decoration as reality.
Marcus: It's a heavy realisation.
Devon: It really is. And to understand how a painted padlock happens in the real world, we need to examine what is perhaps the most instructive security failure in the industry. This is a story where everything looked completely right on paper.
Marcus: Let me guess. They wrote all the correct rules for the regular users, but they left some sort of backdoor open for the IT team, and the system just defaulted to that IT key.
Devon: You are incredibly close to the actual mechanism, but the reality is even more mundane, which is actually why it is so dangerous. This was a multi-organisation system. It was designed to serve dozens of different companies.
Marcus: So, strict isolation between those organisations was the absolute highest priority.
Devon: Exactly. And the team did everything they were trained to do. They wrote the isolation rules, they switched those rules on, they meticulously recorded the policies in their paperwork.
Marcus: So, the fire doors installed, the inspector has signed the clipboard, and everyone goes home happy.
Devon: Months later, during an actual test, someone finally tried a wrong key on purpose, and every single door in the building opened.
Marcus: Oh, wow.
Devon: What the testers discovered was that the underlying connection the system actually used every single day was a special administrative key, so the owner's key. The database policy had a fatal blind spot.
Marcus: It recognised that owner's key.
Devon: Yes. It assumed it was an administrator doing maintenance and simply waved it through every single door, bypassing the isolation rules entirely.
Marcus: So, the rules existed in the code, but the application was essentially flashing a VIP badge at the database, and the database was just saying, "Right this way. Go wherever you like."
Devon: The worst part is the absolute invisibility of the failure. Every screen looked normal to the users. They logged in, they saw their own data, they experienced no glitches at all.
Marcus: Nothing leaked immediately.
Devon: Nothing. Because the software was politely asking only for the right data, the flaw remained hidden. But because nobody had ever stood at a door with a normal user's key and actively tried to open another organisation's drawer, well, that owner's key was silently bypassing the locks for months.
Marcus: I am going to stop you right there and push back on this, because I am putting myself in the shoes of a non-coder directing a project. If professional auditors and a team of clever engineers can completely miss a bypassed lock like that, how on earth is a beginner supposed to catch it?
Devon: I wouldn't say it's impossible.
Marcus: But it feels like we are handing a responsibility to people that they simply cannot discharge. Honestly, this story just proves how impossible this is to get right. It is an unfair burden to place on a non-coder.
Devon: I hear the fatalism in that. I really do. And look, if the solution required you to write the cryptographic algorithms yourself, I would agree it was an unfair burden.
Marcus: Yeah.
Devon: But if we strip away the technical mystique, the discipline of security is boringly learnable. The fix for that multi-organisation breach was absolute, and it required zero coding knowledge to dictate. First, you mandate that the policy binds to everyone, including the owner.
Marcus: So, no VIP badges allowed, ever.
Devon: Never. And second, you dictate a wrong key test for every single drawer, and you mandate that those tests run automatically, forever.
Marcus: Okay. So, my job isn't to build the lock. My job is to mandate that someone constantly jiggles the handle to prove it is locked.
Devon: Spot on. Shifting from blind trust to mandatory testing is the only way a non-coder can actually own their system's security. You dictate the test in plain language. You say, "Show me the wrong key failing." You do not need to read the code. You just need to witness the test turn green because the door successfully refused to open.
Marcus: Okay. I think we meet somewhere honest there. The burden is heavy, certainly, but it is manageable because the tool to manage it is a test, not a degree in computer science. But if the ultimate fix is testing specific keys, we really need to understand how keys are handed out in a sensible system in the first place. I mean, you wouldn't just hand one master key to everyone who walked through the front door.
Devon: No, you wouldn't. And this brings us to the architectural foundation of any secure system. It is a concept called least privilege. The rule is brutally simple. Every person and every part of the system gets a key that opens exactly what its job requires, and absolutely nothing more.
Marcus: We actually do this in real life all the time without thinking about it. If you hire a dog walker, you give them a key to the porch, not the deeds to your house.
Devon: Right.
Marcus: If you have a babysitter, they know where the plasters are in the kitchen cabinet, but they do not know your online banking passwords. It is just the sensible matching of access to need.
Devon: Let's map that directly to the architecture of your software. Think about the everyday part of your application, the part that is serving web pages to your users. That part gets a key that can read and write folders in the cabinet, but it absolutely cannot redesign the cabinet.
Marcus: It can't create new drawers or delete the cabinet itself.
Devon: Precisely. Because there is no logical scenario where the everyday user interface needs to redesign the database. That task is reserved for what we called migrations back in our fifth instalment.
Marcus: Migrations run under a completely separate key then.
Devon: They do. One that is used rarely, deliberately, and usually as part of an automated deployment. And above both of those keys, the master key, the one with total control over the database, sits in a digital safe for genuine emergencies. Every single time it comes out, it is strictly logged.
Marcus: I think a lot of non-technical managers feel a bit weird about this level of restriction. It feels like they are actively distrusting their own team or treating their own software agents with suspicion.
Devon: It's a common feeling, but the mechanical reason for least privilege has nothing to do with trust. It is entirely about limiting the blast radius.
Marcus: Because keys leak.
Devon: Keys leak. Mistakes happen. Laptops get left on trains, and an AI agent might hallucinate, or a bug might execute a command nobody intended. When that day inevitably arrives, the only question that matters is, what did that specific key have the power to open?
Marcus: Right. Fewer doors per key means smaller bad days. If the everyday key can only read and write, then the worst possible day is bounded by reading and writing.
Devon: Exactly. But if you gave the everyday application the master key just out of convenience, well, every bad day is potentially a catastrophic, company-ending day.
Marcus: You contain the blast radius before the explosion happens. Now, once you have limited what a key can do, you have to ensure it only opens the right folders for the right users. A limited key is completely useless if the building relies on polite rules to govern where people can walk.
Marcus: I really want to talk about this concept of polite rules, because it contrasts so perfectly with what the industry calls row-level security. A polite rule in the software layer is a disaster waiting to happen.
Devon: It really is.
Marcus: It is like running a hotel where you hand every single guest a master key, and then you just put a polite, neatly printed sign by the lift asking them to kindly only enter their own assigned rooms.
Devon: What makes that hotel analogy even worse is the aftermath. It doesn't matter if 99% of the guests are perfectly honest. The very first guest who is curious or confused about their room number, or actually malicious, is going to cause an absolute disaster.
Marcus: And because everyone is holding a master key, the hotel's security logs wouldn't even be able to tell you which specific rooms that guest wandered into.
Devon: And that is exactly how a polite rule in software works. Somewhere in the code, a developer writes a rule that says, "When showing a person their tasks, filter the list to only show their own."
Marcus: And the fatal flaw is that the rule has to be actively remembered in dozens of different places. Every search function, every data export, every monthly report.
Devon: If the developer or the AI agent forgets to include that filtering rule just once, a user clicks a button and is suddenly reading someone else's private folders. Politeness scales incredibly badly because it relies on perfect human memory.
Marcus: So, we replace the polite sign by the lift with row-level security. How does that actually work mechanically? Because to a non-coder, it sounds a bit like magic.
Devon: It is just brilliant, ruthless maths. Row-level security means the lock lives in the database itself, not in the software application above it. Think of your data not as a pile of folders, but as a vast grid.
Marcus: Okay.
Devon: Every single row of data has a hidden column attached to it called an owner ID. When the software asks the database for information, the database engine physically intercepts the request. It forcibly injects an invisible, unchangeable rule into the query that says, "Only return rows where the owner ID matches the person asking."
Marcus: So, the software can't even politely ask for everything. The database intercepts the request before it executes, filters the maths, and returns a sanitised result.
Devon: It doesn't matter how cleverly the software asks for the data or if a developer forgot a filtering rule upstairs. If you should not see that row of data, the database doesn't argue with you. It doesn't give you an access denied error where you know a locked door exists.
Marcus: It simply behaves as if the data does not exist.
Devon: The maths does not compute.
Marcus: It is a blank wall.
Devon: Yeah.
Marcus: That is incredibly powerful. So, we have separate keys for separate jobs, and we have ruthless locks built into the deepest mathematical level of the building. But all of this impenetrable architecture is completely useless if someone drops the master key on the pavement outside.
Devon: Which brings us to secrets.
Marcus: Exactly.
Devon: This is an unglamorous topic, but it is responsible for a remarkable share of real-world disasters. When we say secrets in software, we are talking about strings of text that function as keys: passwords, API keys, access tokens for payment gateways. Whoever holds that string of text holds the door open.
Marcus: Why do these end up on the pavement, though? If I'm thinking through how this gets built, a developer has to type that API key into the code to connect the payment system, and then, what, they just leave it in the text file out of convenience?
Devon: That is exactly how it happens. They hardcode the secret directly into the file because it is fast and it makes the application work locally on their machine. But writing a secret directly into your code is quite literally taping the alarm code to the front door of the building.
Marcus: And when they publish that code to a repository, which happens all the time when building modern software...
Devon: It is taking a high-resolution photo of the door with the alarm code taped to it and publishing it in a global newsletter.
Marcus: But who's actually reading this newsletter? For small builders, a massive misconception is that a hacker in a dark room is actively targeting their little startup and picking their digital locks. But that's not what happens, is it?
Devon: The reality is entirely automated. The typical breach for a small project is orchestrated by automated scanners. These are scripts running on servers all over the world, trawling public code repositories 24 hours a day, 7 days a week.
Marcus: Just constantly looking.
Devon: They are scanning millions of lines of code a second, looking for strings of text that resemble Amazon Web Services keys or OpenAI tokens.
Marcus: So, the moment you accidentally publish a file with a secret in it, the scanner sees it.
Devon: Within minutes. And once the scanner finds it, it immediately fires off a script to exploit it. It might spin up thousands of cryptocurrency mining servers on your cloud account, racking up a massive bill before you even realise you published the key.
Marcus: So, the cure for this is that secrets belong in a dedicated secrets manager, you know, a digital safe.
Devon: Absolutely. They should never be committed in the system logs. Safes, not files.
Marcus: And there is a crucial rule from the hotel trade that applies here as well. If you even suspect a physical key might have been lost or leaked, you do not hold a committee meeting to debate whether it really happened. You rotate the key immediately. You change the lock.
Devon: Rotating a digital key takes a few minutes. Debating it and being wrong puts you in a headline you do not want to be in.
Marcus: Let's bring in the AI agent angle, because the tools we use to build software read our project files constantly. If a secret is sitting in a text file, a coding agent might completely innocently quote it back to you in a chat or copy it into an output document.
Devon: Which is why the agents themselves must also work inside a secure building. They need to be subject to least privilege just like a human developer. At the time of release, we can look at how the major tools handle this architectural requirement.
Marcus: Right.
Devon: Claude Code, for instance, runs on a very strict permissions model. You either approve commands one by one, or you grant standing permission only for routine, safe actions, keeping anything consequential strictly manual.
Marcus: Handing out porch keys to the agent, not the house deeds.
Devon: And Codex pairs its approval settings with a strict sandbox. This is a physical confinement layer that forcibly stops the agent from writing outside the specified project folder or reaching out to the wider internet unless you have explicitly granted it permission to do so.
Marcus: That is not the tool being weak or limited. That is the hotel building actively enforcing the boundaries.
Devon: Exactly.
Marcus: So, we have covered the danger of painted padlocks, the architecture of least privilege, the mathematics of row-level security, and the absolute necessity of keeping secrets in a safe. Let's give the listeners some concrete, actionable steps they can take away from this right now.
Devon: The first step is to write out your system's keyring. Just three simple lines in plain English. Define the everyday key. State that it may read and write folders, but it may not touch the cabinet's design.
Marcus: Okay.
Devon: Define the cabinet key. State that it runs migrations, is used rarely and deliberately. And define the master key, locked away, every single use logged.
Marcus: That immediately clarifies the boundaries for whoever is actually writing the code.
Devon: Yeah.
Marcus: What is the second step?
Devon: The second step is to write your very first wrong key test. Again, in plain language. For example, "Using the everyday key, attempt to redesign the cabinet. This action must fail." That single sentence is a rigorous security test.
Marcus: Eventually, an agent or a developer will turn that into executable code, and you will watch it refuse to run.
Devon: And until you watch it refuse, you have to tag your security honestly in your mind and in your documents. This is the third step. Tag your security as specified. Do not call it live. Do not call it secure.
Marcus: Call it specified, which means it is just a wish with a padlock drawn on it.
Devon: Keep that tag there until you have watched the wrong key fail. Taking those steps shifts your entire mindset. You move away from the dangerous assumption that security is a static state of being, and you move toward the reality that security is a constant, aggressive process of verification.
Marcus: I want to leave you with a final thought on that psychological shift. If you truly want mastery over the software you are directing, especially as a non-coder, you have to actively reprogram your own brain.
Devon: It's true.
Marcus: We are culturally conditioned to feel comfortable when things work smoothly. When the green lights flash, the data flows, and the doors open seamlessly, we feel safe. But in the world of security, the absence of friction is not a sign of safety.
Devon: A healthy system is constantly swatting away unauthorised attempts, automated scanners, and confused permissions.
Marcus: If you only know your locks work when you see a door successfully slam in your face, then absolute silence in your system is actually the loudest alarm bell of all.
Devon: If you do not see the swatting, your sensors are broken.
Marcus: If everything is quiet, you aren't secure. You are just blind. Keep testing your locks. Keep asking the hard questions. Demand to see the failures, and we will see you on the next deep dive.