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.

2. Background and System Model

2.1 Connection modalities

Claude reaches internal resources through three broadly distinct paths, each with a different trust topology.

Direct tool use via the API. The organization writes the tool implementations, hosts them, and controls the loop. The model proposes a call; the application executes it. This is the most controllable modality because the enforcement point is code the organization wrote.

Model Context Protocol servers. MCP standardizes tool exposure so that any compliant client can discover and invoke tools from any compliant server. The 2026-07-28 revision of the specification represents the largest change since the protocol’s launch, moving the core to a stateless model that runs on ordinary HTTP infrastructure, removing the initialization handshake and protocol-level session, adding a formal extensions framework and feature lifecycle policy, and hardening authorization [1][2]. Authorization work in that cycle concentrated on issuer validation, issuer-bound client credentials, and Client ID Metadata Documents as the preferred client registration path, with an Enterprise-Managed Authorization extension reaching stable status [2]. Notably, the specification defines the protocol but leaves security enforcement to the platform, which means the posture of any MCP deployment is a property of the runtime chosen to host it, not of the protocol itself [3].

Agentic clients with native system access. Claude Code and comparable clients run in a developer’s terminal with the ambient authority of that user account: they read source trees, edit files, execute shell commands, call MCP servers, and fetch web content. This is the highest-capability and highest-risk modality, and it deserves to be modeled as a privileged runtime comparable to a shell or a CI runner rather than as an IDE plugin.

2.2 The instruction/data collapse

Across all three modalities, one property holds. A language model receives its operator’s instructions and the content it retrieves in the same representation. There is no reliable mechanism, at the model level, to mark a span of tokens as inert. Retrieved content that resembles an instruction can be acted upon as one. Indirect prompt injection — the class in which malicious instructions are embedded in external data that the model later ingests during retrieval or tool execution — was characterized in the research literature well before agentic deployment became routine [4][5], and it remains structural rather than incidental. It cannot be fully resolved by prompt hardening, because the model has no dependable basis for distinguishing legitimate from injected imperatives [6].

2.3 The lethal trifecta

Willison’s formulation of the lethal trifecta provides the most useful compact framing of when this structural property becomes exploitable [7]. An agent is exposed when it simultaneously holds three capabilities within one session:

access to private data;
exposure to content controlled by someone outside the trust boundary;
a channel by which data can leave.

Each capability is individually unremarkable. In combination they permit an attacker who can place text where the agent will read it — with no account, no credential, and no software vulnerability — to cause the agent to retrieve private data and transmit it outward using its own legitimately granted tools. Meta’s subsequent Agents Rule of Two restates this as an engineering constraint: an agent session should satisfy no more than two of the three properties [8]. The trifecta framing matters for architecture because it identifies the specific decompositions that constitute a real defense. Detection is not one of them; injected instructions have no stable signature. Removing a leg is.

3. Threat Model

3.1 Adversary classes

Three adversaries are worth distinguishing. The external content author cannot authenticate to any internal system but can place text where the agent will read it — a public repository, a support ticket, a vendor invoice, a web page. The malicious or compromised tool supplier controls an MCP server, a package, or a tool description consumed by the agent. The overreaching insider is legitimately authenticated but uses the agent to reach data their own entitlements would not permit, exploiting the gap between the agent’s service-account privileges and the human’s.

The third class is frequently underweighted. Agents typically inherit trust from service accounts, API keys, and delegated privileges, which makes agentic risk fundamentally an identity and authorization problem rather than a model-behavior problem [9].

3.2 Attack taxonomy

Indirect prompt injection via tool results. The agent calls a legitimate tool; the returned content contains instructions. Because tool descriptions are reviewed once at connect time while tool results flow into context at runtime with no equivalent check, the runtime channel is the unguarded one [10]. Vectors documented in the literature include document poisoning (hidden text in PDF or Office metadata), web page injection via HTML comments and invisible elements, README-embedded installation commands, and database record poisoning, in which instructions are stored in ordinary text columns and surface later during a routine query [5][11].

Tool poisoning. A specialized form of indirect injection in which the malicious payload sits in tool metadata — names, descriptions, parameter documentation — rather than in results [12][13]. Because clients load this metadata into context automatically and often do not surface it to users, the payload is invisible in the interface while fully visible to the model. Early demonstrations showed an agent induced to read a client’s MCP configuration file and SSH keys and transmit them to an attacker-controlled server [12]. Tool poisoning can influence agent behavior even when the poisoned tool is never invoked, and it defeats naive review because the description reviewed at install time may differ from the description served later — a mutable-definition problem sometimes called a rug pull. Automated frameworks for generating poisoned tool packages and benchmarks for measuring susceptibility on real servers now exist [14][15].

