The first question to ask yourself is if this level of traceability is necessary. For some people, maybe the answer is yes. For others, perhaps not. If you don't need traceability between story and test, you can focus on better ways to measure test coverage and correctness.
The second question to ask is how you intend to implement automation. There are different strategies, each of which would lend itself to various methods of tracking the work. For example, requiring all necessary automation to be a completion criterion for the story is different than requiring test cases to be written but automation following at a later date. The person responsible for automation, either a developer, a test specialist embedded with the team, or a separate test automation team, also drives how you trace and track the work.
Ultimately, though, I consider the "trace changes to tests" to be a very different question than "track what functionality is and isn't tested".
Test coverage is an excellent first step toward identifying what functionality is and isn't covered. Depending on your tools, you may be able to combine coverage from different levels of tests to see what is exercised by unit tests, integration tests, and acceptance tests. Using coverage, you can identify what parts of the system need more tests.
However, coverage doesn't say anything about how good your tests are. Just because they cause lines of code to be executed doesn't mean they assert anything valuable about the code or its intended effects on the system. Peer reviews of tests and test suites can help with this. Mutation testing can also help provide insights into the ability of your tests to detect changes in the software under test and fail.
How you monitor coverage, carry out peer reviews, and otherwise assess the quality of your tests depends on who is responsible for creating and maintaining the test suite.