I love that idea! I've had a couple friends express interest, although I'm not sure I'm talented enough to set up a system for player-submitted AI. If the game doesn't work out, though, that's a really wonderful next-project idea :D
When it's time to make a move, you just call their URL and process the response.
I don't think games involve a lot of data right? So you could probably make it stateless by transferring the whole game each time.
If you want a hand with this I could probably help! Just reply here, and I'll drop you an email.
So I guess my to-do list now is: 1) Forgot password feature 2) B.Y.O.A.I. :)
Anyway, sounds like you don't need any help - good luck!
If your frontend is asking for the current game state (to render it) and sending control messages to modify it, then you don't need much else to allow people to write bots. All you really need to do then is make sure there's a way they can access the exact same API your frontend uses but with (e.g.) an API key rather than cookies.
It's a reasonable thing to do for the code anyway (and might be how it works now, I don't know). Bots then have the ability and knowledge of any human player, you don't need to run any code your side (which brings up issues with sandboxing) and people can write in whatever language they want.
What's tricky that I forgot to mention in the other comment is that more information is acquired as moves uncover fog-of-war tiles. So I've been sending a new request every unit-move, rather than once per player-turn. This is fine as the data being exchanged is so small and fast, but just something people might need to account for. I suppose I can also quickly whip up a system to grab all sequential moves from an AI service when fog of war is disabled and save some network traffic.