The Rule of Two for AI Agents in CI/CD

AI coding agents are crossing a new line.

They no longer just complete code in an editor. They comment on pull requests, read issues, start tests, inspect diffs, open files, call tools, and run inside GitHub Actions or other CI/CD environments. They are becoming part of the delivery pipeline.

That is useful.

It is also a different security category from autocomplete.

This week, Microsoft Threat Intelligence described a case involving the Claude Code GitHub Action. The technical details matter for security teams, but the more important lesson for product and engineering leaders is simpler: an AI agent that processes untrusted input, can access secrets, and can communicate externally is no longer a harmless assistant. It is an operational actor with blast radius.

That is where a simple rule becomes useful.

An agentic workflow should never hold all three capabilities at once:

• processing untrusted input;
• accessing secrets or privileged credentials;
• performing external communication or write actions.

Two of those may be acceptable in specific situations. All three together are dangerous.

That is the practical Rule of Two for AI agents in CI/CD.

Why CI/CD Agents Are Different From Local Assistants

A local coding assistant usually works in a loop that a developer can observe directly.

It opens files, proposes changes, asks for approval, and maybe runs tests. If it does something strange, there is at least a chance the developer notices. Not always, but the loop is close.

CI/CD is different.

A pipeline runs automatically. It often has access to environment variables, build artifacts, package registries, deployment keys, cloud roles, or GitHub tokens. The point of CI/CD is that it can operate without constant human handling.

When an AI agent enters that environment, the question changes.

It is no longer only:

“Can the agent complete the task?”

It becomes:

“What can the agent do if the task has been influenced by an attacker?”

This is not a theoretical concern. GitHub issues, pull request descriptions, comments, commit messages, README files, and log output can all contain text that the model processes. Some of that text may come from people outside the team. To a human, it looks like project context. To an agent, it may act like an instruction.

Once the agent can use tools, text can become action.

The Mistake: “The Agent Is Only Reading”

Many risks start with the wrong mental model.

Teams often treat AI workflows as static automation:

“The bot reads the issue, writes a suggestion, and posts a comment.”

That sounds small.

In reality, the workflow may include much more:

• reading repository contents;
• running shell commands;
• inspecting artifacts or logs;
• seeing environment variables;
• using API tokens;
• calling external URLs;
• posting comments;
• changing branches or pull requests.

Each capability may be legitimate. Together, they can become a chain.

The problem is not that AI is malicious. The problem is that an agent uses language as working context. If untrusted input sits inside that context, the agent may treat something as a valid instruction even though it did not come from the team.

Traditional CI/CD security assumes that code, configuration, data, and credentials have separate roles. Agentic workflows blur those roles because language can be both data and control.

That is why a better prompt is not enough.

The architecture has to prevent a successful prompt-injection attempt from automatically reaching credentials, write access, or exfiltration paths.

The Rule of Two as an Architecture Principle

The Rule of Two is not a magic security solution. It is a simple workflow design principle.

An AI agent should not simultaneously:

1. process content from untrusted sources;
2. reach privileged secrets or tokens;
3. write, post, send, or communicate externally.

If a workflow must read untrusted input, it should run with minimal permissions.

If a workflow needs secrets, its inputs should be tightly controlled.

If a workflow can post externally or write back to the repository, it should not see sensitive data that it could accidentally or manipulatively leak.

That forces a healthy separation.

For example:

• An agent may analyse a GitHub issue, but not run with production credentials.
• An agent may generate a code change proposal, but not push directly to protected branches.
• An agent may start tests, but not read deployment secrets.
• An agent may summarise security findings, but not post raw secrets into comments.
• An agent may inspect logs, but only redacted or scoped logs.

These boundaries can feel inconvenient at first. In serious products, they are the difference between productive automation and a quiet security risk.

What This Means for Founders and CTOs

Many companies will not start by putting AI agents into their most critical systems. They will start with things that seem harmless:

• automated pull request reviews;
• issue triage;
• test suggestions;
• documentation updates;
• release notes;
• small bug fixes;
• internal tools for support or operations.

That is a reasonable starting point.

But even these workflows touch real systems. They run in real repositories. They read real tickets. They may see real tokens. They influence real decisions.

For founders, product owners, and CTOs, the most important question is not whether Claude Code, Codex, Cursor, Copilot, or another agent is “good enough.”

The better question is:

What authority does this agent have inside our delivery system?

