This scenario appears a bit constructed to me.
1. Escrow:
Shortterm escrow services are usually used to mediate a payment between two parties, providing a tie-breaker to make sure the payee fulfills the paid service, and payer pays services rendered. I don't see what need someone might have that requires relinquishing control of his money to a third party just to withdraw within minutes. Hence, it seems contra intuitive that an "escrow" service would exist that facilitates deposits and withdrawals of a payment at such a frequency. A similar situation might be constructed with an exchange, though. They don't usually guarantee payout times as far as I know, though.
2. Confirmations:
If the payee is waiting for at least one confirmation, the payer must be under the influence of a Sybil attack and fed false blockchain data, or the attacker must create an alternative blockchain tip that orphans the block the payee relies on for the confirmation. Either way, the attacker must create at least one block before the withdrawal which would constitute quite an investment.
3. Attack is easily countered:
In the situation that a client wants to withdraw back immediately, the "escrow" would create a transaction using the transaction output of the deposit transaction as input. That way, the client would get their money back reliably if it was paid, or the withdrawal would fail, if their money never arrived in the escrow's wallet.
How many confirmations to wait?
If I were offering an "escrow" service, I'd be implementing it via 2 of 3 multisig addresses. The three keys would belong to Payer, Payee, and Escrow. As the address would be unique to the involved parties, payments would be sourced from the deposit anyhow.
Depending on the amounts involved and the quality of my business relationship with the involved parties, I'd wait at least between one and four confirmations before I'd pronounce the payment as received.