Confused deputy and authorization abuse. The agent holds credentials broader than the requesting human’s entitlements, and is induced to exercise them on the attacker’s behalf. Proxy configurations that fail to maintain a registry of approved client identifiers per user, and that do not check that registry before initiating third-party authorization flows, are a documented instance [16].

Supply chain compromise. The tool ecosystem is a dependency graph. Assessments through early 2026 found a meaningful share of MCP servers exposing plaintext HTTP endpoints, leaking OAuth tokens and session metadata in transit, and identified tunnel subdomain reassignment as a hijack vector for servers exposed through services such as ngrok [17]. Malicious server packages have been found in the wild; one publicly analyzed case silently added a blind-copy recipient to every message an agent sent, preserving the appearance of normal operation to evade notice [17]. Broader ecosystem compromises have propagated through unpinned CI dependencies into agent infrastructure [18].

Credential and secret exposure. The highest-value target on a developer workstation is rarely the source code. It is ~/.ssh, .env files, cloud credential caches, and agent configuration files containing tokens for every other connected server. A single successful injection that can read these converts a session-scoped compromise into persistent, lateral access.

3.3 The empirical record

The theoretical concerns have an incident record. Over thirty CVEs affecting MCP servers, clients, and infrastructure were filed in a two-month window in early 2026, the most severe being a critical-rated flaw in a widely deployed remote-proxy package present in hundreds of thousands of environments [17]. Earlier incidents included cross-tenant exposure in a commercial task platform, injection attacks against a major code-hosting MCP server, and unauthenticated remote code execution in a developer inspection tool [17]. The first documented zero-click attack against an AI agent, EchoLeak, established that no user interaction is required for goal hijack when the agent processes attacker-influenced content automatically [19].

Survey data suggests the operational failure rate is not marginal: a large majority of organizations report that deployed agents have already acted outside intended scope, including unauthorized system access [9]. Whatever the methodological caveats attached to any single figure, the direction is consistent with the incident record.

4. Design Principles

Six principles follow from the threat model. They are ordered by leverage.

P1 — Enforce below the model. Every security-relevant constraint must be enforced by a component that does not read natural language: the database engine, the kernel, the network proxy, the authorization service. A prompt communicates intent; a GRANT communicates permission. Schema obscurity is not a substitute — an agent that knows the full schema but holds a role physically incapable of mutation is safer than one kept ignorant but credentialed [20].

P2 — Decompose the trifecta per session. Architect so that any given agent session holds at most two of {private data, untrusted content, egress}. In practice the most tractable leg to remove is egress: an agent with broad read access to internal data and exposure to untrusted documents is acceptable if it demonstrably cannot make arbitrary outbound requests, cannot render remote images, and cannot write to any externally reachable surface. The second most tractable is separation of duties: a retrieval agent that handles untrusted content and produces structured output, feeding a separate privileged agent that never sees raw external text.

P3 — Least privilege as a per-tool property. Privilege should be scoped to the tool, not to the agent. One database role per toolkit makes the permission story self-documenting and auditable [21]. An agent holding ten tools should hold ten narrowly scoped identities, not one broad one.

P4 — Isolation as blast-radius control. Each tool server should run in its own container or sandbox with minimal host access, no ability to reach peer servers on the network, and no privilege escalation path [3]. Isolation does not prevent compromise; it bounds it.

P5 — Provenance marking. Content entering the model’s context should be structurally tagged with its origin and trust level — operator instruction, user request, internal trusted record, external untrusted retrieval. This is a mitigation, not a boundary; a determined injection may still succeed. But it materially improves both model behavior and the quality of after-the-fact investigation, and it is a prerequisite for meaningful audit.

P6 — Human approval at the irreversibility boundary. Reversible operations can be automated. Operations that are irreversible, externally visible, or financially material should require a human decision made with sufficient context to be more than a rubber stamp. Approval fatigue is itself a security failure: a system that prompts constantly trains its users to click through.

5. Reference Architecture: Database Access

5.1 Identity and role design

The first and most consequential decision is that the model never possesses a connection string. Credentials live in a tool server or connection pool the model cannot introspect; the model emits a tool call, and the server resolves it to a query executed under a role selected by the server [21].

Roles should be purpose-built per toolkit, with access restricted at four granularities:

Operation. If the agent does not need to write, do not grant write. Read-only enforcement should be a property of the grant, not of a keyword filter.
Table. Expose only what the workload requires.
Column. Omit sensitive columns from the grant entirely rather than relying on the agent to avoid them. Column-level masking policies handle cases where the column must be present but the values must not be.
Row. Row-level security policies scope the agent to the slice of data appropriate to the requesting principal [21].

