<aside> 📃

Background

This note comes from an internal request to connect AI to a source code repository for efficiency improvement. The proposal itself was not the concern. I wanted to understand the intended use case, how repository access would be controlled, and how the AI-generated security review would be performed and validated.

As the discussion progressed, the responses increasingly focused on one reassurance: the AI would not directly modify production data. That limitation is important, but it did not fully answer the earlier concerns around data scope, access identity, review criteria, evidence quality, human verification, downstream decision-making, or whether the capability could later expand from advisory output into executable actions.

The case was never primarily about whether AI should connect to a repository. From the beginning, what I concerned was how to describe and assess the complete control path behind that connection.

</aside>

Main Point

The main issue in this case was never whether AI should be allowed to connect to a repository. From the beginning, the AppSec concern was how to define and assess the full control path behind that connection, even though the discussion repeatedly narrowed the question to the connector, the expected feature, or the absence of direct production changes.

“HTTP interface,” “MCP,” “AI review,” and “human plus AI report” all describe different parts of the system, but none of them alone defines the security boundary.

• A transport or integration method explains how components communicate.
• A use case explains what the business expects the AI to do.
• A review report explains one possible output.
• A statement such as “it will not modify production data” describes one current limitation.

What we actually need is the full control path: which actor initiates the request, which identity reaches the repository, which data enters the model context, what analysis method is applied, what evidence supports the result, how the result affects the SDLC, what actions are technically possible, and how mistakes can be detected and recovered.

The important question is not how the AI connects. It is what data, identity, judgment, and authority cross that connection.

Why the Conversation Kept Missing the Real Question

The lesson is simple: broad questions such as “How do you ensure security?” are too easy to answer with feature descriptions. AppSec needs a stable set of dimensions so that each question targets one control layer at a time.

A Seven-Dimension Assessment Model

For AI systems connected to repositories, databases, internal APIs, cloud platforms, or other enterprise resources, I would use the following seven dimensions:

Use Case
→ Data
→ Identity and Integration
→ Method
→ Result and Decision
→ Action
→ Assurance

Together, these dimensions answer one complete question: