There is a concept of "steel thread" that we used back at one of my previous jobs where the user story itself is a specific requirement that has a very particular expectation. Anything outside of that particular expectation should be its own user story. The acceptance tests can then be focused and targeted to verifying that the user story's "steel thread" has been verified. This doesn't mean that there is only one acceptance test, but that the acceptance tests that are written cannot go outside of that limited scope of the "steel thread".

When you get to acceptance tests that defined what is NOT supposed to happen, that actually, in my opinion, should be its own user story.

For example, a user story may read:

"As a web master, I can configure widget B to display in one of the three primary colors of blue, red, and yellow"

A set of acceptance tests would be:

1. The web master has access to the configuration options for widget B
2. The web master has a selection list available of the three primary colors of blue, red and yellow
3. When the web master sets widget B to blue, it displays in blue
4. When the web master sets widget B to red, it displays in red
5. When the web master sets widget B to yellow, it displays in yellow

That would be it. If, however, you need to check and make sure no one else has those abilities, you should write a different user story to say:

"As a web user, I do not have access to widget B's configuration options"

And then write appropriate acceptance tests.

The bonus of this approach is the granularity of requirements so you can easily prioritize those stories you MUST do and backlog those that can wait and then maintain focus among your developers, testers, and product owners to ensure that the user story is completed in any particular iteration without any unnecessary bleed over.

There is a concept of "steel thread" that we used back at one of my previous jobs where the user story itself is a specific requirement that has a very particular expectation. Anything outside of that particular expectation should be its own user story. The acceptance tests can then be focused and targeted to verifying that the user story's "steel thread" has been verified. This doesn't mean that there is only one acceptance test, but that the acceptance tests that are written cannot go outside of that limited scope of the "steel thread".

When you get to acceptance tests that defined what is NOT supposed to happen, that actually, in my opinion, should be its own user story.

For example, a user story may read:

"As a web master, I can configure widget B to display in one of the three primary colors of blue, red, and yellow"

A set of acceptance tests would be:

1. The web master has access to the configuration options for widget B
2. The web master has a selection list available of the three primary colors of blue, red and yellow
3. When the web master sets widget B to blue, it displays in blue
4. When the web master sets widget B to red, it displays in red
5. When the web master sets widget B to yellow, it displays in yellow
6. The web master has no other options other than blue, red or yellow

That would be it. If, however, you need to check and make sure no one else has those abilities, you should write a different user story to say:

"As a web user, I do not have access to widget B's configuration options"

And then write appropriate acceptance tests.

The bonus of this approach is the granularity of requirements so you can easily prioritize those stories you MUST do and backlog those that can wait and then maintain focus among your developers, testers, and product owners to ensure that the user story is completed in any particular iteration without any unnecessary bleed over.

Edited: Added acceptance test 6 as an example of one acceptance test for "It shouldn't do this" that would be valid within a user story. The user story indicates the three primary colors. There should be no other options available. The user story does NOT mention anything about any other users, configuration options for any other widgets, or anything else like that so those are then relegated to different user stories.