The challenge you have found with the Tracer is that the Requestor needs to exist in order to attach the Tracer to it, but in authentication scenarios the (unauthenticated) Requestor is created in the same breath as the authentication activities that run.
Consider whether there is a way to emulate running the authentication activity from an existing requestor, but this may be infeasible if your implementation is in any way dependent on HTTP headers.
Other approaches you can try:
You mentioned needing to trace the "processes being called by it". If those are rules your team has introduced, design them in such a way that a specific combination of inputs (or clipboard state) can yield a predictable set of expected results. Then, build some PegaUnit test cases to run those rules - as standalone rules (not as part of your authentication sequence) using those inputs and assert that the expected results are actually attained. If the rules called by your authentication activity can be shown to behave as you expect for all known sets of inputs, then your authentication activity is more likely to work as a whole. Then you can re-run these tests over and over again.
Set the Logging Level on the authentication activity to DEBUG from Dev (or Admin?) Studio. If you can't trace, emulate execution or PegaUnit parts of your sequence, DEBUG logs for an Activity will at least log which steps in the Activity are performed. From this you can deduce what conditions must be true/false during execution to cause the Activity to jump do, say Step 22 immediately after Step 7.
Please post back your findings on what worked for you.