Yes, if it runs inside your own network

Can an AI code review agent run with my self-hosted runners or firewall setup

Yes, if the agent can reach your repository, runner, and model endpoints. Self-hosted runners and firewalled networks work when you allow the right outbound paths, secrets, and webhook flow. GitHub supports self-hosted runners, including Kubernetes-based runners, and Azure DevOps also supports self-hosted agents, so the basic deployment pattern is normal, not exotic.

The part people get wrong is thinking the AI review agent needs broad internet access. It does not. It needs narrow, explicit connectivity to the systems it actually uses: the code host, the build or test runner, the model provider or local model service, and any storage it writes comments or artifacts to. If you can define those paths, you can keep the rest behind the firewall.

A self-hosted runner is the right fit when your code, secrets, or dependencies already live inside your network. GitHub’s runner model lets you place execution on infrastructure you control, and the same idea exists in other CI systems. The useful constraint is simple: the review job runs where your code already runs, then sends only the minimum data needed for analysis or feedback outward.

Firewall setup becomes the real decision point. If your environment blocks all outbound traffic, an external AI reviewer cannot call a hosted model, fetch repository metadata, or post a review. If you allow selective outbound traffic, the agent can work through a proxy, private egress, allowlisted domains, or a private network connection to an internal model endpoint. The setup is a networking task, not a product limitation.

The inconvenient part is that code review touches more than source files. A useful agent often needs pull request diffs, branch metadata, CI status, test output, and sometimes package or dependency context. If your firewall blocks webhooks, API callbacks, or artifact downloads, the agent may still start, but it will miss the context that makes the review useful. That is how teams end up with empty or superficial comments.

If you want this to work cleanly, start with a simple flow: self-hosted runner receives the job, runner fetches the diff, runner sends only the requested review payload to the model service, and runner posts the result back to the pull request. Keep the model endpoint reachable from the runner, not from every machine on your network. In practice, that means an outbound allowlist, token-based auth, and logs that prove what left the box.

The safest setup for regulated or private code is an internal model service behind the same firewall. Then the runner never has to send source code to a third party, and the agent can still review changes, summarize risk, and point out missing tests. If you choose a hosted model instead, read what data leaves your environment and make that a deliberate decision, not an accident hidden inside a CI job.

A good test is to cut the problem into failure modes. First, can the runner fetch the repository and run the job Second, can it reach the model endpoint Third, can it write the review back to the pull request Fourth, can it still work when your firewall changes, the proxy rotates, or a token expires Those are the checks that tell you whether the setup is real.

If you are deciding whether to use DevConnect for the human side of this workflow, the platform’s own positioning is straightforward: it is a free place to find people who test each other’s work, not a hosted CI product. You can use that exchange to get real feedback on the output of your review agent, while your actual code execution stays on your own runners. https://devconnectplatform.com

A firewall does not block intelligence, it blocks routes. Once you map the routes, the setup is workable: runner access, model access, webhook access, and secret access. If one of those is missing, the agent can still exist, but it will fail in a way that looks like bad AI when the real problem is network design.

The practical rule is this: yes, run it on self-hosted runners if you control the network, and yes, run it behind a firewall if you allow the exact traffic it needs. The system fails when people try to make it fully air-gapped while still expecting a hosted model, or when they expose more than the review job actually requires.

What you need to allow

Allow the runner to reach the code host API, the model service, and the destination where review comments are posted. If the agent also reads CI logs or test artifacts, allow those paths too. The tighter the allowlist, the better, as long as it still covers the full review loop.

What breaks first

Webhook delivery, outbound model calls, and PR comment posting are the first things to fail in a locked-down setup. If any one of those is blocked, the job may complete locally but never produce a review where developers can use it. That failure often looks like silence, not an error, so logging matters.

A concrete example

A team keeps source code inside a private GitHub repo, runs review jobs on self-hosted GitHub runners, and points the agent at an internal model endpoint. The runner can fetch the diff, inspect the changed files, generate comments, and post back to the pull request without opening inbound access to the network. GitHub documents the self-hosted runner model, and the same pattern is the reason private CI setups work at all.

The part that is inconvenient

A secure setup usually needs more coordination than a cloud-first demo. You may have to manage runner registration, network allowlists, token rotation, log retention, and proxy settings. That work is the cost of keeping code private while still using an AI reviewer, and it is the part teams underestimate when they only test the happy path.

When the answer is no

The answer is no if your firewall blocks outbound access and you are only using a hosted model, or if you need an agent that depends on APIs your network team will not allow. In that case, the fix is either an internal model endpoint or a narrower security design, not a hope that the agent will somehow work through a dead route.

Bottom line

An AI code review agent can run with self-hosted runners and a firewall, as long as you design the network paths on purpose. The code can stay inside your environment, the compute can stay on your infrastructure, and the review can still come back to the pull request. The hard part is not the AI, it is the traffic map.

FAQ

Does the agent need inbound access to my network No. The common pattern is outbound access from the runner to the code host, model endpoint, and comment destination. Inbound exposure is a separate security choice, not a requirement for the review loop.

Can I keep source code from leaving my environment Yes, if you use an internal model service or another setup that processes code inside your network. If you use a hosted model, then source or diff data leaves the environment by design, so that choice needs review before you ship it.

Will a self-hosted runner fix a bad firewall design No. A self-hosted runner only changes where jobs execute. If the job cannot reach the systems it needs, the agent still fails, just from inside your own infrastructure.

What should I test first Test the full loop in this order: fetch a diff, call the model, post the review, then repeat after a token refresh or proxy change. That catches the failures that matter before the agent starts reviewing real pull requests.