What happens if a secure token is provided to a trusted party that gets compromised

There's not really enough information to determine the specifics here, but there are some general answers that can be provided.

In your scenario, the assumption by default should be that node A has had the ability to access and modify account X within the scope of the permission of its token. This is, generally, why tokens are usually limited to certain scopes, so that, for example, if node A needs to access directory information about account X, it cannot abuse that to also modify other information on the account.

This is also why automated tokens tend to be time limited—so that the abuse of account X by node A is limited to the life of its tokens—and why credential issuance is usually logged—so that any misuse can be easily determined and the extent of access can be readily discovered. If tokens are issued using sufficient entropy, it is also common to log their access using a hashed version of the token so that actions taken by a bad actor can be determined.

Whether, in this situation, it means that account X is compromised (that is, under the control of the attacker) depends on what data the attacker had the ability to access or modify, both due to the scopes and duration of the token and the design of the system. If, for example, the token grants the attacker the ability to do only cosmetic changes, like change personal names or avatars, then the account is, while potentially defaced, probably not compromised.

If your system permits the issuance of additional tokens to node A, then you may well provide it additional tokens. That, of course, depends on the design of the system.

To detect compromises, you will generally want to have some sort of automated measurements or metrics that detect indicators of compromise. What those are depend on the system. For example, if you know that nodes are generally only supposed to handle about 20,000 accounts per day, you may set up a dashboard or an alert to detect large numbers of issued tokens or tokens issued for many accounts, so you notice it's acting strangely. You may also monitor other indications of compromise, such as loading of additional kernel modules, unusual usage of sudo, or access from or connections to unexpected systems. All of this depends on what you know about your instances and systems and requires that you build in suitable metrics and monitoring that are appropriate for your scenario based on suitable threat modeling. You will need to balance good detection and prevention of threats with gracefully handling the occasional anomalous but harmless traffic pattern and avoiding major inconvenience for staff.