On an Agile project defects are fixed as they are found, so no story should be considered complete if there are outstanding defects with it. But this does not mean that defects do not persist. A defect may be found that is not related to a story in the current iteration, or the customer may decide that the defect on a story is not worth the effort it would take to fix it and would prefer to focus on another story.
In this way a team can start to accumulate defects, which I classify as defect debt.
Defect debt is just like technical debt. It is behaviour that the customer has not asked for. In fact I would suggest that defects are technical debt, they generally exist because of the way code is working, or the lack of code to handle a situation. In some cases defects are not fixed as they are extremely difficult to fix, so the customer would prefer to focus the effort elsewhere. Often these defects would require significant changes to the code.
I suggest that defect debt should be handled in the same way as technical debt. Defects that will not be addressed immediately should be captured as separate cards and fixed whenever possible without impacting velocity. So when a pair is in an area of code that contains a defect, or a pair has some spare time at the end of an iteration. Of course if a customer decides a defect is important enough then they can schedule it for fixing and treat it like a story, but the team should make all efforts to reduce the amount of defect debt they create.