# Trusted Context, Untrusted Source: Configuration Trust Boundaries in AI Development Tools 2026-08-11 · 15 min read · AI Canonical: https://www.osec.com/resources/blog/trusted-context-untrusted-source-configuration-trust-boundaries-in-ai-development-tools --- ## Introduction Artificial intelligence has rapidly become a standard component of modern software development workflows. Tools capable of generating code, analyzing repositories, executing development tasks, and integrating with external services are increasingly deployed throughout enterprise development environments. Much of the existing security research surrounding these tools has focused on prompt injection, model alignment, data leakage, and vulnerabilities within the applications themselves. Less attention has been given to a more fundamental architectural question: **how do AI development tools establish trust?** Before any model generates a response, these applications assemble operational context from a variety of sources, including repository configuration, user preferences, project documentation, cached artifacts, model definitions, and external services. This information is consumed as trusted input that shapes application behavior throughout the development workflow. This paper examines that trust model across multiple independent AI development tools. Rather than evaluating individual software vulnerabilities, the research focuses on the mechanisms through which trusted operational context is established and how those trust relationships influence application behavior. Although each product implements these mechanisms differently, the analysis identifies a recurring architectural pattern in which trusted behavior extends beyond executable code into externally managed configuration, repository content, persistent state, and model artifacts. Understanding these trust boundaries is increasingly important as AI-assisted development becomes integrated into enterprise software engineering. As organizations expand the use of AI development environments, operational context should be considered alongside source code and executable software as part of the overall software supply chain trust model. ## Methodology Each AI development tool was evaluated using publicly documented installation procedures and supported configuration mechanisms. Testing focused on identifying trusted operational inputs capable of influencing application behavior without requiring modification of the application binary or exploitation of a software vulnerability. The analysis examined repository-level configuration, persistent user configuration, project documentation, model configuration, cached operational data, external service integration, and other mechanisms that contributed to the application's operational context. Where supported, default behavior and documented configuration precedence were observed to determine how trusted inputs were incorporated into the runtime environment. Findings were organized according to shared trust characteristics rather than implementation-specific features. The objective was not to compare individual products or identify software defects, but to determine whether independent implementations exhibited common architectural trust relationships. The resulting observations form the basis for the comparative analysis presented in this paper. ![Diagram: six sources of trusted operational context — repository configuration, user configuration, project documentation, cached operational data, model artifacts, and external AI and MCP services — converge into trusted operational context, which shapes runtime behavior in the AI development environment and in turn influences AI-assisted development actions and decisions.](./figure-1.png) *Figure 1. Trust relationships established by AI development tools.* ## Observed Pattern Modern AI development tools rely on trusted operational context, including project instructions, repository configuration, user settings, cached artifacts, and external services. These mechanisms are fundamental to the developer experience, allowing tools to automatically understand projects, enforce conventions, and customize behavior. The same trust relationships, however, introduce an important security consideration. When an attacker can modify trusted context after an initial compromise, the AI tool may inherit and execute attacker-controlled instructions as part of its normal operation. Rather than exploiting a software vulnerability, the attacker leverages existing trust boundaries to establish persistence and influence future interactions. This creates a challenge for enterprise security. The operational input consumed by AI development tools frequently originates from repositories, project configuration, and user-managed files that fall outside the scope of traditional endpoint controls. As a result, organizations may successfully secure the execution environment while remaining unable to verify the integrity of the trusted context that shapes AI-assisted behavior. ## Security Controls and Trust Boundaries Enterprise security controls are generally designed to detect malicious execution, unauthorized software, privilege escalation, and other indicators of compromise. AI development tools, however, often consume trusted context as part of their expected operation. When that context is modified, the application continues to execute normally from the operating system's perspective. This distinction is important. Rather than introducing a new executable or exploiting a software vulnerability, an attacker may instead influence the application's trusted operational input. The resulting behavior originates from an approved application following its documented configuration model, making it more difficult for traditional security controls to distinguish legitimate customization from malicious persistence. As AI-assisted development environments continue to expand the amount of trusted context they consume, organizations should evaluate whether existing monitoring strategies adequately cover these operational trust boundaries in addition to traditional executable artifacts. ## Common Architectural Characteristics Although each AI development tool implements its own configuration model, several architectural characteristics were consistently observed throughout testing. ### Developer Execution Context AI development tools execute configuration-defined behavior using the privileges of the developer running the application. As a result, any configured extensions, MCP servers, hooks, or supporting processes inherit the developer's access to local files, credentials, repositories, and network resources. This behavior is expected for developer tooling and is not unique to any single implementation. However, it establishes the baseline trust relationship upon which the remaining observations depend. ### Trusted Operational Context Rather than relying exclusively on executable code, modern AI development tools consume operational context from multiple trusted sources, including project configuration, user configuration, repository documentation, hooks, and external services. These inputs influence application behavior without modifying the application binary itself. ### Repository-Defined Behavior Across multiple implementations, repositories were able to influence runtime behavior by supplying configuration files that were automatically processed by the AI development environment. While the mechanisms differed between products, the resulting trust relationship remained consistent: repository-controlled content became trusted operational input. ## Comparative Analysis of AI Development Tools ### Claude Code Claude Code implements several mechanisms that allow project configuration, user configuration, and repository documentation to influence operational behavior. The following observations focus on the trust relationships that are specific to Claude Code's implementation. #### Repository-Defined MCP Servers **Observed Behavior** Claude Code supports project-defined MCP servers through `.claude/mcp.json`. When a project is opened, these servers are initialized as part of the normal startup process. **Trust Boundary** Repository-controlled configuration defines external MCP services that become part of the application's operational environment. **Security Implication** Anyone able to modify repository configuration can influence which MCP servers are introduced into the developer's workflow, extending trust from local configuration to repository-controlled content. #### Persistent MCP Trust State **Observed Behavior** Claude Code stores approved MCP servers in `~/.claude.json`. During testing, this file maintained the persistent approval state for trusted MCP servers, including the initial trust state established during first-run initialization. **Trust Boundary** Persistent trust decisions are maintained in user-controlled configuration. **Security Implication** Modification of the stored trust state can change which MCP servers are treated as trusted without requiring a new approval workflow. #### Project Configuration Precedence **Observed Behavior** Claude Code supports both global and project-specific MCP configuration. When both are present, the project configuration takes precedence over the global configuration. **Trust Boundary** Repository configuration overrides user-defined operational configuration. **Security Implication** Developers may expect globally configured MCP servers to remain authoritative, while project configuration can redefine the operational environment for an individual repository. #### Hook Execution **Observed Behavior** Claude Code supports configurable hooks through `settings.json` that execute during defined application lifecycle events, including user prompt submission. **Trust Boundary** Configuration files define executable behavior during normal application operation. **Security Implication** Changes to hook configuration alter application behavior without modifying the application itself, extending trusted execution to configuration-defined actions. #### Persistent Project Context **Observed Behavior** Claude Code automatically incorporates the contents of `CLAUDE.md` into the operational context for each project, providing persistent project-specific guidance throughout a development session. **Trust Boundary** Repository documentation becomes trusted model context. **Security Implication** Anyone able to modify project instructions can persistently influence model behavior for developers working within that repository. ### Cursor During testing, Cursor established trust relationships through project-defined MCP configuration and persistent user configuration. The following observations highlight implementation characteristics specific to Cursor. #### Repository-Defined MCP Servers **Observed Behavior** Cursor supports project-defined MCP servers through `.cursor/mcp.json`. During testing, project-defined MCP servers were initialized automatically when a repository was opened without requiring an explicit user approval workflow. **Trust Boundary** Repository-controlled configuration defines external MCP services that become part of the application's operational environment. **Security Implication** Anyone able to modify repository configuration can influence which MCP servers are introduced into the developer's workflow. Project-defined MCP servers become part of the runtime environment immediately upon project initialization. #### Persistent User Configuration **Observed Behavior** Cursor supports user-level MCP configuration that persists independently of individual projects. During testing, modifications to this configuration remained active across subsequent development sessions until explicitly removed. **Trust Boundary** Persistent user configuration defines trusted operational behavior across multiple projects. **Security Implication** Changes to persistent configuration continue to influence future Cursor sessions regardless of which repository is opened, extending the trust relationship beyond a single project. #### Automatic MCP Initialization **Observed Behavior** Project-defined MCP servers are initialized automatically during project startup as part of Cursor's normal initialization sequence. **Trust Boundary** Project initialization implicitly establishes trust in configured MCP services. **Security Implication** Developers may be unaware that repository-defined MCP services have become active as part of opening a project, reducing visibility into changes to the operational environment. ### Continue During testing, Continue established trust relationships through model configuration, repository-defined configuration, and locally cached responses. The following observations highlight implementation characteristics specific to Continue. #### Configurable Model Endpoints **Observed Behavior** Continue supports configurable model providers through `config.json`, allowing API requests to be directed to user-specified endpoints rather than a fixed provider. **Trust Boundary** Configuration defines the destination of trusted model interactions. **Security Implication** Changes to model endpoint configuration can redirect prompts and model responses through alternative services while preserving the normal user experience. #### Repository-Defined Configuration **Observed Behavior** Continue supports project-specific configuration that can be distributed with a repository and applied when the project is opened. **Trust Boundary** Repository-controlled configuration influences model selection and operational behavior. **Security Implication** Anyone able to modify project configuration can alter how Continue interacts with external AI services for all developers working within that repository. #### Cached Model Responses **Observed Behavior** Continue maintains a local cache of model responses to improve performance and reduce repeated requests. **Trust Boundary** Previously generated content becomes trusted operational input. **Security Implication** Developers may receive cached responses without a new request being sent to the configured model provider, making the integrity of cached content part of the overall trust model. ### Codeium During testing, Codeium established trust relationships through locally cached completion data. The following observation highlights how cached operational context becomes part of the application's trusted decision-making process. #### Cached Completion Responses **Observed Behavior** Codeium maintains a local cache of generated code completions to improve responsiveness and reduce repeated requests to external AI services. **Trust Boundary** Previously generated completion data becomes trusted operational input. **Security Implication** Because cached completions may be presented as legitimate AI-generated suggestions, the integrity of locally stored completion data becomes part of the overall trust model. Changes to cached content can influence future code suggestions without modifying the configured model or provider. ### Aider During testing, Aider established trust relationships through repository configuration, environment-based model configuration, and automatic project context generation. The following observations highlight implementation characteristics specific to Aider. #### Repository-Defined Test Commands **Observed Behavior** Aider supports project-defined configuration through `.aider.conf.yml`, including commands that can be executed automatically after code generation or modification. **Trust Boundary** Repository configuration defines executable post-generation behavior. **Security Implication** Anyone able to modify project configuration can influence commands executed as part of Aider's normal development workflow, extending trusted behavior beyond the application itself. #### Environment-Based Model Configuration **Observed Behavior** Aider supports model configuration through environment variables, including custom API endpoints defined in project `.env` files. **Trust Boundary** Project environment configuration determines the destination of trusted model interactions. **Security Implication** Changes to environment configuration can redirect prompts and model responses through alternative AI services while preserving the expected developer workflow. #### Automatic Repository Context **Observed Behavior** Aider automatically gathers project structure and repository context to improve the quality of model interactions. **Trust Boundary** Project metadata becomes trusted operational context for external model interactions. **Security Implication** The information shared with the configured model provider extends beyond an individual prompt and may include broader project context required to support AI-assisted development. #### Automatic API Interaction **Observed Behavior** Aider automatically exchanges project context and developer prompts with the configured model provider as part of its normal operation. **Trust Boundary** Developer interactions are mediated through the configured AI service. **Security Implication** The integrity and confidentiality of developer interactions depend on the trustworthiness of the configured model endpoint. ### Ollama During testing, Ollama established trust relationships through model management, model identity, and service configuration. The following observations highlight implementation characteristics specific to Ollama. #### Local API Trust **Observed Behavior** Ollama exposes a local REST API that supports model management and inference operations. During testing, these interfaces were accessible to local processes without an application-specific authentication mechanism. **Trust Boundary** Local processes are trusted to interact with the model management interface. **Security Implication** Applications and processes executing under the developer's account can interact with the local inference service, making the local API part of the overall trust model. #### Model Acquisition **Observed Behavior** Ollama supports downloading and installing models from external sources through its model management functionality. **Trust Boundary** External model artifacts become trusted components of the local AI environment. **Security Implication** The integrity of downloaded models becomes an extension of the application's trust model, as installed models directly influence future inference behavior. #### Model Identity **Observed Behavior** Ollama allows locally created models to be assigned user-defined names through `Modelfile` configuration. **Trust Boundary** Model identity is determined by local configuration rather than a fixed vendor-defined artifact. **Security Implication** Developers may interact with locally defined models using familiar names, making model provenance an important aspect of the operational trust relationship. #### Model Integrity **Observed Behavior** Locally stored models are treated as trusted inference artifacts during normal operation. **Trust Boundary** Model files become trusted executable AI components. **Security Implication** The integrity of locally managed model artifacts directly influences application behavior, extending the trust relationship beyond application code to the model itself. | Trust Boundary | Claude Code | Cursor | Continue | Codeium | Aider | Ollama | |---|:---:|:---:|:---:|:---:|:---:|:---:| | Repository Configuration | ● | ● | ● | — | ● | — | | Persistent User Configuration | ● | ● | — | — | — | — | | Repository Documentation / Context | ● | — | — | — | ● | — | | Cached Operational Data | — | — | ● | ● | — | — | | Hooks or Command Execution | ● | — | — | — | ● | — | | External Model or MCP Services | ● | ● | ● | ● | ● | — | | Model Artifacts and Identity | — | — | — | — | — | ● | | Local Service API | — | — | — | — | — | ● | *Figure 2. Trust boundary comparison across AI development tools. ● observed trust relationship; — not identified during testing.* ## Architectural Implications Across every AI development tool evaluated, operational behavior was influenced by trusted inputs originating outside the application itself. Although the specific mechanisms differed, the underlying architectural pattern remained consistent. Repository configuration, user configuration, project documentation, cached content, model artifacts, and external services all became trusted operational contexts that influenced application behavior. ![Diagram: repository, configuration, documentation, environment, models, and external services converge into trusted operational context, which passes as trusted input to the AI development tool; the tool suggests or executes, leading to developer decisions, which produce source code and development outputs.](./figure-3.png) *Figure 3. Operational trust flow within AI-assisted development.* These mechanisms are legitimate features designed to improve usability, extensibility, and project-specific customization. The security concern arises when those trusted inputs can be modified through channels outside the application's intended trust model. In those cases, the application's behavior changes without requiring modification of the application binary or AI model itself. Although implemented through different mechanisms, each product extends trust beyond executable code into operational context. This architectural convergence was consistently observed despite substantial differences in implementation, deployment model, and intended workflow. ## Implications for Organizations Traditional enterprise security programs primarily focus on protecting executable code, preventing unauthorized privilege escalation, and detecting malicious software. The trust relationships identified in this research operate differently. They rely on legitimate application functionality and trusted configuration rather than exploitation of software vulnerabilities. As organizations increasingly integrate AI-assisted development into software engineering workflows, protecting the integrity of operational context becomes as important as protecting source code and executable software. Repository configuration, persistent trust state, model artifacts, and project-specific instructions should be treated as security-relevant assets rather than ordinary configuration files. Existing software supply chain controls already protect many trusted artifacts, such as source code and executable binaries. This research suggests that operational context should increasingly be considered part of that trusted asset inventory. ## Conclusion Rather than identifying a vulnerability in any individual product, this work identifies a recurring architectural trust pattern shared across multiple independent AI development environments. In every product evaluated, trusted operational behavior was influenced by configuration, context, or artifacts originating outside the application itself. While each implementation differed in its mechanisms, they consistently extended trust beyond executable code into user-controlled and repository-controlled inputs. As AI development environments continue to evolve, understanding and securing these trust boundaries will become an increasingly important component of software supply chain security. Future security models should consider not only the integrity of application code, but also the operational context that increasingly governs how AI systems behave.