An agent that only proposes a local patch is in a different risk class from an agent that runs in CI and responds to issues from external users. An agent that only comments on a diff is different from an agent that can run commands and write results back to the internet.

Capability is one side of the decision. Operational responsibility is the other.

A Practical Checklist for Agentic CI/CD

Before connecting AI agents to CI/CD, GitHub Actions, or deployment-adjacent processes, teams should make a short and honest inventory.

1. Which Inputs Are Untrusted?

Not every piece of text in a repository is trustworthy.

Check whether the agent reads:

• GitHub issues;
• pull request descriptions;
• comments;
• commit messages;
• external logs;
• customer tickets;
• support messages;
• generated documents;
• README or configuration files from third-party repositories.

If an agent reads that content, design the workflow as if a manipulated instruction may be present.

2. Which Secrets Are Reachable?

Many CI/CD environments have more access than teams realise.

Check for:

• GitHub tokens;
• OIDC tokens and cloud roles;
• package registry credentials;
• deployment keys;
• API keys;
• database URLs;
• monitoring or logging access.

The agent should only see what the specific task requires. “It happens to be in the environment” is not a security model.

3. Where Can the Agent Write?

External communication is not only HTTP.

Check whether the agent can create or modify:

• issue or pull request comments;
• branches;
• artifacts;
• uploaded logs;
• package releases;
• Slack or ticket comments;
• webhooks;
• outbound network calls.

If the agent can see sensitive data, the team needs to control whether and where that data can leave the workflow.

4. Who Approves the Next Step?

Agentic workflows need gates.

Not every step must be manual. But critical transitions should be explicit:

• from analysis to change;
• from change to merge;
• from merge to deployment;
• from internal note to external communication;
• from read access to write access.

A good workflow makes the fast path easy, but not invisible.

5. What Gets Logged?

If an agent is part of the delivery pipeline, the team needs a record of what happened.

At minimum, it is useful to know:

• which prompt or event started the run;
• which files were read;
• which tools were executed;
• which secrets or roles were available;
• which changes were produced;
• which external actions happened;
• who approved the final step.

Auditability is not only compliance. It is debugging for organisations.

Why German Teams Should Be Especially Careful

In the German market, software is often closely tied to trust.

Mittelstand teams, B2B SaaS companies, regulated businesses, and internal product teams work with customer data, operational processes, contract logic, role models, and long maintenance horizons. A security incident is not just a technical problem. It quickly becomes a trust problem.

At the same time, the upside of AI-supported development is real.

Teams can refactor faster, write more tests, improve documentation, understand legacy code, build internal tools, and validate product ideas earlier. Ignoring that because of fear would be a mistake.

But putting agents into delivery pipelines without a plan is also a mistake, even if the demo flow looks impressive.

The right answer sits between those extremes:

Use AI agents, but give them architecture.

The Productive Compromise: Speed With Blast-Radius Design

A good AI delivery workflow is not maximally free. It is deliberately bounded.

That may sound slower, but it often creates more usable speed. Teams lose less time to unclear reviews, unsafe automation, broken builds, late security discussions, and “who approved this?” moments.

A productive setup may look like this:

• agents run in isolated environments;
• untrusted input is separated from privileged steps;
• secrets are minimised per workflow;
• write permissions are tightly scoped;
• network access is limited;
• critical actions require explicit approval;
• generated changes go through normal tests and reviews;
• architecture rules live in the repository;
• logs show what the agent did;
• the team knows who owns the workflow.

That is not a brake on modern software development. It is the condition that makes modern software development dependable.

Where McDougall Digital Can Help

At McDougall Digital, we treat AI-supported software development as a delivery architecture question, not just a tooling question.

The important questions are:

• Where does an agent genuinely accelerate product work?
• Where does it need access to code, tickets, logs, or deployments?
• Which permissions are actually necessary?
• Which decisions should remain human-owned?
• Which controls belong in CI/CD, tests, reviews, and operations?
• How does the system stay maintainable after the first burst of excitement?

We help teams review existing AI coding setups, remove unsafe workflow patterns, and introduce agentic development in a way that fits the product, architecture, security requirements, and operating model.

The goal is not to make AI agents timid.

The goal is to give them exactly the right responsibility.

The next generation of software teams will not only code faster. They will need to learn how to place automated collaborators safely inside real delivery systems.

The Rule of Two is a good place to start.