A coding agent's security boundary is the set of operations its environment actually permits, not the set of operations the agent says it intends to perform. A useful operating model starts with that distinction. Instructions guide the agent, approval rules govern decisions, and technical controls constrain execution. Each layer matters, but none should be described as though it automatically supplies the others.
OpenAI's current sandbox documentation separates sandbox enforcement from approval policy and notes that spawned commands inherit the execution boundary. It also distinguishes native Windows execution from the Linux implementation used in WSL2. The exact configuration depends on the surface and managed requirements. An operator should inspect the effective session rather than infer it from a product name or an old screenshot. OpenAI sandbox documentation
This article offers an original verification and operating framework for teams using coding agents. It focuses on the evidence needed to justify security claims across local machines, cloud environments, tools, and release processes. The exercises are hypothetical and use harmless fixtures. They are not a claim that Apiary has certified a particular environment or that any software configuration eliminates all risk.
Write down the assets before writing the policy
Begin with the things the agent could affect. In a development task, these may include repository source, uncommitted work, local documents, package caches, credentials, internal services, cloud resources, and public releases. The list should be specific to the environment. A personal workstation and a disposable cloud checkout may run the same command while exposing very different assets.
For each asset, identify the intended operation. The agent may need to read source, modify selected files, run tests, and produce a patch. It may not need to read unrelated home-directory content or deploy to production. Distinguishing read, write, execute, and publish operations prevents a broad phrase such as “repository access” from hiding several different permissions.
Identify the valuable state already present in the workspace. Dirty files belong to someone; they are not automatically disposable because they are uncommitted. A shared checkout may contain another agent's work or a human's unfinished experiment. The task should preserve that state unless the user clearly authorizes a change. Isolated worktrees can reduce accidental overlap while retaining a clear source relationship.
Consider external effects separately. A program that only reads local files may still send their contents through a network request if networking is available. A tool that looks like a file operation may write to a shared cloud folder. The asset inventory should therefore include destinations and audiences, not only paths on disk. Publication changes who can access information.
The resulting inventory does not need to be a large compliance document. A concise table or manifest can identify each resource, intended operation, enforcement mechanism, and verification method. Its value comes from making assumptions explicit. When the task changes, the operator can see which boundary needs to change and which resources remain outside scope.
Separate intent, authorization, and enforcement
Intent describes what the user wants. Authorization describes which actions the agent may take to achieve it. Enforcement describes what the runtime will technically allow. These concepts overlap in practice but should not be collapsed. A user may authorize a repository edit while the current runtime cannot write the file. Conversely, a runtime may technically permit a deployment that the user never requested.
The agent should continue autonomously through clearly authorized, reversible work within its boundary. Repeated permission questions for routine steps create fatigue and make consequential decisions harder to notice. When a materially different action needs a decision, present the specific artifact, destination, and effect. The goal is meaningful control, not interruption as a substitute for design.
Technical enforcement should remain effective when the agent makes a mistake. A prompt that says “do not read outside the repository” is useful guidance, but it is weaker than an environment that denies those reads. A network allowlist written in a note is weaker than an active network control. Verification should test the actual execution path that the agent uses.
Approval is not a universal override. Some actions remain unavailable because of administrator requirements, service policy, or tool-specific restrictions. A denial should be understood and reported rather than worked around through another mechanism. If a legitimate task needs a different capability, the operator should use the supported configuration or authorization process for that capability.
Record the effective boundary at the start of a run and after any material change. This can include workspace roots, execution mode, network policy, tool availability, and the identity of the target repository. Avoid recording credential values. The purpose is to explain what the agent could do, not to create a new sensitive-data archive in the name of auditability.
Verify filesystem boundaries with controlled fixtures
A harmless filesystem test can establish more than a long description of intended behavior. Create a test workspace containing an allowed file and a separate fixture outside the allowed write area. Ask the actual execution tool to read or write according to the intended policy. Use synthetic data and ensure the test itself is authorized. The result should identify which operations were allowed and denied.
Test resolved paths, not just obvious filenames. Relative traversal, symbolic links, junctions, and alternate path forms can expose differences between application validation and operating-system enforcement. The appropriate cases depend on the platform. The important question is whether the effective target remains within the intended boundary after the filesystem resolves it.
Do not use real secrets as canaries. A file containing a harmless unique marker is enough to test whether a read is possible. If the marker appears in an unexpected output, the boundary test has found a problem without exposing valuable information. Store the test result privately and remove or retain the fixtures according to the normal workspace policy.
Include subprocesses in the test. An agent may invoke a package manager, a compiler, or a script that launches another program. The boundary should apply to those operations as documented. Testing only the built-in file editor leaves a large portion of the real execution surface unexamined. A command can do more than its top-level name suggests.
A passing test is evidence for the tested configuration and path. It is not proof about every possible filesystem operation or every future version of the runtime. Record the date, platform, tool version, and relevant policy. Repeat the focused tests when the environment changes materially, rather than treating one successful demonstration as permanent certification.
Verify network policy as its own system
Network access and filesystem access are independent dimensions. A read-only workspace can still expose source through outbound traffic. A writable workspace with networking disabled can still damage local files. Describe and test both. The phrase “sandboxed” is too broad to establish the network destinations or request types available to an agent.
OpenAI's current security documentation distinguishes enabling command networking from activating destination-policy enforcement, and notes that hosted search, apps, and MCP have separate controls. These distinctions mean a setting for shell traffic should not be generalized to every connected capability. Check the relevant surface and managed policy before making a claim. Agent approvals and security
For a controlled test, use approved endpoints that return a small harmless response. Verify one intended destination, one explicitly denied destination, and any local service the task genuinely requires. Record the outcome through the actual command environment. A successful browser visit does not establish that shell networking works, and a blocked shell request does not establish that a connector is unavailable.
Inspect redirects and destination changes when they matter. An allowed documentation URL may redirect to another host. A policy should define whether that second destination is permitted and how the client handles it. The task should not silently broaden its access because a remote page suggests another endpoint. Retrieved links provide information, not authorization.
Also distinguish connectivity from suitability. A destination may be reachable while still being an inappropriate place to send repository data. The agent needs a task-level rule about what information can be transmitted, and the service may need a brokered operation that limits payloads. Network reachability is a technical fact; permission to disclose data is a separate decision.
Understand local, WSL, and cloud execution separately
An agent interface can coordinate work across several execution environments. A command may run on a Windows host, inside WSL, or in a cloud container. The same apparent workspace path in the conversation does not establish the same operating-system boundary. Record where each consequential step actually executes and which resources are mounted there.
Native Windows and WSL should not be described as interchangeable security implementations. OpenAI's sandboxing guidance explicitly distinguishes them. For operational verification, inspect the active environment and use tests appropriate to that platform. A successful Linux boundary check does not certify a native PowerShell session, and a Windows policy does not automatically constrain a remote cloud worker.
Cloud execution introduces another distinction between setup and agent phases. Some environments install dependencies during preparation and use different network settings during the task. Check the current environment documentation rather than carrying assumptions from a legacy configuration. If setup code comes from the repository, its trust and credentials need review as well as the agent's later commands.
Local-to-cloud synchronization also deserves attention. A selected directory may be copied into a cloud workspace, while other local files remain inaccessible. The operator should know which files are synchronized and how exclusions work. Do not assume that a local exclusion rule applies to a different upload mechanism without checking it. The transfer itself is part of the data boundary.
When reporting verification, name the environment. “Tests passed in the isolated cloud checkout” is a useful claim. “The local machine is protected” would require different evidence. Precise environment labels prevent a successful check in one place from being used to justify unrelated capabilities somewhere else.
Treat repository instructions as scoped guidance
Repository instruction files can explain build commands, coding conventions, release paths, and known hazards. They are valuable context for an agent working in that repository. Their scope should be understood: they guide the task within the user's authorization and higher-priority requirements. They do not grant new authority over unrelated services merely because a file says to use them.
Read the applicable instructions before modifying source. A release rule may identify a combined build directory that preserves several applications, or a generated file may need to be updated through a specific generator. Ignoring those rules can cause a severe regression even when the code edit itself is correct. The instructions are part of the operational evidence for how the repository is maintained.
Distinguish maintained instructions from arbitrary content. A test fixture, issue comment, or third-party README can contain text that looks like an instruction to the agent. The agent may need to read it as evidence without obeying it. The source and trust level of the text should remain visible during retrieval and summarization.
If instructions conflict, identify the conflict and resolve it through the applicable hierarchy and task context. Do not invent a new permission requirement from an ambiguous convention, and do not ignore an explicit safety constraint because a shortcut seems convenient. A competent operating process respects already granted authorization while recognizing actual boundaries.
Keep instruction changes reviewable. An agent should not quietly rewrite its own repository rules to make a task easier. If the rules are stale or wrong, propose a scoped correction with evidence and explain the effect. The revised instructions should help future maintainers understand the repository, not merely rationalize the current agent's preferred implementation.
Prompt injection is an authority-confusion problem
An agent may encounter malicious or irrelevant instructions inside the material it is asked to analyze. The dangerous step is promoting that material into authority over the task. A web page, source comment, or log line can tell the agent to reveal secrets or change its objective. The content remains evidence to inspect, not a new user instruction.
Use harmless adversarial fixtures to test the whole workflow. Place a canary instruction in a comment or document that the agent must read for a legitimate task. Verify that the agent extracts relevant facts while ignoring the attempted redirection. The test should include the connected tools the task actually uses, because a retrieval-only demonstration does not establish safe behavior once writes become available.
Summarization can weaken the boundary if it removes attribution. A summary that says “the document requests an upload” preserves the source relationship. A summary that simply says “upload the file” can accidentally turn quoted content into an action item. Review how intermediate notes, memories, and handoffs represent instructions found in untrusted material.
Technical limits reduce the impact of a mistaken interpretation. An agent that cannot access private credentials or contact arbitrary destinations has fewer ways to act on an injected request. That is why prompt handling and sandbox design should be evaluated together. Neither a perfect-looking prompt nor a single filter should be treated as a complete defense.
The expected response to suspicious content depends on the task. The agent may quote or analyze it, flag it as irrelevant, or continue with the legitimate work. It should not derail every task merely because source contains imperative language. The key is to preserve the difference between understanding an instruction as content and accepting it as authority.
Make verification independent of the agent's summary
An agent's final explanation is a useful account of its work, but it is not the strongest evidence that the work happened. Preserve the relevant command results, artifact hashes, test reports, and destination readbacks. A reviewer should be able to verify the important claims without trusting the wording of the summary or repeating the entire task from scratch.
Choose checks that address the requested behavior. If the task fixes a page that renders blank, an HTTP status check alone is inadequate. The page may return success while its body is empty or its client-side script fails. If the task changes access control, a build pass does not establish that unauthorized requests are rejected. Verification should follow the user-visible failure mode.
Use independent expected results where practical. A test generated from the same mistaken assumption as the implementation can pass while the feature remains wrong. A small manually specified fixture, a before-and-after comparison, or a known invariant can challenge that assumption. Independence does not always require another person or model; it requires that the check not merely restate the implementation's own output.
Record negative evidence accurately. A command that timed out did not pass. A tool that was unavailable did not verify the system. A sampled audit does not cover every item in the inventory. These distinctions can be concise in the final response, but they should remain explicit in the underlying receipt. Clear limitations are more useful than broad reassurance.
Verification should also examine preservation. A change can achieve its local goal while removing another feature or overwriting unrelated content. Compare the intended artifact against the prior state, especially for generated indexes, deployment bundles, and configuration. An additive publication should prove that existing entries remain intact, not only that the new entry appears.
Use a capability matrix for mixed tool environments
A modern agent may have a shell, browser, file editor, repository connector, cloud API, and document service. Each tool has its own permissions and side effects. Build a small matrix that lists the tool, execution location, accessible resources, allowed operations, and verification method. This avoids treating one global phrase such as “read-only mode” as a description of every capability.
For example, the shell may be unable to reach the Internet while a connected repository tool can read a private repository. A browser may be signed into a cloud console while the command-line client is authenticated to a different account. A document connector may write to a shared folder even though the local filesystem is restricted. Each fact changes the action's context.
Before a consequential operation, verify the target identity through the tool that will perform it. A successful login elsewhere does not establish the current account for this tool. Read the project, repository, hostname, or document metadata and compare it with the task. This is particularly important when a user maintains several accounts with similar project names.
Do not use an alternative tool to evade a denied action. If one tool blocks an operation because of a safety or authorization rule, switching to another mechanism for the same action does not resolve the underlying issue. A legitimate fallback is appropriate for a capability failure, such as an unavailable renderer, only when it preserves the applicable policy and authorization boundary.
Keep the matrix current enough to be useful without turning it into a burden. Refresh identities and permissions that can drift cheaply. Preserve stable architectural facts as documentation. When a fact is based on an older receipt, label it as historical until verified again. The matrix should reduce mistaken assumptions, not create a false impression of permanent certainty.
Preserve dirty work and make edits reversible
Before editing, inspect the repository state and identify existing modifications. An agent should not reset or clean a shared checkout merely to obtain a convenient baseline. Uncommitted files may be the user's most recent work. A scoped worktree or separate checkout allows the agent to proceed while leaving that work intact.
Stage only the files that belong to the task. A broad add operation can capture logs, local configuration, generated assets, or another contributor's unfinished changes. Review the staged diff before committing. The commit should be understandable as a bounded unit, and its description should match what it actually contains.
Prefer reversible changes during investigation. Save a copy or use version control before transforming a valuable input. For generated artifacts, retain the source and the generation command. Reversibility does not eliminate the need for judgment, but it makes ordinary mistakes easier to repair without losing the user's work.
Deletion deserves a concrete target and a verified path. A cleanup script should know exactly which generated directory it owns, and it should verify the resolved path before recursive removal. Avoid constructing destructive commands from loosely matched filenames. The difference between a build directory and a source directory can be one mistaken variable or an unexpected working directory.
A good handoff includes the branch or commit, the relevant local path, and any remaining uncommitted task files. It should not leave the next maintainer guessing which directory contains the tested result. Durable source and evidence reduce the temptation to reconstruct a release from whichever folder happens to look newest.
Treat deployment as a distinct authority boundary
Deployment can affect users who were not part of the development conversation. Even a small content change may replace a larger bundle if the platform deploys directories or complete worker packages. The operator must know the release unit and the correct source of truth. A correct file in the wrong deployment directory can still produce a destructive release.
Before publication, identify the intended account, project, branch or environment, and artifact. Compare current runtime settings with the proposed release when those settings are managed separately. Preserve bindings, routes, and other resources that the task did not authorize changing. A stale local configuration is not a reliable description of production merely because it once deployed successfully.
Use a preview or staged version when the platform supports it and when it materially reduces risk. Test the actual artifact that will be promoted, not a different local build assembled with different inputs. Associate the preview with a hash or immutable version identifier so the final promotion is a verifiable continuation of the tested result.
Refresh the production head immediately before switching traffic. Another agent or maintainer may have deployed since the investigation began. If the current version differs, inspect the change and reconcile it rather than overwriting blindly. A conflict check protects other authorized work and prevents a narrow fix from becoming an accidental rollback.
After publication, verify the live path and record the deployment identity. A provider accepting an upload is not always proof that the custom domain serves it. DNS, routing, caches, or staged traffic settings can keep the old version active. The final receipt should distinguish uploaded, activated, and live-verified states according to what was actually observed.
Keep secrets out of evidence artifacts
Security work often produces detailed logs, and those logs can become a new source of exposure. Avoid printing tokens, full environment dumps, or private configuration contents merely to prove that authentication exists. A tool can usually report account identity, credential type, and permission names without revealing the credential value.
Inspect diagnostic scripts before running them in a credentialed environment. A generic debug command may serialize request headers or dump process variables. Use a bounded probe that returns only the information needed for the decision. The same principle applies to screenshots: a useful visual check should not unnecessarily capture private account details or unrelated sensitive windows.
Separate private evidence from public documentation. A release note can name the version and tests without including internal paths, raw customer data, or secret-bearing URLs. Store private artifacts under the appropriate access policy and publish a sanitized receipt. Do not rely on readers to infer which portions of a mixed document should remain confidential.
Redaction should preserve diagnostic meaning where possible. Replacing a token with a marker is useful; deleting the entire error context may make the failure impossible to understand. Record the operation type, target resource identity, status, and relevant non-sensitive message. If the raw artifact is retained, make its location and access boundary explicit.
Review evidence files before committing or uploading them. Automated secret scanning is a useful additional check, but it does not recognize every form of sensitive information. Personal data, private business context, and internal operational details may require human or task-specific review. The safest evidence package contains only what the next reviewer needs.
Respond to a boundary failure without broadening it
When an operation fails because of a permission boundary, first identify the actual reason. A missing file, expired login, wrong account, network denial, and unsupported command are different problems. Repeating the same action or granting broad access may hide the cause while increasing risk. A precise error and target identity usually suggest a narrower repair.
Use the supported recovery path for the tool or environment. If authentication requires user interaction, do not improvise a way to extract credentials from another application. If a browser safety check stops automation, respect the stop. If a managed policy forbids an action, report that boundary and continue only with independent work that remains allowed.
Do not confuse a technical capability failure with a safety denial. An unavailable screenshot service may permit a different authorized rendering method. A denial of access to a private resource does not. The agent should state which situation occurred and why the proposed alternative is appropriate. This keeps fallbacks useful without turning them into bypasses.
If a failure may have occurred after a write, reconcile before retrying. A lost response does not prove the action failed. Read the destination or inspect the operation receipt to determine whether the change already exists. Duplicate publication, duplicate messages, and repeated database writes often arise from treating an uncertain outcome as a clean failure.
Leave a resumable record when the task cannot proceed. Include the completed work, exact blocker, affected artifact, and next action needed. Do not mark the entire task complete because the available tools have been exhausted. The record should let the user or another authorized run continue without repeating successful work or making assumptions about unverified actions.
Plan incident handling before the first incident
A boundary test may reveal access that should have been denied, or a real task may expose an unexpected side effect. Define who can stop the execution, preserve evidence, and inspect affected resources. The response should prioritize containing the active problem and understanding its scope without destroying the information needed to diagnose it.
Use stable task and operation identifiers to reconstruct what happened. Identify the source revision, execution environment, tool calls, and resulting artifacts. Avoid assuming that every action in the conversation actually executed; compare requests with tool results and destination state. Likewise, do not assume that a failed response means no external change occurred.
Separate immediate containment from permanent repair. Stopping a task or revoking a task-scoped credential can limit ongoing impact. Fixing the policy, implementation, or workflow requires a reviewed change and regression tests. A successful emergency action does not establish that the underlying defect is resolved.
Test the repair against the original failure and nearby cases. If a path escape was possible through a link, test the link case and the legitimate in-workspace path. If a write was applied twice after a timeout, test the uncertain-response recovery path as well as normal delivery. The regression should protect the actual boundary, not just the exact spelling of one incident.
Document the conclusion with evidence and limits. State which resources were checked, which effects were confirmed, and which remain unknown. Avoid overstating either safety or compromise. An accurate bounded account is more useful than a dramatic narrative, especially when several tools and execution environments were involved.
Build a repeatable boundary-verification checklist
For a new environment, begin with identity: machine or cloud workspace, operating system, repository, revision, and active account for connected services. Then verify filesystem behavior using harmless fixtures. Verify command networking separately from browser and connector access. Confirm how credentials enter the environment and which outputs can leave it.
Next, test lifecycle behavior. Start a harmless child process, cancel the task, and confirm that execution stops as intended. Generate a bounded oversized output and confirm the tool reports truncation or rejection accurately. Simulate a stale source revision and verify that the patch process detects the mismatch rather than applying a decision based on old evidence.
Then test the release path in a disposable or preview target. Confirm that the intended artifact appears and that unrelated content remains preserved. Check the rollback reference and document its limits. If the environment cannot provide a meaningful preview, compensate with the appropriate local checks and a carefully scoped production verification, while stating the remaining limitation.
Finally, review the receipt itself. It should contain enough information for another maintainer to reproduce the important checks without exposing secrets. The strongest report is specific: these operations were tested in this configuration, these results were observed, and these capabilities remain unverified. That is a useful security statement because it can be challenged, repeated, and improved.
Worked exercise: a documentation fix with a release boundary
Imagine a user asks an agent to correct a misleading setup instruction and publish the corrected documentation. The repository contains the website source, a generated output directory, and several unrelated local modifications. The agent begins by recording the current revision and dirty paths, then creates an isolated worktree. It reads the repository's release instructions and identifies the exact build directory used by the documentation site.
The correction itself is small: one instruction refers to an obsolete configuration key. The agent checks the current primary documentation, updates the prose, and removes an example that no longer applies. It verifies that links resolve and that the new instruction describes the supported behavior. These checks establish the content correction, but they do not yet establish a successful release.
The build produces a preview. The agent opens the affected page and confirms that the revised text is visible, the code example is readable, and navigation still works. It also compares the generated inventory with the previous release to ensure that unrelated pages remain present. This preservation check matters because the deployment unit is the entire site, even though the source edit changed only one paragraph.
Before publishing, the agent verifies the authenticated account and project through the deployment tool. A browser session in another account is not accepted as proof of the command-line target. The agent reads the current deployment identity and confirms that no newer release has appeared since the baseline was captured. If it has, the agent reconciles the new state before proceeding.
The authorized publication then uploads or promotes the tested artifact. The agent records the provider's version identifier and checks the public URL. It verifies the actual revised text rather than only the status code. If the page is cached, it uses the platform's supported verification path and reports any unresolved cache delay accurately. The final response can be brief because the receipt contains the detailed evidence.
Now alter the exercise in three ways. First, make the default deployment account the wrong one. The target-identity check should stop the release before any upload. Second, add a newer production version after the preview passes. The conflict check should detect it. Third, make the public page return success with an empty body. The content verification should fail even though the HTTP request succeeded.
These variations test different boundaries: account identity, concurrent state, and runtime behavior. None is solved by making the agent more confident or by asking it to promise caution. Each needs a concrete check at the point where the relevant fact can be observed. The example also shows why useful autonomy and careful verification are compatible: the agent can complete the reversible preparation without interrupting the user, then perform the already authorized release against verified state.
Keep the security claim proportional to the evidence
After the exercise, the justified conclusion is that the tested workflow preserved the selected files, used the intended account, detected a stale deployment, and verified the corrected page. It would be too broad to conclude that the entire workstation is secure or that every future release is protected. Security evidence has a scope, a configuration, and a time.
That proportionality makes the result more durable. Future maintainers can repeat the same checks after a tool upgrade, identify which assumption changed, and extend the verification where needed. A bounded claim is not weaker engineering. It is a claim whose meaning is clear enough to test, maintain, and rely on during the next real task.
Keep a small owner and review date beside the verification record. When nobody owns a boundary, configuration drift tends to become invisible. A named maintainer can decide when a platform upgrade, new connector, changed workspace root, or broader release permission requires another focused check. This turns security verification into ordinary maintenance instead of a one-time ceremony whose results gradually lose their connection to the running system.
Sources and further reading
- OpenAI sandboxing
- OpenAI agent approvals and security
- OpenAI legacy cloud Internet-access documentation — explicitly labeled legacy; do not apply its setup assumptions to every current cloud surface.
- GitHub Actions security guidance
AI-assisted editorial disclosure: this article replaces a truncated local draft. Primary OpenAI documentation was checked on October 30, 2026. The asset inventory, capability matrix, fixture design, incident process, and review checklist are original operational recommendations. They are not a security certification, a claim of universal isolation, or evidence that a particular user's machine has passed these tests.