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:

• a discovery path for finding relevant capabilities
• 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:

• decide whether the draft is about discovery, connection, or execution
• 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:

• discovery: how an agent finds a relevant capability at runtime
• 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 ARD material on catalogs, registries, and trust metadata
• official OpenAI source material on Responses API tools, file search, remote MCP support, and computer environments
• current OpenAI documentation for approval-gated connectors and remote MCP servers
• 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

• Hugging Face: Agentic Resource Discovery - Let agents search: use this for the current discovery-layer framing, why install-first agent wiring does not scale, and how registries let agents search for relevant capabilities at runtime.
• Google Developers: Announcing the Agentic Resource Discovery specification: use this for the cleanest explanation of catalogs, registries, trust metadata, and the handoff from discovery into a capability’s native protocol.
• Microsoft: Introducing the Agentic Resource Discovery specification: use this when the draft needs a practical problem statement for why manual capability wiring breaks down as more agentic resources are published.
• 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 MCP and Connectors guide: use this when the draft needs approval rules, remote-server transport details, tool-list caching, or the practical boundary between trusted connectors and third-party MCP servers.
• 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.
• ards-project/ard-spec: use this as the canonical draft specification repo for ARD schemas, conformance artifacts, and trust-model wording.
• huggingface/hf-discover: use this as a concrete ARD client/server implementation that searches skills, spaces, and MCP servers.

​

Synthesis

The strongest local-agent spine is a layered one:

1. The user or host application chooses an operating boundary.
2. Discovery surfaces help the agent find relevant capabilities.
3. Tools and servers expose capabilities inside that boundary.
4. Resources and roots describe which context can be read or selected.
5. Skills package repeatable task knowledge.
6. 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. Agentic resource discovery adds one more boundary that contributors should name explicitly. Discovery answers “what exists?” It does not answer “what is allowed here?” Catalog or registry results still need approval, pinning, auth, and scope review before an agent should connect or execute. The June 2026 refresh is a useful reminder that the stable handbook term is not just “local agent tooling.” It is local agent discovery and execution boundaries: where the work runs, how new capabilities are found, which approvals exist, which roots or resources are in scope, and what review surface remains after the action completes.

​

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.

​

Execution 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, ARD, and remote-boundary comparison.
• Agent Runtime Building Blocks: use this when the draft needs a reusable breakdown of execution, memory, interface, and action layers inside an agent system.
• 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.
• Codex Workshop: use this when the draft needs the shortest repo-native path from local setup to a real repository-scoped coding-agent loop.
• 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
• registry-backed coding agent: ARD or catalog search result plus a pinned remote MCP or skill decision before execution
• 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-06-21: Added agentic resource discovery sources, clarified discovery versus connection boundaries, and extended the execution-boundary matrix to include ARD-style registries.
• 2026-06-06: Added current OpenAI MCP/connectors guidance and refreshed the matrix around explicit local-versus-hosted execution boundaries.
• 2026-05-27: Replaced older prompt-injection sources with current OpenAI and Microsoft guidance, added the authority-boundary matrix, and connected the note to relevant 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.