Hi @nbarnes,
I've never seen an account "1" that wasn't a root account, so I think your assumption is correct. On the flip side though (for curious users that may happen upon this thread), there are definitely root accounts that are not "1". The root account for my institution's instance happens to be "134".
One agonizing approach you could take would be to create a custom "EAB" admin role, starting it with full permissions. Ensure that works correctly with EAB. Then one-by-one (or maybe a few at a time) start modifying the permissions for that role, taking away things you don't want it to have (or things you feel it shouldn't need). Wait a few hours for the permission caching, then verify the EAB integration is still working. Repeat until the integration breaks, which means you've identified at least one of the permissions it absolutely has to have to function. Does this make sense to you?
Ideally, EAB would be able to tell you the exact API calls they are doing so you could look up which permissions are needed for them. At this point, vendors asking for a full root account API ley to function are going to face heavy scrutiny before we'd even consider installing them at my institution. They are unlikely to get approval unless we hear a very compelling argument form the application vendor.
-Chris