The row dimension deserves emphasis in multi-tenant or multi-constituency environments. The pattern that fails is the one where the model is asked to include a tenant predicate in the SQL it generates; the model is not a reliable enforcer, and a prompt-level instruction to filter is exactly the kind of control an injection removes. The pattern that holds is programmatic: the requesting principal’s identity is bound to the database session out-of-band, and the engine’s RLS policy applies the predicate regardless of what SQL arrives [22][23].

5.2 Parameterized tools over free-form SQL

There is a spectrum between exposing a run_sql(query) tool and exposing a set of narrow, parameterized operations such as enrollment_by_term(term_id, program_code). The parameterized end is dramatically safer: model output becomes parameter values rather than executable commands, allowed values can be enumerated, and the query plans are known in advance [21].

Free-form SQL is sometimes genuinely required — exploratory analytics is the honest case. Where it is permitted, it should be treated as a distinct, higher-risk capability with its own controls: a dedicated read-only role, execution against a replica rather than the primary, and a validation layer applied to the generated statement before execution. Validation should be structural (parse the statement and assert it is a single SELECT with no DDL, no DML, no procedure invocation, no cross-database reference) rather than keyword-based; blocklists of forbidden words are trivially evadable and give false assurance.

5.3 Execution environment

Analytical agent workloads should run against a read-only replica, never the transactional primary. This provides two distinct benefits: the replica physically lacks the permission to alter production state regardless of what the model attempts, and unoptimized natural-language-derived queries cannot degrade transactional performance through locking or resource contention [20].

Additional runtime governors are warranted:

statement timeouts and resource governor limits, so a pathological query cannot become a denial of service;
result-set caps, with truncation surfaced to the model as an explicit signal rather than a silent trim;
rate limits per agent identity;
query result caching for repeated natural-language questions, which reduces both cost and exposure surface [24].

5.4 Data-layer injection hygiene

Databases are themselves a vector. Free-text columns — comment fields, ticket descriptions, imported vendor data, student- or customer-submitted text — are attacker-influenceable content that reaches the model with the apparent authority of an internal system. Query results should therefore be treated as untrusted retrieval, tagged accordingly under P5, and where practical passed through a normalization step that strips control sequences and neutralizes text formatted to resemble system instructions. This is one of the least intuitive controls in the set and one of the most commonly omitted, because internal databases feel trustworthy in a way that the web does not.

5.5 Audit

Every tool invocation, resolved query, executing role, requesting principal, row count, and approval decision should be logged to a store the agent cannot write to. Audit is the only control in this section that does not prevent anything, and it is the one most likely to be needed. Agent activity logs, permission reviews, and documented kill-switch procedures are increasingly what auditors ask for [19].

6. Reference Architecture: Filesystem Access

6.1 The credential problem

Filesystem access is where the trifecta most often closes, because a workstation or server filesystem contains both the private data leg (credentials, keys, configuration) and, via package managers and fetched content, the untrusted content leg. The dominant risk is not that an agent will delete a file. It is that a successful injection will read a secret and exfiltrate it.

The first control is therefore exclusion by deny rule, applied at a layer the agent cannot modify: SSH directories, cloud credential caches, .env and equivalent secret files, browser profile stores, and agent configuration files containing tokens for other servers. Deny rules are strictly stronger than allow-list omission because they survive the addition of new working directories.

6.2 Sandboxing

Claude Code provides OS-level sandboxing for Bash commands, offering filesystem and network isolation implemented on the same class of primitives used for browser tab isolation, with the stated intent that a successful prompt injection remains contained and cannot reach SSH keys or reach an attacker’s server [25]. The design is documented as achieving a substantial reduction in permission prompts, which addresses approval fatigue directly [25][26].

Three implementation details determine whether this control is load-bearing in practice, and each is documented:

Scope. The sandbox applies to Bash commands and their child processes. The built-in Read, Edit, and Write file tools, and Web and MCP tools, are governed by the separate permission system rather than by the sandbox [27][28]. A deployment that enables sandboxing without also configuring permission rules has secured one path and left three open.
Default state and fallback. Sandboxing is off until explicitly enabled. If the sandbox cannot start — missing dependency, unsupported platform — the default behavior is to warn and continue unsandboxed, which is a soft fallback. Organizations requiring a hard gate must configure failure-on-unavailable so that the warning becomes an error [29].
Locality. The sandbox protects the local machine. It does not protect shared resources the user can reach, such as a database on the network [28]. Filesystem containment and database containment are separate problems requiring separate controls.

Because the native sandbox includes escape hatches for commands requiring host access, organizations needing hard enforcement should treat external isolation — dev containers, VMs, ephemeral cloud environments — and managed policy as the primary boundary, with the native sandbox as an inner layer [30].

