Let me see if I understand what your saying:
1) no transaction state is kept in the web server
So if I'm a bank app, the data to populate the account history table and the form post data to transfer money are not held on to by the web server? You'd have to go out of your way to hold onto that data, unless you had some output caching block on the account history.
Maybe my app is more complicated, and I have some type of long-running job, so I create a job class with all the job parameters, and stick it in Session, Redis, or plain App Memory Cache, while the client polls to see if the job is complete. You're saying don't hold onto the Job class, but just an identifier for the Job.
2) pass idempotent statements through the API with transactional identifiers rather than keep state
How is this done? If the user wants to move $200 from account_a to account_b, twice, how is that handled? Which service generates the transaction identifiers?
Set up routing such that the microservice cannot talk to any machine that isn't on the same subnet as the front end (perhaps some static route work will help)
Design the app so that no transaction state is kept in the web server, pass idempotent statements through the API with transactional identifiers rather than keep state.
Create logs using a separate service that can watch all traffic between the front end and the micro service by snooping the network between them. Make the only way to login to the logging server from a locally resident console terminal, have it send the logs to your network accessible system but internally provide triggering on suspicious activities.
Never allow "remote hands" service on any machine in a data center you don't own, install intrusion detection on every machine.
That is probably a start.