AI Agents Are Becoming Part of the Production Control Plane

An agent becomes part of the production control plane when it can change the systems that operate a service: deployment configuration, repository permissions, cloud resources, workflow definitions or release state. A read-only assistant can create confidentiality and decision risks without having that production authority.

For a coding agent, trace the credential and release paths first. If its runtime can edit a CI workflow and trigger a release, an instruction in an issue or tool response may influence a privileged operation. The review needs to establish which change is reachable and what authorizes it.

Follow the patch into CI

Consider a remediation agent that reads an issue, prepares a patch and opens a branch. Source comments, dependency metadata, test output and documentation all enter its working context. Some of that material may be controlled by an untrusted contributor.

Now inspect what the branch can trigger. Does the agent's token permit workflow-file edits? Can its changes run on a runner with deployment credentials? Can it alter branch protection or approve its own release? A limited-looking patch workflow can reach much broader authority through those paths.

GitHub's secure use reference covers untrusted workflow inputs, token permissions, action pinning and runner exposure. Apply those controls to the actual workflow. The presence of a model does not change the trust level of a pull request or make its contents suitable for privileged execution.

Keep patch preparation separate from release authorization where the job permits it. The reviewer needs to see workflow and dependency changes as well as application code, and the release gate must bind to the approved commit. Passing tests for one commit does not authorize another.

Check the authority behind an MCP tool

An MCP tool called prepare_fix might write a branch, invoke a shell or call a deployment API. Review the implementation and credential rather than infer its limits from the name.

A tool description, issue body or returned log can influence the next model request. At execution, validate the target, parameters and current permission in code. A source file cannot grant release authority, and a model-generated statement that the user approved a change cannot satisfy the approval gate.

Include local process permissions and network access. A tool restricted to one repository may still run beside a broadly privileged cloud credential. If that credential is available to the process, it belongs in the review.

Test the intended limit

For the sample patch agent, define a narrow operating boundary: read the approved repository, write a task branch and open a review. Then try the adjacent operations that should fail: editing protected settings, reading deployment secrets, selecting another repository and promoting a release.

Repeat after revoking the agent's grant. Check queued work and active runners, not only the UI. If a stop control leaves a job running, record what authority that job retains and how its result will be reconciled.

A consequential operation needs a trace linking the initiating user, proposed action, authorization decision and downstream result. Preserve safe parameter fields and protected references without copying secrets into the log. An attempted release, an accepted deployment and a healthy production alias are different observations.

Keep the review next to the release configuration

Maintain a diagram of the input and execution paths, the tool and credential register, and tests for the denied operations. Link findings to the affected configuration and an owner who can fix or contain them. A short release decision should state the permitted operations and any remaining restrictions.

Use the tool-permission guide to define those operations and the blast-radius review to inspect their combinations. Expand access only after the team has tested the added authority and its stop path.