This issue has occurred a few times, and it's very devious. It can be very hard to impossible to diagnose by the project admins, and it's caused by a very simple error. Here's how it happens:

1. User 1 is project admin in project A, but not in project B. He doesn't even have Browse Issues rights, so project B and its issues are essentially invisible
2. User 2 is project admin in project B, but not on project A
3. User 1 uses a Scrum board and starts a sprint
4. User 2 reports an issue in project B. That issue's Create screen contains the Sprint field, but User 2 makes a mistakes: He manually types in the wrong sprint, and inadvertantly add that new issue to the sprint for project A
5. User 1 attempts to close his sprint, but is met with a problem: He's not admin of project B. Since he doesn't even have Browse Issue rights, he's not allowed to see the name of the project this intruder issue belongs to.
6. User 1 is smart and goes in Issues and filters for issues belonging to his sprint, but since he has no Browse Issues rights, he doesn't see the issue that's out of place.
7. At this point, a JIRA admin has to get involved and must track down the problem. User 1 could not have found the problem, and user 2 couldn't have known about it until he was closing his own sprint and noticed the absence of an issue there.

If user 1 had been project admin on project B as well, the sprint would have closed without errors, but this would have been a worse outcome. User 2 would have had an issue disappear from his backlog because it would be part of a closed sprint, and user 1 would have weird sprint reports.

I see how this would be tricky to prevent. You would need a condition that "only issues that pass the filter for the board that created the sprint can be added to a sprint". Still, this seems like a huge problem area.