development 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.

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.

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.

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.

The Four Pillars of a Mind

A scholarly look at why memory, personality, emotional intelligence, and motivation are the four things that make a character — or a person — feel real. And what cognitive science has to say about each of them.

The tavern keeper problem

Picture two tavern keepers. Both are characters in a game you’re playing, or in a novel you’re reading, or in an immersive world you’ve been invited to spend time in. Both pour you a drink, both take your coin, both say hello when you walk in.

The first one does nothing else. Every time you walk into the tavern, she gives you the same greeting. She doesn’t remember you. She doesn’t react to whether you saved her village last week or betrayed it. She has no opinions about the weather, no complaints about her back, no idea that the barrel of ale in the corner is cursed. She is, functionally, a vending machine for drinks wearing a person-shaped costume.

The second tavern keeper is also a character. Also pours drinks, also takes coin, also says hello. But she remembers that you helped her daughter recover from the fever six months ago, and her greeting is warmer because of it. She’s naturally cautious — when you ask about the cursed barrel, she weighs the question for a moment before answering, the way a cautious person would. She notices that you look tired tonight and pours you something a little stronger without being asked. And she wants something for herself, too, underneath all of this — she’s been saving up to buy out her brother-in-law’s share of the tavern, because she thinks she could run it better alone, and that ambition colors everything she does.

You know which tavern keeper is the memorable one. You also know which one is more expensive and time-consuming to build, whether you’re writing her as a novelist, scripting her as a game designer, or configuring her as an AI system. The question I want to walk through in this post is why. Why does the second one feel like a person and the first one doesn’t? What are the specific ingredients that have to be present for a character to cross the line from puppet into presence?

The answer, it turns out, is that there are exactly four of them. And they are not a designer’s preference. They correspond to four dimensions that cognitive scientists have been studying in humans for the last fifty years — four specific things the human mind uses to recognize another mind as being real. When you design a character who has all four, you’re not faking personhood. You are activating the parts of your audience’s brain that are already wired to respond to personhood, and those parts don’t care whether what’s in front of them is digital, printed, or physical.

I call these the Four Pillars. Let me walk you through each one, and the research that makes each of them load-bearing.

From Cute Little Helper to Civilizational Threat

How the public’s feelings about artificial intelligence changed more in five years than in the previous fifty — and why the next five years are ours to shape.

Remember when AI was adorable?

I want you to go back in your head to about 2015. If you had an Amazon Echo in your kitchen, you probably thought of Alexa as a friendly little helper. You said “Alexa, what’s the weather” and she told you. You said “Alexa, play some jazz” and she did. When she misheard you — which was often — it was funny, not threatening. She was, in the cultural imagination of the mid-2010s, a charming household appliance. Something between a toaster and a butler. Nobody thought Alexa was going to take over the world.

Always On

On what we already know about minds that never look away — and what it might mean to wear the screen on your face.

A different kind of question

The first three posts in this series were about things we can measure. Eye strain, with tens of thousands of subjects across decades of optometry research. Inattentional blindness, with controlled studies in driving simulators and flight cockpits. Pedestrian deaths, with police accident reports and peer-reviewed papers. All of that is real. All of that is solid ground.

This last post is going to walk us off the solid ground a little, and I want to be honest about that up front. The question of what happens when augmented reality moves from a thing you sometimes use to a thing you always wear is, as of this writing, an open question. The glasses are not yet ubiquitous. The contact lenses don’t exist yet. The data set we’d need to answer the big version of the question hasn’t been collected, because the experiment hasn’t been run on a big enough population for long enough.

So I’m not going to make predictions. I’m not going to tell you what AR glasses are going to do to society in 2035. I have no idea, and anybody who tells you they do is selling you something. What I’m going to do instead is something a little sneakier and a lot more honest: I’m going to walk you through what we already know about what phones have done to human attention, memory, and presence — because phones are basically AR glasses that haven’t quite made it onto your face yet, and the research on phones is a lot further along than the research on glasses. Then I’ll let you do the math.

The Pokémon Go Body Count

What happens when an augmented reality layer forgets you still have a body in the real world — and what the first big real-world dataset has to teach the next generation of builders.

The summer the world went outside

In July of 2016, something happened that the technology industry had been predicting for about twenty years and had nonetheless completely failed to prepare for. A small company called Niantic released a free mobile game called Pokémon Go, which used your phone’s camera and GPS to overlay little cartoon monsters onto the real world. To catch them, you had to physically walk to where they were. To battle in a “gym,” you had to physically stand near the gym’s real-world location. The game’s slogan was Gotta Catch ‘Em All, and within a few weeks, what felt like half of the developed world was outside trying.

If you were old enough to remember it, you remember the surreal sight of grown adults wandering through public parks at midnight in groups of twenty, their faces lit up by phone screens, occasionally letting out a cheer when somebody caught a rare one. People who had not voluntarily been outside in years were suddenly logging miles on foot. Cardiologists wrote excited articles about it. Public health researchers ran studies on the activity benefits. For a brief shining moment, it looked like augmented reality might single-handedly solve the obesity crisis.

And then the other dataset started coming in.

The Gorilla You Didn’t See

On attention, AR, and the strange truth that more information in your field of view often means less awareness of the world.

A famous experiment, in case you haven’t seen it

Sometime around 1999, two psychologists named Daniel Simons and Christopher Chabris ran an experiment that has since become one of the most famous demonstrations in cognitive science. They filmed a short video of six people in a room passing two basketballs back and forth — three players in white shirts, three in black. They asked viewers a simple question: count how many times the players in white shirts pass the ball.

Most people watch the video carefully, count the passes, and report a number — usually correct. Then the experimenters ask: did you see the gorilla?

The viewers stare at them. What gorilla?

They play the video again. About thirty seconds in, a person in a full gorilla suit walks into the middle of the frame, stops, faces the camera, beats their chest, and walks off the other side. The gorilla is on screen for a full nine seconds. It is not subtle. It is not hidden. It is, by any normal measure, the most interesting thing in the video.

And about half of all viewers, on the first watch, do not see it at all.

This effect has a name. It’s called inattentional blindness, and once you know about it, it changes how you think about pretty much every visual interface you’ve ever used. Including, very specifically, augmented reality.