# A collection of 12 posts

## [Parallel agent workflows often use Git worktrees: one checkout per task, one branch per agent. That improves isolation, but it also creates a subtle permissions problem. A child agent running in one worktree may still try to read or edit sibling worktrees, parent directories, or shared files outside its assigned.](/content/blog/opencode-worktree-relative-deny-rules/index.html)

## [The useful version of issue-to-PR automation is not "let the agent merge code." It is "give the agent a well-scoped issue, let it open a draft pull request, and keep the existing GitHub quality gates in charge."  
The Linear integration for GitHub Copilot cloud agent fits.](/content/blog/linear-agents-github-copilot-draft-prs/index.html)

## [Hosted coding agents are convenient until legal, security, or customer commitments say your source code cannot leave controlled infrastructure. OpenHands is interesting for those teams because it offers open-source local usage and an enterprise self-hosted model where agents run in your environment.  
This article outlines how to think about self-hosting.](/content/blog/openhands-self-hosting-compliance-sandbox/index.html)

## [Git worktrees make it easy to run several coding agents in parallel. They do not make the resulting branches compatible. If three agents edit the same files, the merge queue becomes the first place you discover the collision.  
A lightweight "clash predictor" can catch overlapping edits earlier by.](/content/blog/parallel-worktrees-conflict-prediction/index.html)

## [OpenCode permissions are useful when you are driving agents from a terminal. They become awkward when the human approver is not sitting at that terminal. A better shape for remote approval is event-driven: subscribe to permission.asked, send the request to a mobile queue, then handle permission.replied as the.](/content/blog/opencode-permission-events-mobile-approval-queue/index.html)

## [Most agent safety controls are advisory until they sit on the tool-call path. VellaVeto is positioned as a runtime proxy for MCP tools: every call is evaluated against policy before execution, and policy failures deny the call. That fail-closed posture matters for agents that can read files, call SaaS APIs.](/content/blog/vellaveto-fail-closed-policy-mode-deny-unsafe-mcp-tool-calls/index.html)

## [Prompt injection becomes operationally dangerous when an agent can both read secrets and make network or tool calls. Pipelock addresses that boundary problem by sitting between the agent, MCP servers, and the network. This article is for developers running coding agents locally or in CI who want a practical control.](/content/blog/pipelock-mcp-proxy-https-proxy-stop-secret-exfiltration/index.html)

## [Agents often need credentials to be useful. They also read files, execute tools, and ingest untrusted content. That combination makes plaintext API keys in .env files, shell profiles, and agent config a poor default. Pincer-MCP takes a proxy-token approach: the agent receives a limited token, while real API keys stay.](/content/blog/pincer-mcp-proxy-tokens-keep-real-api-keys-out-of-agent-memory/index.html)

## [Agent failures rarely look like a single slow request. They look like loops: plan, call tool, retry, summarize, call another tool, exceed budget. OpenTelemetry’s GenAI semantic conventions give developers a portable way to trace those steps with model, token, workflow, and tool-call attributes.  
The short version  
* Use one trace.](/content/blog/opentelemetry-genai-spans-agent-workflows-trace-tool-calls/index.html)

## [MCP tools are not just code endpoints. Their names, descriptions, and schemas are fed to the model so it can decide what to call. That makes tool metadata part of the instruction channel. Tool shadowing and poisoned descriptions abuse that trust by hiding instructions where users rarely look but models.](/content/blog/mcp-tool-shadowing-defenses-detect-poisoned-descriptions/index.html)

## [A coding agent is useful because it has capabilities: it can read a repo, run tests, call tools, and access the network. A prompt injection is dangerous for the same reason. Capability separation reduces blast radius by ensuring no single component has both unrestricted secrets and unrestricted egress.  
The short.](/content/blog/capability-separation-coding-agents-network-sandboxing-egress-dlp/index.html)

## [Most MCP security discussions focus on either secret leakage or prompt injection. In practice, you need both directions. Outbound tool arguments can carry secrets to an attacker-controlled server. Inbound tool responses can carry instructions that compromise the next model step. A useful MCP gateway scans both paths.  
The short version.](/content/blog/bidirectional-mcp-scanning-pipeline-catch-leaks-and-injection/index.html)