Scrum and\OR Kanban

We are currently following scrum but we almost never commit to the sprint scope and almost always end up adding small requests and items to the sprint backlog during the sprint.

That's fine. Scope would be a poor thing to commit to in a complex and uncertain world. Does the team have Sprint Goals to commit to instead, and if so are they meeting them? Scope should just be an emergent forecast of the necessary work.

I agree with Ian about not committing to scope for a Sprint. The team should be committing to a goal. There's probably some body of work that is necessary to achieve that goal that would be an implicit commitment, but even that body of work could change throughout the Sprint, as long as the goal is stable. As long as you leave enough capacity in the Sprint to account for this late-emerging work (along with things like planned and unplanned time off and other stuff), I don't see a reason why you can't keep adding work to the Sprint Backlog throughout the Sprint.

The thing that concerns me the most is that all of the work isn't visible on the Kanban board. I don't see why you couldn't apply a Kanban board to visualize all of the work. If you split the work up into two places, I'd be concerned with the impacts to transparency and visibility for the team and stakeholders. Everyone now has two places to go to look at the current state of work and get the information they need to make decisions.

I agree with everything that @Ian Mitchell and Thomas Owens have said.  I also want to ask how your team feels about the addition of another location to track work.  Based on my experience, every team I worked with wanted to have a single source of information for work, even if they were using pure waterfall.  Why would making the information and work tracking more complex be a good idea? 

You have your PSM I, so I ask you where in the Scrum framework is the mention to committing to a Sprint scope? And where does it mention that the Product Owner should decide how the Developers work?  Your idea actually makes the information less transparent and more difficult to order.  Would this technique help the team to be more predictive or more successful at delivering valuable increments of work on the product?

Adding to what has been said in the other comments, Developers and Product Owner are part of one Scrum Team, and the Scrum Team should work on improvements and/or impediments together. The Product Owner isn't empowered to decide all that on his own.

Actually, my first and foremost thought: might it be possible that communication between Product Owner and Developers should be improved? Possibly with the support of the Scrum Master?