Ideally there should be a regression or "hardening" sprint before the project ends, and in the dream world, a hardening sprint every few cycles.
I'd suggest that automated tests of the steel thread of the sprint be developed as the sprint progresses, and any bug fixes get an automated test as well. This way, you build your automated regression as the development progresses with much less pain than manually re-running each manual test script for each new sprint. This also helps to deal with the common real-life situation where the regression/hardening sprints don't happen.
By focusing automation on the combination of steel-thread and known breakages, you're likely to be effectively regressing the most used and most fragile areas all through development, and can use any "found" time to add automation for any other areas you consider potentially risky.
I've also found it helps to prioritize potential breakages according to likely use frequency and impact - something that's likely to happen commonly and would take the application down if it broke should have a regression test to ensure that any breakage is caught before deployment.
In short, regression should be happening throughout the cycle as part of automated and unit tests, and continuously expanded to cover any new issues that arise as well as new steel-thread stories.