I would start with the question "Is this necessary to fulfill the intent of the backlog item?"
Yes?
Some items are obviously a Yes. For example, if you discover that you need to add an option to a feature for the story to work properly, then obviously this needs to get wrapped in. However, there are less certain ones. For example, if in doing work you discover you really should do a refactor to move a method into a different class, this is a matter of technical quality and should also be included in the story.
You should never decide if something is part of a story or not based on how much time you have in a sprint. That leads to cutting corners and mounting technical debt.
No?
The easiest way to know that something is not part of the current backlog item is to describe how this new item builds on the existing functionality. For example, let's say I have a user story that I would like to be able to enter some record information for a website order. After looking at it, someone says "Filling out that form is confusing. I wish we had mouseover tooltips on each field." That adds some new capability to the feature and should probably be its own backlog item. Now, if you have time in the sprint and the PO agrees, you can bring that item into this sprint, but it's still really its own thing.
There can be grey area here, but adding in small things that aren't expressly needed because they're quick or easy leads us to gold-plating, which has a while set of other problems associated with it.