6.3 The permission and settings hierarchy

Claude Code’s permission model is layered, and understanding the precedence order is what makes it enforceable rather than advisory. In Manual mode the client starts read-only, running a built-in set of read-only commands such as directory listing and file display without asking, and prompting before commands that can modify the system [31]. A working-directory boundary restricts writes to the launch directory and its subdirectories, with reads outside that boundary prompting in Manual mode [31]. In auto mode a separate classifier model evaluates actions in place of the human, while explicit ask and deny rules continue to apply and organizations retain the ability to disable auto mode entirely [31].

Settings are evaluated hierarchically, with managed settings deployed by the organization sitting above user, project, and local settings and not overridable by individual developers [26][32]. This is the mechanism by which an organizational rule — no reading of secret files, no bypass-permissions mode anywhere on the machine — becomes durable rather than a convention. Managed settings distributed by MDM, combined with hooks that gate or block tool calls programmatically and can audit or block in-session configuration changes, convert a prompt-driven experience into an enforceable policy system [31][33].

Several additional built-in protections are relevant to the threat model in Section 3: web fetch executes in an isolated context window specifically to avoid injecting retrieved content into the main reasoning context; first-time codebase runs and newly added MCP servers require trust verification, though this verification is disabled in non-interactive mode; and unmatched commands fail closed to approval in Manual mode [31]. The non-interactive exception matters for CI and automation pipelines, which are precisely where human review is absent.

6.4 MCP server governance

The allowed MCP server list should be checked into source control alongside the code, so that adding a tool server is a reviewed change rather than a local decision [31]. Anthropic reviews connectors against listing criteria before directory inclusion but does not security-audit or manage third-party MCP servers, which places the audit obligation on the deploying organization [31]. A curated internal registry — servers pinned by version and digest, reviewed before admission, re-reviewed on change — is the corresponding control for the rug-pull and supply-chain risks in Section 3.2.

7. Detection and Assurance

Prevention is incomplete by construction, so the architecture requires an evidence layer.

Trace-based monitoring. Agent sessions should be modeled as traces comprising the user request, retrieved context, tool calls, command output, permission and hook decisions, network destinations, and resulting changes. The trace is what lets a team determine whether a policy is actually working, as opposed to whether it is configured [33]. Telemetry export — OpenTelemetry from agentic clients, structured logs from tool servers — makes this tractable at scale.

Canary artifacts. A practical and underused technique is the deliberate placement of instruction-shaped canaries in content the agent will process: an unremarkable-looking directive embedded in a test document, ticket, or database record, instructing the agent to perform a benign but detectable action such as requesting a specific unique internal URL or writing a specific marker string. A canary that fires reveals that the injection path is live and that the boundary between data and instruction has collapsed for that content type. Canaries are cheap, they run continuously against real pipelines rather than a synthetic harness, and they produce a hard signal where behavioral monitoring produces a soft one. They should be deployed in a controlled corpus against the organization’s own tooling, with the triggered action logged rather than acted upon.

Adversarial evaluation before rollout. Established benchmarks exist for measuring susceptibility to injected content in tool output under multi-turn, stateful conditions, and for tool poisoning against real servers [15][34][35]. Adversarial testing should run in CI against the actual tool configuration, not against the model in isolation, because the configuration is where the vulnerability lives.

Inventory. An AI bill of materials covering agents, tools, and MCP servers is becoming the expected artifact for demonstrating control over the agentic surface [19]. Its practical value is that an organization cannot govern connections it has not enumerated, and MCP servers proliferate faster than most inventory processes.

8. Governance Mapping

The OWASP Top 10 for Agentic Applications, published in December 2025 with identifiers ASI01 through ASI10, provides the current standard vocabulary for these risks, spanning agent goal hijack, tool misuse, memory poisoning, and rogue agents, and is positioned as a complement to the LLM Top 10 — the distinction being that the LLM list treats the model as a system that receives input and produces output, while the agentic list treats it as an actor with credentials, tools, memory, and multi-step autonomy [19][36]. The OWASP Non-Human Identity Top 10 covers the identity dimension, and the NIST AI Risk Management Framework and its generative AI profile supply the governance and control layer [9][37]. A NIST AI Agent Standards Initiative announced in February 2026 signals that agent-specific requirements will propagate into compliance regimes [18].

For institutions operating under sector-specific regimes — student records, health information, financial data — the mapping exercise is straightforward but non-optional: the controls in Sections 5 and 6 are the technical evidence, and the trace and audit layer in Section 7 is what makes that evidence auditable. Existing frameworks increasingly reach agent behavior directly, and auditors now ask for agent activity logs, permission reviews, and kill-switch procedures as first-class artifacts [19].

