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 still create confidentiality and decision risks, but it does not automatically have that control-plane authority.

That distinction matters when a team describes a coding agent as a productivity feature. If the runtime can edit a CI workflow and trigger a release, it needs the same care as other privileged automation. The extra concern is that issue text, source comments, or tool output may influence its next action.

I would begin the review with the credential and release paths. A prompt-injection test becomes much more useful once we know which downstream change it could cause.

The CI/CD Version Is Especially Serious

AI-assisted software delivery creates a concentrated version of this problem.

If an agent can read issues, summarize pull requests, suggest patches, edit code, trigger workflows, interpret test output, or prepare remediation changes, then untrusted development context can influence privileged engineering actions.

Issue text, pull-request comments, commit messages, logs, dependency metadata, generated artifacts, and documentation can all become part of the agent's working context.

If that workflow has broad repository permissions or access to CI/CD secrets, it crosses a software supply-chain boundary. GitHub's secure use reference explains why untrusted workflow inputs, token permissions, action pinning, and runner exposure need separate controls. Adding a model does not remove those requirements.

The control question becomes:

Can attacker-controlled text influence a system that can change code, expose secrets, alter workflows, or affect releases?

If yes, the agent needs to be reviewed like privileged automation.

MCP And Tool-Connected Agents Raise The Same Issue

MCP changes how tools are connected. The downstream service still decides which identities can read data or change production state.

The important boundary is where natural language turns into structured action.

A tool description, retrieved document, issue body, email, webpage, database field, or local file can influence what the model decides to do next. If the agent has access to tools that send messages, modify records, update tickets, query sensitive data, run commands, or call internal APIs, the system needs deterministic controls outside the model.

A prompt should not be the only thing standing between an agent and a destructive action.

High-impact actions need explicit authorization, narrow credentials, server-side policy checks, human approval where appropriate, replay protection, logging, and a clear kill switch.

What A Serious Review Should Answer

Before an AI agent receives production access, the organization should be able to answer:

• What is the agent's system boundary?
• What identities, credentials, and tokens can it use?
• Which tools can it call?
• Which actions are read-only, write-capable, destructive, external-facing, or execution-capable?
• What untrusted content enters the context window?
• Can retrieved content or tool output influence later tool calls?
• Are high-impact actions gated by deterministic code or human approval?
• Can the agent cross tenant, customer, repository, or workspace boundaries?
• Can the team reconstruct every meaningful action after an incident?
• What is the maximum plausible blast radius if the agent is manipulated, misconfigured, or over-permissioned?

If these questions cannot be answered, the agent is not ready for the level of access it has.

What Good Looks Like

Assume a model will occasionally select the wrong action. The architecture needs to contain that selection before it reaches a privileged operation.

Good designs use narrow tool permissions, typed parameters, strong authorization outside the model, scoped credentials, trusted/untrusted context separation, high-impact approval gates, deterministic logging, and operational kill switches.

Keep the review package small enough that engineering can maintain it:

• Trust-boundary map
• Tool and credential matrix
• Abuse-case matrix
• Findings register
• Blast-radius assessment
• Pre-launch blockers
• Remediation roadmap
• Go/No-Go recommendation
• Artifact appendix

For example, a hypothetical remediation agent could prepare a branch and a patch while a separate release identity controls deployment. The patch reviewer must see workflow-file changes, dependency changes, and the exact commit approved for release. A green test result does not authorize a different commit or expand the agent's credentials.

Keep release authority explicit

Map the path from untrusted input to the production change, then remove authority that the task does not require. An agent that prepares a patch may need repository read access and a bounded branch write. It may have no reason to change branch protection, read deployment secrets, or promote the release.

Use the tool-permission guide to document those distinctions and the blast-radius review to inspect combinations. These are architecture recommendations, not a claim that every TARE workflow implements the controls described here.