Local Agent Tooling Source Map

​

Summary

This note gathers official source inputs for contributors writing about local agent systems: agents that work near a user’s files, tools, project state, and workflow instructions rather than operating only as a remote chat surface. Use it when a draft needs to explain what “local” actually means. The durable pattern is not the location of one model. It is the combination of:

• an execution environment or local tool boundary
• reusable skill or workflow packaging
• explicit filesystem or document scope
• resources that can be selected, searched, read, or refreshed
• permission rules that make the boundary understandable to users

​

How To Use This Note

This is a source map, not a full article. Future contributors should use it to:

• define the boundary before describing the agent
• choose the right source for the claim they are making
• keep local files, selected resources, skills, and connectors separate
• add case-study examples that show what the agent may read, write, and review

​

Why It Matters

Local-agent topics are becoming easy to overstate. A useful handbook treatment should separate several concerns that are often mixed together:

• runtime: where commands, scripts, files, or containers run
• skills: how reusable task knowledge is packaged
• roots: which local filesystem areas a tool-facing server may see
• resources: which files, schemas, records, or application objects can be exposed as model context
• connectors: how local and remote services become callable tools

That split helps contributors write case studies and starter projects without pretending that every integration is the same kind of agent capability.

​

Scope Notes

Included:

• official OpenAI source material on Responses API tools, file search, remote MCP support, and computer environments
• official OpenAI, Microsoft, Claude Code, and MCP security guidance on indirect prompt injection, sandboxing, scope minimization, and trust boundaries for local agents
• official MCP material on roots and resources
• official Claude Code material on local stdio servers, project/user scopes, and MCP resources

Excluded:

• third-party MCP server listings
• unofficial prompt-injection commentary
• vendor comparisons that do not change the handbook’s local-agent mental model
• implementation details for a production email or CRM integration

​

Source Map

• OpenAI Responses API tools and remote MCP support: use this for claims about hosted tools, remote MCP support, file search, and long-running background work.
• OpenAI computer environment for agents: use this for claims about execution environments, persistent files, shell access, compaction, and agent skills as runtime support.
• Understanding prompt injections: use this when the draft needs OpenAI’s current plain-language framing for third-party instructions, layered defenses, sandboxing, and user confirmations around agent actions.
• Defend against indirect prompt injection attacks: use this for a current enterprise defense stack that names prompt shields, spotlighting, plan-drift detection, critic agents, tool-chain analysis, information-flow control, and least privilege.
• MCP introduction: use this for a stable, high-level explanation of MCP as a connection layer between AI applications and external systems.
• MCP roots: use this when the draft needs to explain local filesystem boundaries.
• MCP resources: use this when the draft needs to explain application-controlled context surfaces such as files, schemas, or application-specific objects.
• Claude Code MCP documentation: use this as a practical example of local stdio servers, project-scoped MCP configuration, plugin-provided servers, and resources in a coding-agent workflow.
• Claude Code security: use this for permission checks, trust verification for MCP servers, and practical guidance for working with untrusted content.
• Claude Code sandboxing: use this for claims about filesystem and network isolation that limit damage if prompt injection succeeds.
• MCP security best practices: use this when the draft needs concrete language for local MCP server compromise, one-click startup-command consent, scope minimization, and why stdio or authenticated transports matter.
• modelcontextprotocol/modelcontextprotocol: use this as the high-signal implementation and specification repo for checking current MCP adoption, issue flow, and security-surface maintenance.
• microsoft/BIPIA: use this as a benchmark-oriented repo when the draft needs a concrete example of evaluating indirect prompt-injection robustness.
• promptfoo/promptfoo: use this as a high-signal implementation repo for red-teaming and CI-level prompt-injection checks around agents, tools, and RAG systems.

​

Synthesis

The strongest local-agent spine is a layered one:

1. The user or host application chooses an operating boundary.
2. Tools and servers expose capabilities inside that boundary.
3. Resources and roots describe which context can be read or selected.
4. Skills package repeatable task knowledge.
5. The agent produces an artifact or action that can be reviewed.

For handbook purposes, this is more useful than saying “the agent has access to files.” Local access should always be explained with the boundary attached: which files, which server, which transport, which permission, and which artifact. The same discipline applies to skills and connectors. A skill can tell the agent how to perform a task, but it should not be treated as current evidence. A connector can expose a useful system, but it should not imply permission to read or act on every object in that system.

​

Production-Readiness Note

The current seven-day signal around prompt injection is a reminder that local agents should be described as authority systems, not just capability systems. The practical question is not only “what can the agent read?” It is “what authority travels with that input once the agent can call tools, touch files, or send data elsewhere?”

• Treat retrieved files, web pages, emails, and connector output as untrusted content unless a reviewed policy says otherwise.
• Separate source from sink: untrusted content may inform the agent, but sensitive tool calls, credential use, and outbound transmissions should stay behind extra approval, sandboxing, or both.
• Verify every MCP server before connecting it. Prefer explicit scope choice, exact startup-command review, and stdio or authenticated transports for local servers.
• Keep human confirmation in the write path for consequential actions such as sending messages, changing tickets, or moving data to third-party systems.
• Add prompt-injection and tool-misuse checks to eval or red-team workflows before calling a local-agent setup production-ready.

​

Authority Boundary Matrix

The source map is easier to apply when contributors compare local-agent surfaces side by side instead of treating them all as “tool access.”

​

Where To Deepen This In The Handbook

• Reference Notes: keep the source-map and contributor-briefing layer clear before drafting durable handbook pages.
• Protocols and Interoperability: use this when the draft needs the MCP, A2A, and remote-boundary comparison.
• Agent UI Protocols and Generative UI: use this when the draft needs to separate tool permissions from UI state.
• Weather MCP Server Starter: use this as the repo-native example surface for explaining MCP boundaries in runnable form.
• April 2026 Assistant Safety Escalation Watch: use this when a draft needs to connect local authority boundaries to human escalation and audit paths.
• GitHub Issue Guide: use this when the note turns into a scoped contribution proposal or issue claim.

​

Case-Study Hooks

Good local-agent case studies should make the boundary visible:

• customer-support email agent: inbound message path plus local policy document path
• coding agent: repository root plus issue, test, and branch permissions
• operations agent: dashboard or database resource plus read-only query rules
• research agent: source folder plus citation artifact output

Each case should state what the agent may read, what it may write, and what requires human review.

​

Gaps And Follow-up

• Expand the customer-support case study once the starter code includes a real mailbox or Gmail adapter.
• Add a future starter or case-study note showing how source-aware authority enforcement or prompt-injection red-teaming fits into a local-agent workflow.
• Add a narrow walkthrough for turning indirect prompt-injection findings into repo-native eval checks or contribution-ready issue templates.

​

Update Log

• 2026-05-27: Replaced the older prompt-injection source with current OpenAI and Microsoft guidance, added an authority-boundary matrix, and linked the note to related handbook surfaces.
• 2026-05-17: Added prompt-injection, sandboxing, trust-boundary, and red-teaming guidance to the local-agent source map.
• 2026-04-24: Refined the note for contributor comprehension with usage guidance, term boundaries, and clearer source-to-claim mapping.
• 2026-04-23: Added a contributor-facing source map for local agent tooling, skills, roots, resources, and file-grounded workflows.