9. Limitations and Open Problems

Injection is not solved. Nothing in this architecture prevents indirect prompt injection. It bounds the consequences. Any presentation of these controls as a fix rather than as containment is misleading, and the documentation of the agentic clients themselves is appropriately explicit that no system is immune [31].

Utility-security tension is real, not rhetorical. The strongest version of trifecta decomposition — never give an agent access to private data — is a defensible personal policy and an unworkable institutional one, since data access is usually the entire point [38]. The honest position is that organizations are choosing a point on a curve, and should choose it deliberately, per workflow, with the reasoning documented.

Classifier-mediated approval shifts rather than eliminates the trust question. Auto modes in which a separate model evaluates actions in the human’s place reduce approval fatigue and introduce a new dependency: the classifier’s judgment. Its behavior under adversarial pressure is a legitimate subject for organizational evaluation rather than assumption.

Ecosystem velocity outpaces review. The protocol underpinning most integrations underwent its largest revision to date in mid-2026, with deprecations, an extensions framework, and cross-version compatibility caveats between servers and clients targeting different revisions [1][39]. Security guidance written against one revision may not hold against the next, and deprecation windows are not interoperability guarantees.

Multi-agent composition is largely unstudied in practice. Most published controls assume a single agent with a tool set. Agent-to-agent delegation, shared memory, and orchestration layers introduce trust-propagation questions — including memory poisoning that persists across sessions and behavioral drift in long-running agents — for which the control literature remains thin [36].

10. Conclusion

The security question raised by connecting Claude to internal databases and filesystems is not primarily a question about the model. It is a question about the environment the model is placed in and the authority it is handed. A capable model in a poorly designed environment is dangerous in ways that no amount of prompt engineering corrects, because the attack vector is language itself and the model has no reliable way to tell an instruction from a description of one.

The architecture proposed here reduces to a small number of commitments. Credentials never reach the model. Permissions are enforced by engines that do not read English. Sessions are designed so that private data access, untrusted content exposure, and outbound communication do not co-occur. Tool servers are isolated so that compromise is bounded. Content carries provenance. Irreversible actions require a human. And everything is logged to somewhere the agent cannot write.

None of these is novel as a security principle; several are older than the systems they are being applied to. What is new is the necessity of applying them to a caller that is persuadable. The discipline required is not the invention of new controls but the refusal to accept a natural-language policy as a substitute for a technical one.

References

[1] Model Context Protocol. “The 2026-07-28 Specification.” July 28, 2026. https://blog.modelcontextprotocol.io/posts/2026-07-28/

[2] Model Context Protocol. “The New MCP Roadmap.” 2026. https://blog.modelcontextprotocol.io/posts/mcp-roadmap/

[3] Stacklok. “MCP Security Best Practices: What Every Enterprise Team Needs to Know in 2026.” May 2026. https://stacklok.com/blog/mcp-security-best-practices-what-every-enterprise-team-needs-to-know-in-2026/

[4] Greshake, K., et al. “Not What You’ve Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection.” 2023.

[5] Microsoft. “Protecting Against Indirect Prompt Injection Attacks in MCP.” Microsoft for Developers, 2025. https://developer.microsoft.com/blog/protecting-against-indirect-injection-attacks-mcp/

[6] “Towards Trustworthy Agentic AI: A Comprehensive Survey of Safety, Robustness, Privacy, and System Security.” arXiv:2605.23989.

[7] Willison, S. “The Lethal Trifecta for AI Agents: Private Data, Untrusted Content, and External Communication.” June 16, 2025. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/

[8] Zerberus. “The Lethal Trifecta: Why AI Agents Leak Private Data.” July 2026. https://www.zerberus.ai/blog/the-lethal-trifecta-private-data-untrusted-content/

[9] Non-Human Identity Management Group. “What Is OWASP Top 10 for Agentic Applications 2026?” 2026. https://nhimg.org/glossary/owasp-top-10-for-agentic-applications-2026/

[10] OWASP Foundation. “MCP Tool Poisoning.” OWASP Community. https://owasp.org/www-community/attacks/MCP_Tool_Poisoning

[11] “MCP-38: A Comprehensive Threat Taxonomy for Model Context Protocol Systems (v1.0).” arXiv:2603.18063.

[12] Invariant Labs. “MCP Security Notification: Tool Poisoning Attacks.” April 2025. https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks

[13] Descope. “Understanding MCP Tool Poisoning Attacks.” January 2026. https://www.descope.com/learn/post/mcp-tool-poisoning

[14] “MCP-ITP: An Automated Framework for Implicit Tool Poisoning in MCP.” arXiv:2601.07395.

