Something controls the software that would ask for instructions, and that could be hacked. I'd also suggest a default of auto-reject after a minute, not auto-accept.
When people think about attack surfaces in devices they often think about the things making repeated connections out. The thing is, every piece of reachable mutable code in the device is an attack surface, not just the software making connections.
You may have heard of ATM car collectors that attach to real ATMs, or people that have hacked an ATM to collect cards. Your smart car connects to a number of systems throughout its life: your dealer's diagnostics, every time you charge, every time you play music through the bluetooth connection on your phone. Each one of these is a potential attack vector.
Let's say one of these things is using JAVA, and somehow does not have an updated log4j [1]. Now that thing can be used to compromise other subsystems of your car. And these attack vectors do not have the antivirus and other protections your desktop computer or laptop do.
As bizarre and backward as it sounds, I think the best bet is burned immutable firmware on a physical module that can be easily swapped out by an authorized dealer (or with a key of some sort to allow people to service their own cars). This would reduce the vulnerability quite a bit, though not eliminate it. It also would eliminate over the air firmware updates, which are insane in my opinion. It's kind of how if you want a more secure computer you burn a live CD with a minimal hardened distro of linux, rip out the hard drive, make sure you have a fast CD, and have the computer boot to CD. This is part of what I used to do for a DMZ PC. There's always a risk your firmware will be hacked, but that is harder, and can be checked on startup depending on what you have on the system [2].
[1] https://www.trendmicro.com/en_us/research/21/l/examining-log...
[2] https://crypto.stackexchange.com/questions/59965/tpm-and-rem...