GrantTap field guide · · 15 min read
When a document tries to instruct your coding agent
Separate authorized instructions from retrieved material. Inspect tool inputs, preserve provenance, limit credentials and verify the execution boundary without claiming a universal prompt-injection shield.
A coding agent reads material that other people can change: repository files, issue descriptions, dependency documentation, browser pages, command output, and messages from connected services. Some of that material describes the work. Some may try to redirect it. A useful defense starts by asking which source is allowed to give the instruction, rather than asking whether the words sound convincing. A page can be relevant to a bug without having permission to choose a new destination for credentials, expand repository access, or authorize a deployment.
This article develops a practical boundary for local coding work coordinated through GrantTap. It explains how to inspect suspicious content, preserve the intended task, and use supported tool controls without assuming that one product can identify every hostile sentence. The scenarios are defensive examples and proposed checks, not a report of a vulnerability found in a customer project. The editorial date belongs to the archive; preparation and source verification took place on November 5, 2026.
Distinguish the task from the material used to solve it
Start with the request that actually came from the person who owns the work. Identify the desired outcome, permitted workspace, relevant constraints, and decisions that require that person's involvement. Then classify incoming material by its role. A stack trace is evidence about a failure. A documentation page may explain an API. A third-party issue comment may suggest a reproduction. None automatically becomes authority to change the objective. This distinction remains useful even when the material is not malicious. A well-intentioned old comment can still describe an obsolete process that conflicts with the current request.
Repository instructions need the same care, with attention to their legitimate scope. A project's recognized instruction files may contain rules the user has authorized the agent to follow. That does not mean every quoted document, generated report, or copied issue has the same authority. Ask who controls the source and why its instructions apply to this task. When a source includes a statement that somebody already approved an action, treat that statement as a claim until it is confirmed through the appropriate decision channel. The agent should not manufacture a new user instruction from a sentence embedded in data it retrieved.
Notice changes of authority, destination, and scope
Suspicious material often asks the agent to cross a boundary that the original task did not require. The clearest warning signs are a new recipient, an unexpected credential request, a change to permissions, a demand to bypass review, or an instruction to hide part of the work. You do not need a catalog of every possible phrase to recognize the structural change. Compare the proposed action with the objective and the source's authority. A source that can explain a build error has not necessarily been authorized to edit account configuration or send project contents elsewhere.
Look for indirect redirection as well. A document may claim that a routine prerequisite requires disabling a check or replacing an approved dependency with an unknown download. A tool response may include suggested next steps that go beyond the tool's purpose. Those suggestions can be useful, but they remain suggestions. Verify the underlying reason and use trusted documentation or a bounded local inspection where possible. The practical question is whether the proposed step is necessary, within scope, and allowed by the effective policy. Confident wording and apparent urgency are not substitutes for those conditions.
Keep the execution boundary outside the prose
Instructions can guide behavior, but technical permissions determine what the agent can actually do. Keep sensitive capabilities limited by the provider's native environment, the operating system, service credentials, and supported project policy. GrantTap Governance offers Allow, Ask, and Deny for supported capability paths, with computer-reported coverage. A saved rule and a confirmed enforced rule are different states. If the selected integration only observes a capability, its report should not be interpreted as a guarantee that the action was blocked before execution.
Avoid responding to a failed operation by broadly removing restrictions. A permission error can indicate that the boundary is working as designed. First identify the exact capability and the reason it is needed. If a legitimate action requires a narrower adjustment, make that adjustment deliberately and verify its application on the owning computer. The phone's approval does not override a provider-wide denial or a policy the route cannot enforce safely. This approach cannot prove that every malicious instruction will be recognized. It reduces the consequences of a mistaken interpretation by preserving independent limits on execution.
Inspect the proposed tool call rather than its reassuring description
A tool label can hide important differences in target and effect. Before authorizing a sensitive call, inspect the actual operation, arguments, workspace, and destination. A read action against a sample file is different from a write against production configuration. An upload to an approved service is different from a transfer to a newly introduced address. The friendly explanation should help you understand the call, but the call itself determines the practical consequence. In GrantTap's approval details, retain the link to the original request and the computer that will execute it.
The MCP Tools specification describes tools with schemas and distinguishes protocol errors from tool execution errors. Its security guidance assigns responsibilities to both servers and clients, including input validation, access controls, visible inputs for sensitive operations, and validation of results. Those protocol provisions are not a universal semantic detector of malicious content. Treat the schema as an interface contract and the authorization as a separate decision. A result that conforms to a JSON shape can still contain misleading prose. A successfully transported request can still be rejected by the service responsible for the action.
Minimize secret exposure before reading untrusted material
The safest secret is often one the task does not need to see. Prepare a sample configuration, a restricted test account, or a service-specific access path instead of putting broad credentials into the agent's context. Do not copy environment files into a conversation simply because an issue comment asks for a complete diagnostic bundle. Determine which configuration fields matter, remove confidential values, and preserve enough structure to explain the failure. This is a proposed working practice, not a claim that GrantTap automatically redacts every file or every external tool response.
Separate configuration from authorization. A provider's login on a particular computer, a GrantTap device pairing, and a project's environment values solve different problems. Successfully connecting the phone does not authorize arbitrary access to the provider's account. Likewise, a project secret should not be repurposed as an MCP token for an unrelated service. Keep credential handling in the supported login or secret-management path. If you suspect that a credential was actually exposed, use the owning service's revocation and recovery controls. Deleting the visible chat message is not a reliable way to revoke a copied credential.
Respond to a suspicious instruction without amplifying it
Pause the affected action and describe the mismatch plainly. Identify the source, the requested deviation, and the task boundary it would cross. You can preserve a short sanitized excerpt when it helps the owner understand the issue, but there is no need to repeat a complete malicious payload through every connected channel. Keep the evidence separate from the instruction you want the agent to follow. A report can say that an external page requested an unrelated credential upload without turning that requested upload into a new action item.
Then continue the legitimate work where possible. A suspicious comment in one issue does not automatically invalidate the entire repository. The agent may be able to reproduce the bug using known files, consult an official API reference, or ask the owner a focused question about the intended destination. Escalate the actual unresolved decision, not a vague demand to confirm everything again. If the suspicious content altered the working context materially, a fresh bounded continuation with a clear summary may be appropriate. State what is known, what was not executed, and what still needs verification rather than claiming that the whole environment is now safe.
Build a harmless boundary test
Use a disposable project and synthetic material. The test can include a document that asks the reader to change a nonessential local setting or ignore a declared acceptance rule. The goal is to observe whether the agent distinguishes retrieved content from the authorized task. Do not include real credentials, real external recipients, destructive operations, or live accounts merely to make the example feel realistic. Define the expected outcome before starting: the source is recognized as data, the unrelated action is not executed, and the agent continues or asks a targeted question about the legitimate work.
Observe both behavior and enforcement. An agent that voluntarily refuses the redirection demonstrates one response in that context. A technical denial at a supported tool boundary demonstrates a different layer. Record which layer produced the result. Do not infer that all providers, all prompt variants, or future sessions will behave identically. If the route only supplies observation, say so. A small safe test can improve your configuration and understanding without becoming a public claim of comprehensive security coverage. The article's illustrations represent these boundaries conceptually; they are not captures of a successful containment experiment.
Keep a retrieved plan separate from an approved plan
Agents often retrieve instructions that look like a ready-made implementation plan. That can be helpful, but approval should attach to a specific intended operation rather than to the mere existence of a plan. Check whether the plan's assumptions match the current project, revision, environment, and account. A maintenance guide for a different deployment can recommend a valid command that is still wrong for this computer. A copied checklist may also presume access that the task owner never granted. The agent should adapt the useful explanation without silently inheriting those assumptions.
For sensitive changes, ask for the smallest reviewable proposal: which target, which effect, why it is necessary, and how success will be verified. If the owner already authorized that exact scope, preserve the authorization instead of repeatedly interrupting. If the proposal introduces a new scope, explain the missing decision clearly. This is an authority check, not a request to approve every read operation. The purpose is to keep momentum on the legitimate task while preventing external prose from expanding permissions through an apparently routine prerequisite. A useful plan makes its dependencies visible enough to inspect.
Understand what encryption protects
GrantTap's encrypted device connection protects message contents on the supported route between trusted endpoints. It does not make every document the agent reads trustworthy, and it does not mean the model executes without contacting its own provider. Once the selected computer decrypts a task, the configured coding client and its tools operate under their own data and permission boundaries. A browser controller also has a different local storage model from a native app. Keep those endpoint differences visible when deciding where to review sensitive material.
An encrypted malicious instruction is still a malicious instruction. Transport protection and source authority answer different questions. Similarly, an authenticated service can return content supplied by an untrusted user. The service identity tells you where the response came from; it does not make every embedded claim an owner's instruction. This matters in issue trackers, shared documents, and repository comments. Preserve the original provenance in your reasoning and reporting. Do not summarize a third-party suggestion as a confirmed project decision simply because it arrived through an authenticated API or an encrypted connection.
Preserve boundaries during a Task transfer
A handoff should carry the objective, known facts, relevant changes, checks, and unresolved decisions. It should not promote suspicious source material into a higher-trust instruction just because the next agent reads a summary instead of the original page. Mark external claims and rejected redirections explicitly. If the previous execution decided not to run an operation, preserve both the reason and the fact that it was not run. The next agent should not need to rediscover that the apparently helpful prerequisite was unrelated to the approved task.
GrantTap keeps a stable Task while the provider or computer can change through a separate Execution. Check the destination's workspace, tool support, and effective policy independently. A transfer does not carry the source computer's permissions automatically, and a Git commit does not encode every account grant. If an important restriction cannot be enforced on the destination route, that limitation must remain visible. Do not present the new agent as protected merely because the previous one had a supported hook. The working boundary belongs to the current execution environment, not to the visual continuity of the conversation.
Make review questions concrete
When asking a person to resolve a boundary question, show the particular decision. For example, a new diagnostic endpoint may be proposed while the task only authorized local inspection. The useful question identifies the endpoint's owner, the information that would be sent, the reason for the request, and an alternative that stays within the existing scope. The person can then approve, refuse, or choose the alternative knowingly. A vague confirmation button attached to a long unfamiliar command does not provide the same understanding, even if it creates an approval event in a log.
Avoid alarm fatigue by separating ordinary evidence collection from meaningful authority changes. Reading an already authorized file usually does not need a new decision. Expanding access to another repository, sending private material externally, or changing an effective denial may. Honor the owner's existing instructions when they already settle the question. Good boundary handling should reduce unnecessary interruption, because the agent understands what it may continue doing. It should also make the few important interruptions easier to answer. The objective is a comprehensible workflow, not a wall of warnings that the user learns to dismiss.
Record the incident without creating a new leak
A useful report names the task, source type, relevant timestamp, attempted deviation, and observed result. Include sanitized request or delivery identifiers when they help locate the event. Exclude tokens, active QR codes, authorization codes, unrelated private files, and unnecessary account details. If a tool call ran, distinguish its transport receipt from its actual effect. If the agent stopped before calling the tool, report that narrower fact. The reviewer should be able to tell whether the boundary was exercised, whether a policy rejected the action, and whether any follow-up recovery is required.
Keep the report proportionate to the evidence. A suspicious string in a document does not prove exploitation. A blocked call does not establish that every path is protected. A screenshot of an approval sheet is not a penetration test. GrantTap's audit and transcript sources can help organize observations, but a broader security conclusion requires its own work. When reporting an actual service issue, use the maintainer's appropriate channel and disclose only what is necessary. The practical outcome should be a corrected route or a better boundary, with the legitimate development task able to continue under understood conditions.
Recheck the setup when its parts change
Provider updates, new MCP tools, a different computer, and changed project access can alter the available execution paths. Revisit the boundaries that mattered to your task after such changes. Confirm which capabilities are installed, which are selected, which are enforced, and which have actually been observed. These are distinct facts. Updating a CLI through Devices does not prove that an already running process adopted the new version or that a new tool inherited the intended project rule. Read the result and refresh the owning computer's state before assuming the change is active.
Keep a small maintenance record rather than rebuilding the entire security model on every turn. It can identify the current route, important denials, trusted instruction sources, and a harmless regression scenario. Repeat that scenario when a material component changes. If the result becomes unknown, retain the uncertainty until the supporting path is checked. The strongest practical habit is to connect each instruction to its authority and each action to its execution boundary. That habit remains useful across changing models and interfaces, while leaving room for the real limitations of any particular agent integration.