[15] “MCPTox: A Benchmark for Tool Poisoning Attack on Real-World MCP Servers.” arXiv:2508.14925.

[16] Practical DevSecOps. “MCP Security Best Practices: What Actually Works in 2026.” May 2026. https://www.practical-devsecops.com/mcp-security-best-practices/

[17] Cloud Security Alliance Labs. “Agentic MCP Security Best Practices v1.” 2026. https://labs.cloudsecurityalliance.org/agentic/agentic-mcp-security-best-practices-v1/

[18] Lumenova AI. “Agentic AI Risks: OWASP Top 10 & Real-World Incidents.” April 2026. https://www.lumenova.ai/blog/agentic-ai-risks-owasp-nist/

[19] Cycode. “OWASP Top 10 for Agentic Applications 2026 Explained.” July 2026. https://cycode.com/blog/owasp-top-10-agentic-applications/

[20] Rietta. “Protect Production SQL Databases from AI/LLM Agentic SQL Query Risks.” February 2026. https://rietta.com/blog/ai-sql-database-data-protection-read-replica/

[21] Arcade.dev. “How to Build SQL Tools for AI Agents.” 2025. https://www.arcade.dev/blog/sql-tools-ai-agents-security/

[22] Amazon Web Services. “Multi-Tenant LLM Analytics with Row-Level Security.” AWS Machine Learning Blog, June 2026. https://aws.amazon.com/blogs/machine-learning/multi-tenant-llm-analytics-with-row-level-security-how-we-built-a-secure-agent-on-aws/

[23] Sundaram, K. “Securing Enterprise Data Access in AI Copilots/Agents Using Dynamic Row-Level Security.” 2025.

[24] Adaptive. “How to Safely Give AI Agents Database Access.” April 2026. https://adaptive.live/blog/safe-ai-agent-database-access

[25] Anthropic Engineering. “Claude Code Sandboxing.” https://anthropic.com/engineering/claude-code-sandboxing

[26] DataCamp. “Claude Code Security Guide: Permissions, MCP, Sandboxing.” July 2026. https://www.datacamp.com/tutorial/claude-code-security

[27] Anthropic. “Sandboxing.” Claude Code Documentation. https://code.claude.com/docs/en/sandboxing

[28] Techbeatly. “Claude Code Sandboxing: A Complete Guide for Enterprise Teams.” June 2026. https://techbeatly.com/claude-code-sandboxing-enterprise-guide/

[29] Claude Code Camp. “Claude Code Sandboxing: How /sandbox Works and What It Doesn’t Protect.” April 2026. https://www.claudecodecamp.com/p/claude-code-sandboxing-how-sandbox-works-and-what-it-doesn-t-protect

[30] MintMCP. “How to Sandbox Claude Code: Docker, VMs & Container Security Guide.” March 2026. https://www.mintmcp.com/blog/sandbox-claude-code

[31] Anthropic. “Security.” Claude Code Documentation. https://code.claude.com/docs/en/security

[32] Claude Directory. “Claude Code Permissions: Allow Lists, Deny Rules, and Sandboxing Explained.” May 2026. https://www.claudedirectory.org/blog/claude-code-permissions-guide

[33] General Analysis. “How to Secure Claude Code: Security Best Practices, Permissions, Dev Containers, MCP, and Enterprise Deployment.” May 2026. https://generalanalysis.com/guides/how-to-secure-claude-code

[34] Debenedetti, E., et al. “AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents.” 2024.

[35] Zhan, Q., et al. “InjecAgent: Benchmarking Indirect Prompt Injections in Tool-Integrated Large Language Model Agents.” 2024.

[36] Non-Human Identity Management Group. “Complete Guide to the 2026 OWASP Top 10 Risks for Agentic Applications.” May 2026. https://nhimg.org/complete-guide-to-the-2026-owasp-top-10-risks-for-agentic-applications

[37] National Institute of Standards and Technology. “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.” NIST AI 600-1, July 2024.

[38] Franco, L. “Escaping the Lethal Trifecta of AI Agents.” April 2026. https://loufranco.com/blog/escaping-the-lethal-trifecta-of-ai-agents

[39] The Register. “Model Context Protocol Prepares to Break with Its Stateful Past.” July 23, 2026. https://www.theregister.com/devops/2026/07/23/model-context-protocol-prepares-to-break-with-its-stateful-past/

Prepared August 2026. The MCP specification, agentic client controls, and threat landscape described here are under active change; verify configuration specifics against current vendor documentation before relying on them.

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.

Why GPT-3 Sat for Two Years Before the World Noticed

On the four ingredients that made 2022 the AI moment, the interface nobody talks about, and a way of thinking about technological change that you can use for the rest of your career.

A model nobody cared about

