Agile is not a religion; there is no Agile Scripture; there are no Agile Priests.
should all user stories be linked to an epic, or could some stories stand independently on their own?
The basic answer to your question regarding "Must Use" is
No; at least, not in any formal way. As a matter of formality, the entire purpose of "Epics", "User Stories", "Scrum", "Story Pointing", "Acceptance Criteria", etc is to use as communication tools. If you are clearly communicating without one of them, then adding one of the ticketing concepts in would be a cost with no benefit. If you are not clearly communicating without one of them, then there are tools available for you to apply in an attempt to eliminate confusion and hopefully prevent miscommunications that lead to failed expectations.
The only relevant formal requirement here (assuming Scrum) is that you represent your work requests as user stories, that you have clearly defined acceptance criteria, and that you produce a story point estimate for implementing those acceptance criteria prior to work starting.
"Epics", "Features", "Tasks", "User Stories" are all implementation specific. Scrum is a framework for designing an agile process and your organization's agile process is going to necessarily be customized to your business' needs.
Your organization will have defined a standard for this and usually the implementation of a "Must Use" rule for this matter is a worthy attempt at eliminating the ambiguous null problem.
When seeing (null) with no other context, one has to decipher whether there was a mistake in the linkage (i.e. "This is supposed to be linked to an Epic but someone didn't") or if the absence of a link is intentional.
Without a "Must Use" rule, you typically have to capture this with a separate concept such as writing an explicit note or creating a
Noepic tag so that the absence is clearly communicated as intentional without requiring additional conversation. This additional rule would obviously have to be managed.
We implement a "Must Use" rule that all stories associate with Features and all Features are under an Epic but we enforce that somewhat loosely. The way we are able to enforce the rule is by declaring that User Stories are not ready for story pointing until they are complete and bundling beneath a Feature which itself is bundled beneath an Epic is a step required for completion. If a ticket is in our backlog without an Epic declaration, it is not a candidate for a story pointing conversation.
This way, there is no need for individual interpretation of the circumstances and less of a chance for failing to deliver.
That is consistent with the way we communicate with our clients.
"Agile" processes are just communication tools. There is no OneTrueWay to be Agile. If your organization is communicating well and you are adhering to the Agile Principles then your process is Agile.