Reviewing GitHub and integrated AI tools

The work I did

I assessed GitHub environments and governance over integrated AI tools. The reviews covered identity and access management, privileged access monitoring and secure repository configuration, including controls around responsible use and unauthorised code changes.

My contribution was the control review. I have kept repository names, actual configurations, client findings and confidential workpapers out of this portfolio.

Start with the environment

For a review like this, I’d want to understand which organisations and repositories are in scope, who owns them and how the environment connects to the rest of the development process. That context gives the access and change-control questions something concrete to work against.

I’d then trace who can join, what permissions they receive, who can change the configuration and what evidence supports the review of elevated access. The right questions depend on the environment and the control requirement, rather than a generic list of settings.

Configuration and operation

A configured restriction is one piece of evidence. To understand how a control operates, I’d also examine relevant changes and approval records for the period being reviewed.

For example, if the requirement is that a protected change receives authorised review, I’d want to understand the configured rule, any permitted exceptions and what happened for the changes selected for testing. The workpaper needs to connect those pieces to the conclusion.

When an AI tool is part of the workflow

An integration adds permissions and data flows of its own. I’d map what it can read, what leaves the environment, how it is authorised and whether it can propose or perform changes.

• Who can enable the integration, and who approves its use?
• Which repository content or other information can it reach?
• How are its permissions reviewed when a user, repository or use case changes?
• What approval is required before a proposed change becomes an accepted change?
• Who handles a reported failure or an exception to the agreed controls?

Those questions help keep the review grounded in the actual use of the tool. I wouldn’t infer an effective control simply because a product describes a security feature.

How my training connects

I’ve completed ISO/IEC 42001 lead auditor training. It covers AI management systems, including risk assessment, lifecycle governance and human oversight. That training gives me a framework for discussing ownership and controls around an AI use case.

A separate example you can read

The work samples include a fictional internal knowledge assistant. It retrieves information from approved policy documents. I use it to show proposed questions about data access, prompt injection, accuracy, action permissions and change control.

The example is a new portfolio illustration. It doesn’t report an engagement I performed or tests I completed for a client.

Read the AI review sample→

What I would want the review to leave behind

A clear account of the scope, the control requirements, the evidence examined and the remaining questions. If a finding is confirmed, the proposed action should connect to that finding and identify who is responsible for following it through.

For me, that is the useful part of the review: making the basis for the conclusion understandable to the people who need to act on it.