Context, Tools & Permissions in Coding Agents
Agent quality is not just model quality. What the system can see, what it can execute and where it must ask for approval are equally important parts of the design.
Three layers determine agent behavior
A coding agent can only act through the environment around the model. Three layers are especially important:
Context determines what information the model can reason about. Tools determine what actions it can request. Permissions determine which of those actions the environment will actually allow and under what conditions.
Two systems using the same model can behave very differently because these layers differ.
Context: what the agent can see
Useful context may include source files, repository instructions, issue requirements, diffs, dependency manifests, test output and tool results. Retrieval matters because large repositories exceed practical context budgets.
Context also has provenance. A project instruction written by the repository owner is not equivalent to arbitrary text found in a dependency, webpage or issue comment. Systems should preserve that distinction when deciding what instructions deserve authority.
Tools: what the agent can attempt
A model that can only answer with text is limited to recommendations. Add file editing and it can change a working tree. Add a terminal and it can build or test. Add networked integrations and it may interact with issue trackers, documentation, databases or deployment systems.
MCP is one current standard for connecting AI hosts to external tools and data. Its SDK documentation describes servers exposing tools, resources and prompts that compatible hosts can use. That interoperability is useful, but each added integration also expands the system's capability surface.
A tool may exist without being automatically executable. The host can require confirmation, constrain arguments, isolate execution or deny the action entirely.
Permissions: what the agent is allowed to do
Permission design should follow the potential consequence of an action. Reading a source file is different from deleting files; running a unit test is different from publishing a package; editing a local branch is different from changing production infrastructure.
Useful controls include filesystem scope, command allow/deny rules, network restrictions, secret isolation, sandboxing and explicit approval for higher-impact actions. OpenAI's description of Codex safety emphasizes boundaries, approval for higher-risk actions and telemetry; GitHub likewise documents human oversight and review across its agentic features.
The goal is not to require a confirmation dialog for every harmless operation. It is to keep the agent's authority aligned with the task.
Treat external content as untrusted input
An agent may read README files, issue comments, webpages, generated logs or tool responses. Those inputs can contain instructions that conflict with the user's actual goal. This creates a prompt-injection problem: text encountered during the task may try to redirect the model into unrelated or unsafe actions.
Practical defenses are layered: minimize unnecessary access, keep secrets out of the execution environment where possible, restrict consequential tools, separate trusted instructions from retrieved content and require approval when an action crosses an important boundary.
Verification and review close the loop
Even a well-sandboxed agent can produce incorrect code. Review therefore has two dimensions: what the agent was allowed to do and whether the resulting change is correct.
Before accepting substantial agent work, inspect the diff, understand commands that were run, review test evidence and consider what was not tested. For high-impact changes, use the same engineering controls you would require for a human-authored contribution.