Certificate interception
A security appliance re signs traffic and the client refuses it. Reported as a generic network error with no detail.
How-to — — by Mahmoud Zalt
Diagnose an AI coding assistant that will not connect on a corporate network, identify which traffic is filtered, and make a request your IT team can actually approve.
There is one test that settles this in two minutes. Tether the laptop to a phone and try again. If the assistant connects on the hotspot and fails on the office network, you have your answer and nothing in the product needs changing.
That single result also changes who you talk to. A network restriction is owned by your IT or security team, and no amount of reinstalling, signing out, or changing accounts will move it.
If the outcome you actually need is the work rather than that specific editor, say so early. An AI employee can take a scoped task and return the result, and Sistava supports configurable models behind it. Confirm the current options in the employee configuration before you build a dependency.
Certificate interception is the most common cause. A security appliance decrypts outbound traffic and re signs it with an internal certificate, and any client that pins or strictly validates certificates refuses the connection. The editor reports a network error and gives no hint about the cause.
Long lived connections are the second. Assistants stream responses over websockets or similar persistent channels, and proxies that buffer or time out idle connections cut them. The symptom is a response that starts and stops, or a completion that never arrives.
Category filtering is third. Many appliances now have a category for generative AI services, and it is switched on by default in a lot of deployments. That produces a clean block at the domain level, sometimes with a corporate block page.
Authentication flows are fourth. Sign in opens a browser window to an identity provider, and blocked pop ups or a filtered callback leave you in a loop with no message at all.
A security appliance re signs traffic and the client refuses it. Reported as a generic network error with no detail.
Streaming responses die on a proxy that buffers or drops idle connections. Answers start and never finish.
The appliance has a category for AI services and it is on. A clean domain level block, often with a block page.
The identity provider window or its callback is filtered, leaving a login loop with nothing to read.
Security teams decline vague requests because they cannot scope the risk. These steps produce a request that is specific enough to say yes to.
The objection is rarely about the tool and almost always about source code leaving the perimeter. An assistant that reads a repository to answer a question is, from a data governance view, an outbound transfer of proprietary code to a third party.
That is a legitimate concern and it deserves a real answer rather than an argument. Which repositories, which endpoints, what retention, and whether the vendor trains on submitted content are the questions that decide these requests.
Approach it that way and the conversation is short. Approach it as a blocked website and it stalls, because nobody can sign off on a request they cannot describe.
If the exception is refused, that is a real answer and not a dead end. The constraint is the corporate device and network, so the useful move is to get the work done somewhere that is already approved.
Plenty of the work behind this search does not need repository access at all: a migration plan, a test matrix, a review checklist, documentation, a script against a public interface. Those can proceed without an exception.
For the rest, a hosted AI employee that produces work you review before it lands keeps the code inside your perimeter while still moving the task forward. Check the current model options in its configuration so you can answer the security question honestly.
Tether to a phone hotspot and try the same account on the same laptop. If it connects on the hotspot and fails at the office, the restriction is local and your IT team owns it.
Certificate interception usually looks exactly like that. A security appliance re signs traffic and the client refuses it, and clients rarely surface the real reason.
A proxy buffering or timing out a long lived connection. Streaming answers need a persistent channel, and inspection proxies frequently cut it.
Do not route around a security control. It is usually a policy violation, it hides the real problem from the people who can fix it, and it can put your employment at risk. Make the request instead.
An allow list for the endpoints the vendor publishes, inspection bypass only where certificate pinning requires it, plus a clear statement of which repositories are in scope and what leaves the network.
Because source code reaching a third party is an outbound data transfer they have to be able to describe to an auditor. Answer the retention and training questions and the request becomes reviewable.
Yes. Plans, test matrices, review checklists, documentation, and work against public interfaces need no repository access and no exception.
Any hosted tool needs network access, so ask the same questions and bring the same evidence. Check the employee's model configuration so you can answer the data path question precisely.
Treat this as a network conversation rather than a product one. Prove it with the hotspot test, capture the evidence, bring the published endpoints, name the data path, and ask for the narrowest exception that gets you working.