# Connector Change Reviewer: An AI Agent That Flags Risky Config

The Connector Change Reviewer is an AI agent that reads diffs of integration configuration around a customer data platform (CDP) and flags risk before a person merges. It serves platform engineers at propose level (L2), commenting with a risk rating, new data flows and scope changes. It has no ability to grant, revoke, merge or deploy, and it never holds secrets.

Its rail is one application of [AI agent rails](https://privycdp.org/ai/rails). The surrounding change process sits in the [platform and data pipeline operations playbook](https://privycdp.org/ai/rails/functions/platform-operations).

## Rail at a glance

The Connector Change Reviewer's rail stops at comments. Redaction runs before the model sees a diff, and branch protection keeps the merge with a person, so neither limit rests on the prompt.

| Field | Value |
|---|---|
| Job | Read diffs of integration configuration and flag risk before a person merges. |
| Trigger | A proposed configuration change. |
| Data scope | Configuration diffs with secrets redacted, connector documentation and data classification. |
| Tool scope | Read: configuration diffs, connector docs, data classification; propose: review comments with a risk rating; execute: none, with no ability to grant, revoke, merge or deploy. |
| Output contract | Risk rating, new data flows, scope changes, and questions for the author. |
| Gate | A platform engineer merges or rejects. |
| Limits | Secrets redacted, and no deployment tools. |
| Ledger | Diff hash, findings, reviewer decision. |
| Evaluation | Seeded risky changes such as new destinations and wider scopes. |
| Owner and kill switch | Platform lead; disabling the review step leaves human review in place. |

## What it does and who uses it

The Connector Change Reviewer reads a diff with two questions in mind: where does data go now, and with what rights?

Illustrative run: an engineer opens a change titled "Upgrade CRM connector and add webhook". The diff adds a write scope to a connector that only reads today, a webhook to an unfamiliar host, and a mapping that sends `date_of_birth`, which the data classification marks as sensitive. The reviewer rates the change high and lists the new data flow. It asks which call needs the write scope, whether the host is a contracted destination, and what purpose covers date of birth. The author drops the scope and the field. A platform engineer merges the rest once the host is confirmed.

Certain patterns in a diff deserve a question every time, as this illustrative list shows.

| Pattern in the diff | Why it matters | Question for the author |
|---|---|---|
| New host in a destination or webhook | Customer data may reach a party with no contract | Is this host on the allow-list and the processor list? |
| OAuth scope wider, or a wildcard | A stolen token acts with whatever it holds; see the [Salesloft Drift case](https://privycdp.org/ai/7-things-ai-agents-should-never-do-with-customer-data) | Which call needs this scope? |
| New field mapped outward | Its classification may mark it as sensitive | Which purpose and consent cover it? |
| Secret reference moved, or replaced by a literal | A credential may leave the vault | Why is this not a vault reference? |
| Debug logging switched on | Payloads can land in logs with wider readers | Who reads those logs, and for how long? |

## Why this level

The Connector Change Reviewer stops at propose level (L2) because a comment is cheap to ignore and a merge is not. A bad comment costs a few minutes. A bad merge can open a data flow to a third party, and copied data does not come back.

Rule of Two analysis sets the design [1](#source-1). Pull-request text, commit messages and vendor documentation are untrusted, and configuration diffs reveal how customer data moves, so the session holds two properties. The third must stay out. Kudelski Security showed why in 2024: text in an AI pull-request tool steered its output, and the tool posted that output with its own token, which on GitLab could trigger actions such as approving a merge request [2](#source-2). So a separate service posts the comments, using a token that cannot approve or merge.

L2 is also its ceiling on the [rail levels](https://privycdp.org/ai/rails/rail-levels-autonomy-ladder). Auto-merging "low-risk" changes is tempting, but low risk is exactly what an injected description would claim. A fast path, if wanted, should be a deterministic pipeline rule owned by a person.

## Three ways it fails, and the control for each

Config reviewers fail by being talked out of a finding, seeing too much, or being trusted too far.

| Failure | What it looks like | Control |
|---|---|---|
| Injected text lowers the rating | A description or vendor document tells the model to call the change routine. | Rule checks set a rating floor: a new host or wider scope cannot score below high, whatever the model writes. The seeded set includes hostile descriptions. |
| Secret reaches the model | Redaction misses an unusual token format. GitHub's documentation, checked on 1 November 2026, says push protection blocks only supported patterns and can be bypassed [3](#source-3). | Scanning and redaction run before the model. A hit stops the review and alerts security, and the secret is rotated rather than merely removed. |
| A low rating read as approval | Engineers skim anything rated low, and console changes never appear in a diff at all. | The rating does not satisfy a merge check. Required human approval stays on the branch, new commits can dismiss stale approvals [4](#source-4), and each comment says it covers this diff only. |

## How to evaluate it

Seeded changes show whether a model adds anything beyond the rule checks, which is the only reason to run one here.

- **Catch rate on seeded changes,** by class: new destinations, wider scopes, sensitive fields and literal secrets.
- **Extra catches.** Count risks the model found and the rules did not. Few extra catches mean rules alone may be enough.
- **False alarms on benign diffs,** such as version bumps and comment edits.
- **Injection resistance.** Seeded descriptions should never move a rating below the floor.
- **Incidents traced to reviewed changes.** Check each comment history to learn whether the risk was missed, or flagged and ignored.

## Where it runs

Redacted diffs still reveal how customer data moves between systems, so the default is a private model, with an external one allowed only under masking and a contract that covers it. The [boundary architecture patterns](https://privycdp.org/ai/ai-agents-on-customer-data-inside-your-boundary) explain the trade-off. [PrivyCDP](https://privycdp.org/cdp) has an MCP-ready interface, though this reviewer is no part of the product.

## Related

- [AI agents for platform and data pipeline operations](https://privycdp.org/ai/rails/functions/platform-operations): the change process around this reviewer.
- [Access Review Assistant](https://privycdp.org/ai/rails/agents/access-review-assistant): reviews scopes already granted, not scopes being added.
- [Rail card template](https://privycdp.org/tools/agent-rail-card): a blank card for writing this rail down.


The [AI agent rails hub](https://privycdp.org/ai/rails) connects this reviewer to the other platform agents. Set your own rating floors and merge gate with the [rail card template](https://privycdp.org/tools/agent-rail-card).

Rail level: L2 · Risk: medium · Function: platform operations

By Art Kukharenko
Published: 2026-11-02
Updated: 2026-11-02

## FAQ

### Can an AI agent approve configuration changes?

This one cannot. It comments and rates risk, and a platform engineer merges or rejects. A model that reads untrusted text should hold no merge rights.

### What does it add beyond rule checks?

Rules catch known patterns, such as a new host or a wider scope. A model can link a field mapping to its classification and ask about purpose. Drop the model if rules catch nearly everything.

### Does this cover MCP connectors?

It can. A new MCP server or tool description is integration configuration, and tool descriptions have been a route for attacks, as the [tool-poisoning advisory from Invariant Labs](https://privycdp.org/ai/what-is-mcp-model-context-protocol-martech) showed in April 2025. Review them as you would any new destination.

## Sources

1. Meta, Agents Rule of Two, on keeping state changes out of this session: https://ai.meta.com/blog/practical-ai-agent-security/
2. Kudelski Security, vulnerabilities in the AI-powered PR-Agent (29 August 2024): https://kudelskisecurity.com/research/careful-where-you-code-multiple-vulnerabilities-in-ai-powered-pr-agent
3. GitHub, about push protection: https://docs.github.com/en/code-security/secret-scanning/introduction/about-push-protection
4. GitHub, about protected branches: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches


## Further reading

- [AI Agents for Platform and Data Pipeline Operations: The Playbook on Rails](https://privycdp.org/ai/rails/functions/platform-operations)
- [Cost Watcher: An AI Agent That Tracks Spend per Rail](https://privycdp.org/ai/rails/agents/cost-watcher)
- [Restore Drill Reporter: An AI Agent for Recovery Evidence](https://privycdp.org/ai/rails/agents/restore-drill-reporter)
- [AI Agent Rails: An Operating Model for Running Agents on Customer Data](https://privycdp.org/ai/rails)
- [AI Agent Rail Card Template: YAML, Spreadsheet and JSON Schema](https://privycdp.org/tools/agent-rail-card)