An Access Token is a cryptographicly-signed key, allowing a system to identify and authorise itself. The most common format is called JSON Web Token (JWT). In the most common means of use, you open a browser, you login as yourself. An Access Token is generated representing you, this application, this session. That Access Token is then stored in your browser. Each web page you open uses it to generate some API calls after the fact. That is the normal case.
The abnormal case, however, is not as good. If that web page stores the token as a cookie, it may be intercepted. If it stores it in browser local storage, it could be scraped from the disk. Malicous JavaScript hosted on the same page might use cross-site-scripting request forgery to get access to it. How do you protect yourself?
Well, first start by using a set of best practices. Use a strong Content-Security-Policy. Secure your cookies. Use the XSS features. Use the PKCE Code Flow. Achieving this in your web application will make it much stronger, reducing the risk.
What if that is not enough? What if your data is more valuable, your app more risky than the average? Well, a new IETF draft (OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)) seeks to enhance, to lower the risk. The specification defines a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens.
Now, in a full Zero-Trust model, we would use client-certificates (mutual TLS) to identify the sender. However, in a typical web application this is not possible. So, they replace it with a private-key/public-key pair. The applicaton which generated the Access Token in the first place also has its own private key. Each subsequent use it signs in such a way the server can see who signed it, but that replace is not possible.
Now, this does not solve all attacks. In particular, a browser does not have a lot of options for secure storage of local secrets. So this private key could be stolen in the same way the access token is. But, it does protect against access tokens stolen by network sniffing, from caches, logs, etc.