The Bank Vault: Why Some Data Must Be Categorically Off-Limits

The Sentinel Ridge Files · Track 1: The Framework

The Bank Vault: Why Some Data Must Be Categorically Off-Limits

The Bank on Main Street

When I was in high school I worked at the bank in my hometown. We knew everybody that came in there. I might not have known every single individual but you can guarantee that one of the seven tellers that worked in that bank knew every single individual that walked in the door or pulled through the drive-through. Without exception. I even remember a few times people saying “That signature doesn’t look correct. Joey, come on and let me show you how to verify a signature on a check from the records.” We had a big roll-up cabinet desk thing where all of the customers’ signatures of record were on file. The point is that if we knew something was wrong, we were going to double-check it and make sure that our customers didn’t lose money from fraud.

But there were areas that were less secure in the bank itself. There was a big conference room that people were able to book and utilize for meetings if they chose. There were offices that had keyed doors on them and even keyed file cabinets inside, but if you were determined enough, you’d gain access. In fact I remember having my first ever performance review in one of those offices. Mr. Weatherby was very kind as he told me that I was defensive. To which I responded “Defensive? I’ve never been defensive a day in my life…” But that’s a different story for a different time.

What we also had, though, was a vault. Now I have to tell you the vault was simultaneously cool and terrifying. During normal business hours the vault was open with a metal bar door that had two keys to gain access. This is where people could go in and get into their safety deposit boxes, which also required two keys: one held by the person and one held by a teller. But when we closed down at 5 p.m. every single day, the vault was closed. Once it closed it was not opening until 6 a.m. the following morning. It was a giant metal door. It had the big spinning wheel in order to close the metal struts that protruded into opposite sides of the wall. The only way that it could have been cooler to a kid like me was if it had been round. Sadly this one was rectangular.

The point is that once something was in that vault and it was sealed, you weren’t going to get it out. Once the manager closed the vault for the evening, the only way that you were going to break in was to rip holes through the walls or tunnel under the floor. Couple that with the fact that the building was in the middle of downtown. I can guarantee you that no one stood a chance of getting into that area of the bank after hours.

I mentioned that it was terrifying and I meant that. I didn’t want to wind up getting locked into that vault on the weekend, particularly a three-day weekend when I would wind up getting stuck in there with no hope of getting out. It wasn’t that I was afraid of suffocating or anything like that. I just had a love for food, and I didn’t want to be separated from my mistress for that long.

The Locked Office

When I worked at the bank I worked one week as a teller and then I would work the next week as a data processor. I preferred working as a data processor most times but I didn’t always get to do that. I had to learn both sides of the business.

We had a very large microcomputer that took up an entire room in the bank. It was a small room mind you but it was a very big computer especially compared to what we have available to us today. In order to gain access to that room I had a key that allowed me in. When I came in the evening it was generally about fifteen minutes before closing. I used one key in order to gain access to the back door of the bank. My vehicle was in the back parking lot and I walked to the back door, inserted my key, and turned it. As soon as you removed your key from the outside of the door the lock engaged again. When you closed the back door, which was a very large metal door, it automatically locked behind you. This prevented someone from accidentally leaving access to the bank open because of a human error.

I had a separate key for the computer room that I needed to get into. It was one of those big heavy wooden doors. I kept my back door key on me all the time. This was because whenever I came in toward the end of my school day to work as a teller, I would use the same back door to come in. But I only had the key to the server room when it was my week to do the data processing. One of my friends and classmates, Tenille, worked the opposite shift of me. When she was working as the data processor, I would give the key to her so that she would have access to the server room but during those weeks I had no access to the computer physically. If I had really wanted to gain access to the server room, I could have done so in a number of ways. I wasn’t really into mischievous activities but had I been I would have learned how to pick locks and then I would have immediately had access to the server room. If I was a would-be thief that wanted to do something with the computer system, I could have potentially shot the hinges off the door with double-aught buckshot. At that point the door would have easily fallen off with a single push.

The point is that while the door and the lock on the server room served as a deterrent to prevent unauthorized individuals from gaining access to the computer system contained in that room, it was not a foolproof way of keeping ne’er-do-wells out. It was basically a way of keeping honest people honest.

The Vault

So let’s pretend like it’s one of the weeks that I’m the data processor. I’m there doing my thing and all of a sudden the cleaning team comes in. They were a very nice family who were very kind to me. Great folks with a tremendous amount of character and honest to the core. I always loved it when they came in.

Thankfully this never happened but imagine what happens if one night this wonderful family winds up having criminals take them hostage and gain access to the interior of the bank. They had the same key to get through the back door that I did. Let’s say that these criminals come in and they point guns at this wonderful family and then they tell me that if I don’t open the bank vault door, they’re going to kill them.

I’m going to pause for a second and say that I am glad that this never happened. The reason is simple: I would have had NO POWER TO SAVE THEM. I was a big fan of cheesy action movies back in the day so I’m sure I would have wound up getting killed doing something stupid trying to save them. But there was no way that I would be able to save them by opening that vault door. It’s on a timer. It’s basically a giant metal cube. There’s no way that I’m going to be able to grant you access to this because I simply don’t have the authorization.

