eLearning Systems Archives - Application Development Cloud

Securely Connecting Claude to Internal Resources: A Reference Architecture for Database and Filesystem Integration

Abstract. Large language model assistants have moved from advisory tools to agentic systems that read files, execute commands, and query production databases under delegated authority. This shift invalidates a core assumption of conventional application security: that the caller is deterministic code whose control flow was reviewed before deployment. When the caller is a language model, the instruction channel and the data channel are the same token stream, and no amount of prompt hardening reliably separates them. This article surveys the threat surface created by connecting Claude — through the Model Context Protocol (MCP), through agentic coding clients such as Claude Code, and through direct tool-use APIs — to internal databases and filesystems. It then proposes a defense-in-depth reference architecture whose central claim is that all security-relevant enforcement must occur below the model, in systems the model cannot argue with. Concrete control sets are given for relational database access and filesystem access, followed by a treatment of detection, assurance, and governance mapping. The article closes with open problems, including the unresolved tension between agent utility and the structural vulnerability known as the lethal trifecta.

Keywords: agentic AI security, Model Context Protocol, prompt injection, tool poisoning, least privilege, row-level security, sandboxing, non-human identity

1. Introduction

The practical value of an AI assistant inside an organization is roughly proportional to what it can reach. An assistant that cannot see the student information system, the finance warehouse, or the shared document store is a well-read stranger; one that can see them becomes an analyst. Every integration that increases utility, however, also increases the consequences of a successful manipulation, and the manipulation vector for language models is not a memory-corruption bug or an injection flaw in a query builder. It is text.

This is the asymmetry that makes agentic integration a distinct security discipline rather than a special case of API security. Traditional API security assumes an authenticated caller executing reviewed code against known endpoints with validated inputs. An agentic deployment inverts two of those assumptions. The caller is a probabilistic model that decides at runtime which tool to invoke and with what arguments, and the inputs it reasons over include content the organization does not control: web pages, uploaded documents, ticket bodies, database text fields, package README files, and the descriptions advertised by third-party tool servers.

The consequence is that controls expressed as instructions to the model — system prompts, tool descriptions that say “never access PII,” policies written in natural language — are user-experience features, not security boundaries. They express intent. They do not constrain capability. This article’s organizing principle follows directly: enforce in the engine, not in the prompt.

The scope here is deliberately narrow. It concerns the connection between a Claude-based agent and two categories of internal resource: relational databases and filesystems. These two are chosen because they are the most commonly integrated, the most sensitive, and the most instructive — filesystem access is where credential theft happens, and database access is where regulated data lives.

FORGE: A Five-Step Method for Thinking in the Age of AI

Building on the SIFT method with a framework designed for a generation that uses AI to find the truth, not just to question it.

Suggested citation: Denney, D. W. (2026). FORGE: A five-step method for thinking in the age of AI. Realm Forge Academy Research. Published May 12, 2026. https://apps.dwdenney.com/forge-a-five-step-method-for-thinking-in-the-age-of-ai/

License and use: This research is published openly and freely. Journalists, researchers, educators, and students are welcome to read, reference, cite, and build upon this work with proper attribution using the citation above.

The method that got us here

In 2017, a digital literacy researcher at Washington State University named Mike Caulfield introduced a framework he called the Four Moves, later formalized as the SIFT method — Stop, Investigate the Source, Find Better Coverage, Trace Claims to their Origin (Caulfield, 2017; 2019). SIFT was designed as a fast, practical alternative to the older CRAAP test (a checklist-based evaluation method that had been the default in academic libraries for years). Where the CRAAP test asked students to evaluate a source in isolation — currency, relevance, authority, accuracy, purpose — SIFT asked them to leave the source and check what the rest of the web said about it. The technique Caulfield called “lateral reading” was borrowed directly from professional fact-checkers, and it worked.

SIFT became, and remains, one of the most widely adopted information literacy frameworks in higher education. It is taught in university libraries from Chicago to Carleton. It has a Creative Commons license, a companion course, and a substantial body of classroom adoption behind it. I want to be direct about this: SIFT is good work. It does what it was designed to do, and what it was designed to do is important. The emotional pause. The source investigation. The upstream tracing. These are genuine skills, and Caulfield deserves credit for distilling them into a framework simple enough to teach in a single class session.

But SIFT was designed for a specific information landscape — the landscape of 2017, where the primary threat was misinformation spreading through social media, and the primary question was “should I believe this?” The landscape has changed. The threats have changed. And the tools available to the person doing the evaluating have changed in ways that SIFT, through no fault of its own, does not address.

This post introduces FORGE — a five-step framework that builds on SIFT’s foundation and extends it for a generation that lives in a world SIFT wasn’t built for.

Five Thousand Years to Get Here

A brief history of every tool humanity ever built to teach its children — and the one that finally broke the pattern.

By D.W. Denney

Every tool on the same curve

I want to tell you a story that covers five thousand years and fits on the back of a napkin. It’s the story of every educational technology humanity has ever invented, and the punchline is that until very recently, they were all doing the same thing.

Here’s the napkin version. Somebody knows something. They need to get it into somebody else’s head. Every tool we’ve ever built for that purpose — every single one, across all of recorded history — has been a more efficient way to do one of four things: store information, distribute information, drill information into memory, or assess whether the information stuck. That’s it. Four functions. Five millennia. One curve.

Let me walk you through the timeline, and watch how the technology changes while the function doesn’t.

Oral tradition. Before writing, knowledge lived in the mouths of elders and was transferred by speech. The teacher spoke. The student listened, repeated, and memorized. If the elder died before the transfer was complete, the knowledge died with them. The storage medium was the human brain. The distribution method was the human voice. The range was the distance sound carries across a campfire. This worked, and it worked for a long time, and the stories and songs and genealogies that survived this era are a testament to how powerful the human memory can be when it has no other option. But the system was fragile. One forgotten line, one dead elder, one scattered tribe, and the knowledge was gone.