This is a summary of the TPM commands used for audit. See the TPM 2.0 specification Part 3 for the complete command set and API details:
• TPM2_StartAuthSession is used to start a session that can be used for audit.
• TPM2_GetSessionAuditDigest returns the session audit digest and optionally a signature over the digest.
• TPM2_GetCommandAuditDigest returns the command audit digest and optionally a signature over the digest.
• TPM2_SetCommandCodeAuditStatus determines which commands are included in a command audit digest.
The TPM library supports two audit types: command audit and session audit.
Command audit has two important traits, which it shares with TPM 1.2 audit.
First, it's on a per-command basis. Most commands include an attribute that, when set, indicates that the TPM should audit all instances of the command. There is a global, TPM-wide audit digest, and an auditor can request a signature over that digest.
Second, it's optional in the PC Client TPM specification. In TPM 1.2, to keep down development and test costs, vendors routinely ignored optional commands. Hardware 1.2 TPMs didn't implement command audits. Software can't rely on command audit being implemented in all TPM 2.0 devices. 
a tpM can be used as a certificate authority (Ca). as a hardware security module, it protects its private signing key far better than a software solution. a Ca might want a verifiable list of all certificates that it signed. By setting a command audit of the TPM2_Sign command, the auditor can verify the list of signatures and detect any tampering of the list.
the tpM commands are as follows:
• TPM2_SetCommandCodeAuditStatus: Make TPM2_Sign
• TPM2_Sign: uses the tpM as a Ca to sign certificates. the caller keeps an audit log.
• TPM2_GetCommandAuditDigest: gets a signature over a digest of the log containing the certificate hashes that were certified. the caller can use the signature to verify that the audit log has not been tampered with.
Session audit is new for TPM 2.0. It's mandatory in the PC platform specification, so it's likely to be widely available.
As the name suggests, session audit provides for an audit digest per session. An authorization session can additionally be used as an audit session by simply setting the audit attribute in each command to be audited. That is, a session doesn't become an audit session at the time it's started, but rather when it's used with the audit attribute set. For commands that don't require authorization, or to decouple audit from authorization, the audit session can be a separate session.
For example, TPM2_Create requires one authorization session to authorize the parent key. This session can also be marked as an audit session. Alternatively, a second session can be included with the command, this one marked for audit. TPM2_GetCapability requires no authorization and is normally used with no sessions. However, a session can be used for audit.
A command with multiple sessions can mark only one as an audit session.
-  TPM2_GetCapability with the parameter TPM_CAP_COMMANDS retrieves a list of implemented commands.