The user that created the enrollment isn't stored as part of the enrollment Object within Canvas. That means that the only way to know who the person that created the enrollment was is to look at some kind of log of the transaction.
One log that is kept within Canvas is the user page views. If I add an enrollment to a course, an entry gets written to my page views. The view that gets added, though, is actually an API call, even though I made the user was added through the web interface. For example, it was <instance>/api/v1/courses/<courseID>/enrollments and the User Agent shows up as "User-Generated" rather than the Chrome 97 that normally appears. I do know know whether an API call made outside Canvas is logged in this way, but it wouldn't show user-generated and it would be for the user that your token belongs to, so it should be possible to distinguish a system-added enrollment vs a user-added enrollment.
When you get an enrollment for an API, it contains the timestamp of when it was created and when it was updated. You could use those along to restrict the times on the user page view endpoints to find out whether a user added someone to the course. The problem is that you would need to know all of the users that potentially could have added someone to the course -- or at least the one that you suspect added them -- and then iterate through all of those, looking for a match.
A second kind of log is what Robert's ( @robotcars ) was talking about. Live Events is part of Canvas Data Services. When something happens in Canvas, you can get a real near time notification to an AWS SQS queue or a custom endpoint. It's an external log rather than internal and the contents cannot be retrieved within Canvas like the page views can be. Those notification messages include metadata and a body about the event.
There is an enrollment_created event that "... is emitted anytime a new enrollment is added to a course by an end user or API request." If you were monitoring the live events, you could get notified when this happens. Two immediate concerns arise with this that might affect you: (1) the events cannot be retroactively obtained, they are only sent from the time you turn them on forward and (2) it's a best one-time effort and if the event is unable to be sent (Canvas has too high of a load) or received (network issues or the queue is down), it's lost.
Part of the metadata with that request is the user that made the request. This would let you know whether it was your API process or someone else (and how that someone else was). With this technique, there is no trial and error or iterating through page views to find the user, it's given in the event's metadata.
A better way might be to keep track of the students that you enroll through the API and then the ones that aren't in your list were added by someone else. If you have a SIS that has a list of the students that are supposed to be in the course, that could be your source for ones that were added through the API.
