DEV CommunityWednesday · June 10, 2026FREE

Agent workflows need an impact boundary

In a follow-up to a previous article about why coding agents should not hold write credentials, David Loibner expands the argument to all agent workflows. He uses GitHub as an example, noting that a coding agent can read a repository, reason about a change, and produce useful work, but if the same agent also owns the token that creates branches, commits, or pull requests, the proposal and the authority to create impact are too close together. The problem extends beyond GitHub: agents are becoming more useful because they can use tools to read files, call APIs, update tickets, prepare emails, run commands, inspect systems, and sometimes change state. Loibner emphasizes that the boundary matters more, not less, as agents gain more capabilities. He poses two questions: "Can the agent use this tool?" and the more important "Should this specific request become impact now?" He argues that a tool can be visible to the agent, the call valid, the arguments well-formed, and the goal reasonable, yet this does not automatically mean the requested effect should happen. Examples include a GitHub tool creating a pull request, a database tool updating or deleting rows, a cloud tool deploying a configuration, or an email tool sending messages. The article calls for a missing layer of decision-making to separate tool access from impact execution.