If you really want to get technical about it, no one in the world had the authorization to grant access to that door until 6 a.m. the following morning. It wouldn’t be that I didn’t want to save the people. I just couldn’t. This is because the bank had made a determination that they would make it so that the people who stored their assets in that vault could rely on them to be safe overnight when there were no employees in the bank. What is a sure-fire, guaranteed way to make sure that no one can steal anything out of the vault? Make it so that it cannot be accessed by anyone. Not the bank manager, not the town’s mayor — who also worked at the bank, by the way — or even the governor of the state where I lived. It was literally impossible to gain access to the vault after hours.

In our town of agentic AI we have made many parallels, starting primarily with that of the town clerk’s office. But we mentioned in our last article that the town clerk has no say in who does or does not have access to the bank vault. All the clerk can do is issue an identity for each agent that is in our fictional town. It is up to the bank to determine who is authorized to get access to the vault. Just like it was up to the bank where I worked to determine who got access to Mr. Jimmy’s office or who got access to the vault itself.

Code, Not Policy

So what about our Agent Town? Is there some type of analog? Turns out there is. When it comes to creating a vault in Agent Town, it must live in code, not policy. Why is that? Well much like the bank vault door, deterministic code paths behave predictably and can be audited — and they don’t change their mind based on how you ask.

I need to introduce an important concept here: non-deterministic behavior. That’s what an agent is. I cannot guarantee that an agent is going to behave in a certain way because it is non-deterministic by nature. Well-structured sequential code that I write with a language such as Python, Rust, C++, or — heaven forbid — Ada behaves deterministically. When a particular input is sent through the code, it will take the same path every single time as long as that input is identical and the conditions match. With agents they may take a different path even with identical input.

If I’m going to protect data, I have to consider the non-deterministic nature of agents. Certainly there are deterministic portions to agents but the models that make the decisions or the determinations are definitely not. Therefore you have to control access to sensitive data with code and logic and controls that are not based on large language models or any other type of machine learning algorithms.

Why is that? Well first you don’t know what’s going to happen with those agents. They could be sent by a rogue system. What happens if an agent winds up getting pointed at the wrong large language model? If that LLM is controlled or trained by an attacker, the behavior that you get from the agent will be completely different than if the appropriate pre-assigned LLM is used. This is not hypothetical. All I’m going to ask is: have you 100% secured your LLM gateway?

But even if the LLM is the one that you intended to be used, what happens if the wrong input or prompt goes into that model? Can you guarantee that it’s going to behave the way that you want it to behave even if it gets the wrong prompt? And then for those of you who have used LLMs for any amount of time at all, you probably know what I mean when I say bit rot. We have fancy names for this these days — “context drift,” “pollution,” things like that. But really what it comes down to is sometimes they just don’t behave the way that you expect them to behave. These agents have to be terminated and re-created so that you can get back to a more stable state.

Because of this type of behavior, which is inherently unpredictable, there are some data stores that you must protect to a different level. You need to have:

  • Steel walls
  • Steel ceilings
  • Floors that cannot be penetrated
  • Doors that lock and are controlled with a timer

Of course I’m not suggesting that you implement these things exactly in this manner. I’m using the bank vault as an illustration. There have to be controls that are in place which cannot be violated no matter how badly the agent wants to violate them. How many times have you seen a model make up information because it thinks that that will please you? Why do you think that the same model is going to behave differently in an agentic system versus a web GUI?

Categorical constraints must live in code and not in policies that can be bypassed easily. Those easy-to-bypass policies are more akin to the wooden door that protected the server room that I told you about previously. Deterministic code is like the bank vault. In security architecture this principle has names — “secure by design” and “correct by construction.” The idea is that you build the system so that the forbidden action has no code path to execute rather than trusting a policy to prevent it. The bank didn’t trust a policy that said “don’t open the vault after hours.” They built a timer that made it physically impossible.

Access Control vs. Data Sovereignty A comparison diagram showing the fundamental difference between access control (conditional, policy-based, bypassable) and data sovereignty (categorical, code-based, cannot be bypassed). Organizations deploying agents need both. ACCESS CONTROL vs. DATA SOVEREIGNTY The Locked Office Access Control Conditional "You are not authorized" Can Be Bypassed Escalated, picked, or social-engineered Policy-Based Non-deterministic agents can subvert A Wooden Door Keeps honest people honest The Bank Vault Data Sovereignty Categorical "This never leaves, period" Cannot Be Bypassed Not by anyone, not at any privilege level Code-Based Deterministic, auditable, no code path to violate A Time-Locked Vault Cannot open until 6 AM regardless of who asks Necessary but insufficient Required for crown jewel data Organizations deploying agents need both.
Access control is conditional and policy-based. Data sovereignty is categorical and enforced in code. Organizations deploying agents need both.

The Town Charter

So let’s imagine that the local town bank and its vault is where our town charter resides. This is our town’s founding document. Maybe it’s been here and present for decades. Maybe even centuries, depending on how old our town actually is. It’s the most important document that we could possibly have within our town because without it we don’t actually know how we are to be governed. If someone were to come in and take it from us, they could hold it hostage. They could demand some type of ransom. Not only does it have practical value from the standpoint of it defining how our town is to be governed but it also has historical value and even sentimental value for the residents of the town and those who choose to serve. It could potentially command a very high price if held for ransom or maybe even sold to neighboring towns who are less than amicable towards our town.

