Splitting 1 large object into 2 tightly-coupled ones - good, bad?

Question

I have a complex object (call it BusinessLogic) which provides an RPC interface to semi-trusted users. The functions in the RPC interface have to decide which procedure to call, check authorisation for that function, perform some argument checking, and then call private functions to carry out the required functionality, and then return results to the caller.

I decided to implement this by having the RPC functions in a separate stateless object (call it AppInterface), to separate out the concerns somewhat, so that BusinessLogic just moves its own data around and AppInterface decides which methods on BusinessLogic to call to implement the functionality it exposes.

This works very well for the most part. However it feels a bit wrong to me. The BusinessLogic object has benefited from not having to worry about authorisation, argument checking, etc, which is good. But since the AppInterface implements all of its functionality in terms of BusinessLogic, it can just be a thin wrapper for some procedures (which makes me question its necessity) and is a complex wrapper in other procedures (which makes me wonder whether that complexity should be pushed back into the BusinessLogic, given that the BusinessLogic has all of the information needed to perform the task). It also means that AppInterface needs access to methods in BusinessLogic that would otherwise be private as nothing else uses them; think friend functions in C++. Finally, it means I can't effectively unit-test AppInterface without using a full BusinessLogic object as that is the only practical way to get valid output.

I am happy to leave the system as it is, as it works, but I am curious as to whether there are obvious improvements I can make to such a system.

(For what it's worth, I am using Python 2.7, in a primarily object-oriented style.)