First and foremost: If the token is concatenated into a SQL query (without sufficient escaping), then yes, it can be used for SQL injection. Don't build queries by concatenation!
Tokens, by themselves, have no permissions; they are just identifiers. The app's logic determines what permissions to give the bearer of the token, but it's up to the app to enforce that, and a (successful) SQL injection bypasses such checks. Databases also have permissions (at least, the better ones do), and the app will have certain permissions on the database that determines what a query the app sends to the DB can do (and all that a SQL injection is, from the perspective of the DB, is a query that the app sent over). A very security-conscious app will use the Principle of Least Privilege (which says you should never give anything more permissions than are needed to do its task), such that (for example) a DB query that is supposed to be read-only will be made using a connection with read-only permission on the DB, and in such a case an embedded DELETE
subquery would indeed fail. However, in practice very few developers do this, and the app usually makes all queries using a connection with full permissions on the DB.
The permissions of the token-bearing identified entity (presumably a user of a web app or similar) have no bearing whatsoever on the permissions that the app has when talking to its database. In fact, since a SQL injection requires modifying the token, it's no longer actually the correct identifier for that user, so it definitely isn't going to be subject to user-specific access checks.