Every organization, whether it be a company, some type of government agency, or even someone who keeps data on their own home network, has data that is equivalent to the town’s charter. I can’t tell you what it is and by that I don’t mean that I don’t know what my data is from a town charter standpoint. I mean that I can’t determine what your town charter equivalent is in your organization. If you’re a business maybe it’s secrets that are specific to the way that you cook a particular dish that you serve at your restaurant. If you’re a government agency maybe it’s the information about your constituents who make use of your governmental services. If you’re an individual maybe it’s your pictures and photos from years gone by that have slowly accumulated.

The point is that you have to determine what is supposed to go into your vault and not just how to build the vault itself. If that bank vault where I worked as a young man had nothing of value in it, then all it’s doing is taking up space. If the mayor kept the town charter in a drawer in his home rather than in the bank vault, then the bank vault would have served no purpose.

You are the one who has to determine what level of security your vault needs to have in order to protect your data. You need to determine what is important enough to be housed alongside the town charter. I used to have a CISO who would tell me that we shouldn’t try to solve a $50,000 problem with a $5 million solution. But at the same time you don’t want to try and protect a $5 million data store with a $5 USB drive.

Nothing Is 100% Secure

Now I want to take a moment and try to address something that many of you have probably been screaming at your computer monitor as you read this. I said that it was impossible to get into the bank vault. Some of you were probably thinking of the Joker from Batman, who got a group of individuals to help him break into a bank vault. You may have also thought, “Well deterministic code can be hacked or maybe we find vulnerabilities inside of it or in the runtimes that execute the code.” All of this is true. And thank you for helping to keep me honest.

One thing that I have found in my decade and a half of cybersecurity as well as the prior decade-plus of development work that I did is that nothing is 100% secure. And just like a determined individual who wants to get into that bank vault can do so if they have the tools and resources available, determined entities can gain access to your town charter level data.

So why bother with a vault? I mean if the reality is that it can be breached, what’s the point of having it? Well the vault really isn’t there to prevent a criminal from getting access. It’s there to prevent a criminal from getting access within a shorter amount of time than it takes for qualified law enforcement to respond to the alarm.

Back in 1999 a security researcher named Winn Schwartau published a concept called Time-Based Security. His formula was simple: Protection time must exceed Detection time plus Response time. And you want to know what example he used to explain it? A bank vault. The vault buys time. The alarm triggers detection. Law enforcement provides the response. If the vault holds long enough for the cops to show up, the system works. That is exactly what we need in our Agent Town. The digital equivalents of our vault — hardware security modules that refuse to export keys under any circumstances, secure enclaves where sensitive computation happens in isolation, systems built so that no API exists to perform the forbidden action — these are real and deployed across billions of devices today. But they only work if someone is watching the alarm. And that brings us to the next building our town needs: the sheriff’s office…


References

  1. Schwartau, Winn. Time Based Security. Interpact Press, 1999. Also published as “Time-Based Security Explained: Provable Security Models and Formulas for the Practitioner and Vendor” in Computers & Security, Elsevier. Establishes the P > D + R formula using a bank vault as the primary example.

  2. “Secure by Design.” Cybersecurity and Infrastructure Security Agency (CISA). Initiative shifting the security burden from end users to manufacturers. Over 250 companies have signed the pledge.

  3. Chapman, Roderick. “Correctness by Construction: A Manifesto for High-Integrity Software.” Altran Praxis / Praxis High Integrity Systems. Formal methods paradigm where security properties are guaranteed by system structure. Used for the NSA’s Tokeneer ID Station project.

  4. “Security Requirements for Cryptographic Modules.” FIPS 140-3, NIST, March 2019. Defines requirements for cryptographic modules including HSMs — keys cannot be exported in readable form.

  5. “The Secure Enclave.” Apple Platform Security Guide. Hardware keys are not visible even to the Secure Enclave’s own operating system.

  6. “LLM01:2025 Prompt Injection.” OWASP Top 10 for LLM Applications, 2025. Ranked #1 threat for the second consecutive edition — LLMs process instructions and data in the same channel without clear separation.

  7. Wu, Yulong et al. “Natural Context Drift Undermines the Natural Language Understanding of Large Language Models.” Findings of EMNLP 2025. Demonstrates 30%+ accuracy drops from context drift.

  8. Dongre, Vardhan et al. “Drift No More? Context Equilibria in Multi-Turn LLM Interactions.” October 2025. Studies context drift specifically in multi-turn conversations.

  9. “Defence in Depth.” Military strategy origin, adapted to cybersecurity by NSA. “Seeks to delay rather than prevent the advance of an attacker, buying time and causing additional casualties by yielding space.”

  10. “AI Agent Standards Initiative.” NIST Center for AI Standards and Innovation (CAISI), February 2026. NCCoE concept paper: “Accelerating the Adoption of Software and AI Agent Identity and Authorization.”