The short answer is: Nothing. It just works!
To go back a bit further. I just found an interesting post on the MSDN forums, which asks why the agent still works, even when the PAT token from VSTS is already expired or has been revoked.
The answer is simple and makes a lot of sense. Because of security reasons, they don’t want to save the token on the agent. The PAT token is only used for registering the agent on the agent pool on your TFS or VSTS. After that the token is not used anymore.
To quote the original answer from the Microsoft Employee
“That’s normal and desired. For security reasons, we don’t want to persist your PAT on the agent machines. The PAT is only used to register the agent. Upon registering we generate a JWT token specifically for that agent which only has permissions to listen to the queue. That JWT token is encrypted / stored securely and has limited rights. The build machine uses that JWT token to listen to the queue. When the server runs a build, it generates another time bombed (life of the build) token which allows the build machine to get sources and write back to VSTS / TFS. The token represents to a collection or project level service account (see options tab on definition). That token is never persisted and only held by the agent and available to tasks. There is also an option to expose that token to ad-hoc scripts (ps1, cmd, sh). If you use agent config.cmd remove, that’s why it will prompt you for the PAT again. Because we didn’t store it. That’s the one down side. But, you can always remove the agent from the web UI and wack the agent folder if you’ve revoked the PAT.”
And this should also tell you, that you only you need to worry about a valid PAT token, is when you configure your agent with the given config script. In this case every time!