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.