I think you are on the right track. You want the Player object to allow autonomous movement, but without putting too much knowledge about the "outer game mechanics" into it. A "grabbed" state inside the player does not fit to this design, and you are perfectly right: introducing such attributes which are only useful for exactly one use case will make the class less reusable and flexible.
One can solve this by developing a clear idea what fits well into a certain abstraction, and what not. That's what we call the responsibility of a class. In this case, you want the Player to be an abstraction for a physical game item - hence it makes sense let the player know only it's own physical properties (like velocity and position), and maybe some meta information (like a name or id), but not many more.
Since the game will allow changing velocity and position of a player "from outside", you need to give it getters and setters for both. Making a boss "grab" a player just sets the player's velocity to zero - no need to introduce an extra state attribute for this (of course, this comes for the price of having the player "forgetting" its former velocity). When the boss lets the player go, the game mechanics has to set new velocity for the player - but which velocity that will be is part of the game rules, nothing a player object should care for.
Still you can (ans should) implement all methods inside the Player class which can be implemented reasonably by making use of player's internal attributes, like your update method. I would consider to use a more expressive name for it, like moveAutomatically. Such a method fits perfectly into your player abstraction of a "physical item", and placing it there helps to keep your program well organized.
When your program grows, and you add more and more use cases to it, you will several times have to make a decision whether the Playerclass should be extended, or whether a certain functionality should be kept out of the class. When you stick to the responsibility you envisioned, this usually leads to some convergence - for the first use cases you implement, the class has to be extended and refactored, but at some time in the future, the class becomes "feature complete" and stable. Then new use cases can be implemented by simply reusing the Player's methods and attributes which are already there.