Risks associated with automatically shrinking TempDB as a SQL agent job?
There are a lot of common misconceptions when it comes to tempdb and shrinking databases.

For starters, if tempdb grows beyond 350 GB, it's because it needs to. With that kind of size growth, I'd say there's an ETL job or manual batches that aren't behaving well. You could fix that in a number of ways, the best of which are (matter of my opinion)


Fix the queries that are eating up your tempdb: look for huge Hash Match or Sort operations without proper indexes or even row versioning if you're doing Read Committed Snapshot Isolation.
Add more disk space. In most environments, this is just a matter of giving your SAN admin a call.


Normally, I would recommend putting tempdb on its own disk(s) and size the database from the start, so you'll avoid the autogrow thing entirely. Autogrowing by 10 percent is often really bad practice for two reasons:


When the database is small, autogrowth can be very frequent, and also not aligned with your physical storage sectors
With larger databases, the files will grow by quite a lot once they do.


Another issue with shrinking tempdb is that SQL Server keeps a lot of stuff in there, preventing it from shrinking. You'll find that even if you try to shrink tempdb, it just won't, unless you pretty much restart the server (either literally or by clearing all sorts of buffers, both of which can have a dramatic impact on your production environment).

In summary


Don't autoshrink, make sure there's enough space from the start.
Consider sizing tempdb from the start so it won't have to autogrow.
See if you can tune those queries that are filling your tempdb. They'll probably also be the ones that take the most time to run.