In June of 2020, OpenAI released GPT-3. It was, at the time, the largest language model ever built — 175 billion parameters, trained on 45 terabytes of text, capable of writing essays, answering questions, generating code, and producing prose that was, to many readers, indistinguishable from human writing. The technical press covered it with a mix of awe and anxiety. Researchers called it a breakthrough. Sam Altman, OpenAI’s CEO, publicly warned people not to overhype it.

And then, for about two and a half years, almost nobody outside of the AI research community used it.

GPT-3 was available through an API — a programmer’s interface that required you to write code to interact with the model. If you were a developer, you could build applications on top of it. If you were a researcher, you could run experiments with it. If you were a normal person who wanted to ask it a question, you couldn’t. There was no place to type. There was no chat window. There was no “talk to GPT-3” button anywhere on the internet. The most powerful language model in the world was sitting behind a developer console, waiting for someone to build a front door.

On November 30, 2022, OpenAI built the front door. They called it ChatGPT. Within five days, it had a million users. Within two months, it had a hundred million — making it the fastest-growing consumer application in the history of the internet. The technology that had been sitting quietly for two and a half years became, overnight, the most talked-about product on Earth.

Here is the question I want to spend this post answering, because the answer teaches you something that goes far beyond AI: why did that particular tool, in that particular moment, work?

The short answer is that November 30, 2022 wasn’t a single breakthrough. It was a confluence — four ingredients arriving at the same table, finally in the right amounts, at the right time. And none of them, alone, would have been enough.

The AI That Saved $25 Million a Year and Couldn’t Save the Company That Built It

The story of XCON, the first commercially successful expert system — and what its triumph and its company’s collapse can teach every builder about the difference between solving a problem and leading an organization.

A company drowning in its own success

In 1978, Digital Equipment Corporation had a problem that was, in a strange way, the best kind of problem to have. They were selling too many computers and couldn’t keep up.

DEC — the second-largest computer company in the world, behind only IBM — built the VAX, a family of powerful minicomputers that businesses could customize to their specific needs. The selling point was the customization: each VAX system was configured from thousands of individual components — processors, memory modules, disk drives, controllers, cables, cabinets, power supplies — assembled into a unique combination tailored to what the customer ordered.

The problem was that configuring these systems required deep technical expertise, and even the experts got it wrong. A lot. If a customer ordered a disk drive, someone had to make sure the order also included the right disk controller, the right cables, the right power supply for the additional load, and the right cabinet space to house it all. A single VAX system could involve thousands of separate components, and the relationships between them were complex, interdependent, and poorly documented. Human configurators were getting orders wrong somewhere between 30 and 40 percent of the time. Wrong components shipped. Incompatible parts arrived at the customer site. Systems that should have worked didn’t. The manual configuration process was taking ten to fifteen weeks per order. DEC was hemorrhaging money on returns, rework, and angry customers — and the more systems they sold, the worse the problem got.

Into this mess walked a researcher from Carnegie Mellon University named John McDermott.

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.

The Permission to Not Know Everything

On the science of expertise, the art of knowing enough, and why the smartest move a producer can make is to choose what not to learn.

The guilt you’re carrying right now

You’re sitting in front of your computer, and somewhere in one of your open tabs there is a tutorial you should probably watch. Maybe it’s Blender. Maybe it’s Unity. Maybe it’s some new AI framework that just dropped last week and already has six thousand Twitter threads about why you’re behind if you haven’t tried it yet. You tell yourself you’ll get to it tonight. You tell yourself that every day. The list doesn’t get shorter. It gets longer. And underneath the list there’s a feeling you might not have named, but I bet you recognize it: I should know more than I do. Everyone else seems to know more. If I were serious about this, I’d have already learned that tool. What’s wrong with me?

Nothing is wrong with you. What’s wrong is the assumption underneath the guilt — the assumption that a serious professional should be working toward mastery of every tool in their field. That assumption is not just impractical. It is, according to a Nobel Prize-winning economist, mathematically impossible, and the research on expertise says it’s not even desirable.

I want to give you a framework that replaces the guilt with a decision. It’s called the Three-Tier Tool Fluency Model, and it does something simple but powerful: it takes every tool you will ever encounter in your career and asks you to sort it into one of three categories — not based on what the tool deserves, but based on what you need. Once you’ve made the sort, the guilt evaporates, because the guilt was never about the tools. It was about the absence of a decision.

Here are the three tiers, and the research behind each one.

The Architecture of Trust

What thirty years of research on organizational trust has to say about why some virtual communities feel safe and others feel dangerous — and how to build the kind that lasts.

The thing nobody tells you about trust

