Before adding an approval step, find out what your agent can reach

A coding agent doesn’t need its own production credentials if it can use yours. A deployment approval can be perfectly implemented and still leave production exposed through another route. Before adding a human decision to the workflow, find out which routes the agent can already use.

Readers kept raising it under my recent LinkedIn post on enforcing approval outside the agent. One reader reported removing an agent’s email access after it sent draft content to an unintended recipient. Another reported an agent acting on an instruction intended for a different repository, despite separate dev containers; how that happened is still unknown.

A third commenter identified the deployment problem directly: an approval check on the deploy service can be bypassed if the agent can also use a kubeconfig that reaches the cluster. The suggested first step was to list what the developer’s laptop can touch. That is a useful starting point for the agent’s actual execution environment too.

Follow the credential to the system that accepts it

Consider an agent preparing a release. The intended workflow sends an image digest, service name and production target to a deployment service. That service requires approval. But the agent’s environment also has a usable Kubernetes identity with permission to update the same workload. A direct request to the cluster never reaches the deployment service, so its approval check never runs.

Whether that route exists depends on the real configuration: file access, authentication, resource permissions and network reachability. A kubeconfig file alone does not prove that a process can change production. Equally, putting the process in a container does not prove that the route has been removed.

Docker’s bind-mount documentation describes how host files become available inside a container, with writable mounts by default. Mounting a developer’s home directory can expose exactly the files the isolation was meant to keep out. Inspect the mounts and permissions the agent actually receives.

Two sandboxes using the same accepted credential can act under the same authenticated identity. A receiving service may apply additional device, network or session restrictions, but separate containers alone do not give it separate principals or separate permissions.

An inventory you can use

Start with the environment the agent actually runs in: its operating-system identity, mounted directories, available tools and network access. For each item below, record what it can reach, which identity the destination sees, what operations that identity may perform, and where those operations are checked. Record credential locations and permissions without copying secret values into the inventory.

Check how each tool resolves access. The AWS CLI documentation covers configuration and credential profiles, environment overrides and cached SSO tokens. Kubernetes documents how kubeconfig connects clusters, users and contexts. A familiar filename is a lead to investigate; the effective identity and its permissions are what matter.

Separate authority from influence

Some items in that inventory expose authority directly. Others let someone steer how the agent uses authority it already has. A shared instruction file does not grant permission to deploy. It can influence an agent that already has that permission. A browser session can provide an authorized route without the agent ever reading the underlying session token.

Keep both relationships in the inventory. For authority, record the resource, identity and allowed operations. For influence, record who can write the input and which privileged process reads it. This makes it easier to see a chain such as one agent changing a shared file that another agent reads before using a production session. It also avoids treating an unexplained incident as proof of a particular attack path.

The boundary has to cover human access too

The harder part is that the fix often belongs in access management and deployment architecture. If an agent can use the developer’s production credentials or authenticated sessions, changing its instructions will not remove that access. The same workstation may offer a guarded deployment workflow and a direct administrative route. Both belong in the review.

Give the agent the access needed to prepare the work. Keep the authority to perform the protected action behind an enforcement boundary it cannot change. That may be the target service itself or a broker whose downstream credential and configuration the agent cannot access. An emergency route needs its own enforced authorization and a separate access path; leaving it available in the agent’s environment recreates the bypass.

This does not require one physical server or one credential for the whole organization. It requires every available route to a protected operation to enforce the intended authorization. A short-lived credential can reduce exposure, but while it is valid its permissions still determine what the holder can do.

The same inventory applies to CI

None of this is specific to agents. A CI job is another actor whose environment can hold authority its workflow never names. Inventory it the same way: secrets available to every workflow in the repository, not only the gated one; the id-token: write permission, which lets a job request an OIDC token that a cloud trust policy can exchange for credentials, so there is no stored secret to find; the instance role of a self-hosted runner, which any job on that machine can use; and registry logins cached on runners that are reused between jobs. The ChainDrop analysis shows what happens when publishing authority sits inside that environment.

Then bind approval to the operation

For an action that requires human approval, the executing service must check the signed authorization against the target, action and parameters it will actually use. It must apply its trusted approver policy, enforce expiry and prevent reuse. For a release, bind an immutable artifact digest, the service and the environment. A changed destination or artifact must require a new approval.

Keep the approved values fixed through execution. For changes in one database, approval consumption and the change can share a transaction. External calls need their own retry and idempotency design: consuming an approval does not prove that the downstream operation completed. Nor does signing a requester’s description prove that the description accurately explains the structured parameters.

INTYGA provides human-signed approvals bound to an exact request and receipts the relying service can verify independently. Your integration owns the execution check, replay handling and removal of alternative access paths. The service-side approval walkthrough explains those responsibilities. The access inventory comes first because an approval receipt cannot close a route that never checks it.

Test the routes you found

Use a controlled test environment with representative permissions. For one protected action, try the intended service without approval, with a changed target or parameter, and with an already consumed approval. Then test the alternative route identified in your inventory. Confirm at the receiving service that it refused the unauthorized operation; an agent saying it could not proceed is insufficient evidence.

The result should name the boundary: this identity cannot update that workload directly; this session cannot send mail; this service refuses an operation without the required approval. That is more useful than a general claim that the agent runs in a sandbox.

Any route where you cannot yet name the boundary is where to start.