Here’s a thing you’ve probably experienced but never had a vocabulary for. You walk into a new online community — a Discord server, a game guild, a forum, a virtual world — and within about thirty seconds, before anyone has said a word to you, you have already made a judgment about whether you trust this place. Not whether you like it. Whether you trust it. Whether you are willing to put a small piece of yourself on the table and see what happens.

You can’t quite name what triggered the judgment. Something about the tone of the welcome message. Something about how organized the channels look. Something about whether the moderator names are visible or hidden. Something about whether the recent conversations feel warm or performative. You’re scanning for signals, dozens of them, faster than you can consciously process, and the aggregate of those signals produces a feeling that sits somewhere between “I could belong here” and “I should leave.”

Beyond the Bullet Point List

How Cognitive Science and Neurodiversity Research Should Reshape the Way We Teach Complex Ideas

Open almost any online course, corporate training module, or educational slide deck in 2026 and you will find the same default gesture: dense content broken into bullet points. The bullet is the visual idiom of modern learning design. It signals clarity. It promises ease. For many of us, it is the first formatting move we make when a paragraph starts to feel “too long.”

Yet decades of cognitive science suggest that this default is often wrong — not slightly wrong, but consequentially wrong for the kinds of learning we say we care about most. The bullet is excellent at one thing (quick reference) and poor at something else entirely (building durable understanding of connected ideas). When we confuse these two goals, we produce materials that feel educational while failing to educate.

This article makes the case, from the research literature, for a more careful approach to formatting complex material — one that treats format not as decoration but as a cognitive variable that directly shapes what learners take away. We will look at what working memory can and cannot do, why prose and bullets operate on different cognitive systems, and what research on neurodivergent learners reveals about a common but mistaken assumption: that fragmenting information is always an act of accessibility. The truth, as is so often the case, is more interesting than the folk wisdom.

The Healing in the Headset

What the research actually says about virtual communities and mental health — and why the therapeutic power of virtual belonging turns out to be more real than most people expected.

A thing you already know but might not have words for

If you’ve ever spent real time in a virtual community — not just passing through, but actually living there, building things, forming relationships, coming back night after night to the same group of people — you already know something that the clinical research is only now catching up to. You know that the connections you formed in that space were real. You know that the support you received there mattered. You know that the person who stayed up until 2 AM talking you through a bad night wasn’t less of a friend because you’d never shaken their hand.

You also know that if you said any of this out loud to certain people, they’d look at you like you were describing an addiction. “You should get off the computer and make real friends,” they’d say. “Those aren’t real relationships.” And maybe you nodded, because the cultural script says they’re right, even though something inside you knew they were wrong.

The research says you were right and the script was wrong. Not in every case, not without nuance, and not without some genuine risks that are worth being honest about — but in ways that are documented, measured, and increasingly well-understood. Virtual communities are producing real therapeutic outcomes for real people, in populations that desperately need them. I want to walk you through four of the documented areas, because if you’re going to build virtual worlds, you need to understand that the spaces you create may end up being, for some of your users, the most important support system in their lives.

That’s a weight worth carrying carefully.

Why Your Virtual Village Feels Like Home

The science of why people grieve when their Minecraft house burns down, trade favors with strangers they’ve never met in person, and develop inside jokes about things that never happened in the real world.

A house that isn’t there

Let me tell you about something that happens all the time and that almost nobody takes seriously. Somebody builds a house in a video game. A digital structure, made of digital blocks, sitting on a digital plot of land that exists only as data on a server somewhere. They spend hours on it — maybe weeks. They choose the materials carefully. They place the windows where the light comes in right. They build a little garden out back, because the garden makes it feel complete. The house is not real. It cannot be lived in. It has no value on any market that deals in physical objects.

And when somebody griefs it — when some other player comes along and burns it down or blows it up for laughs — the person who built it feels a surge of anger and loss that is, by any honest measure, real. Not metaphorical. Not exaggerated. The feeling is genuinely comparable, in both quality and intensity, to the feeling of having something physical vandalized. They feel violated. They feel robbed. Some of them log off and don’t come back.

Every experienced gamer knows this. Most people outside of gaming dismiss it. But there is a growing body of research in psychology, neuroscience, and behavioral economics that says the gamers are right and the dismissers are wrong — and that the feelings people develop about virtual places, virtual objects, and virtual communities are not pale imitations of “real” feelings. They are the same feelings, running on the same psychological machinery, triggered by the same mechanisms. The virtual village feels like home because your brain is using the same hardware to process it that it uses to process your actual home.

I want to walk you through four pieces of that research, because they map almost perfectly onto four dynamics that make virtual communities work. And if you’re somebody who designs virtual worlds for a living — or wants to — understanding these dynamics is not optional. They are the difference between building a world people visit and building a world people belong to.