There are really several things going on here.
The first question is about determining what, if any, authentication is necessary for security testing. This really depends on your threat model. For example, the systems that I'm currently working with are scanned using various end-user credentials, but not with credentials associated with the level of permission that company employees have. We've decided that if there's a malicious internal user, the types of concerns would go well beyond what a vulnerability scanner can pick up. The focus is on making sure that end-users, with malicious intent or not, have limited opportunities to harm or bypass the normal operation of the system. This approach may or may not be suitable for all organizations, so it's up to each organization to determine the risks and benefits of different configurations for scanning and penetration testing.
The statement that the security consultant, whether using automated tools or by a manual process of interacting with the system, is changing the configuration such that the system doesn't function is concerning. First, the security consultant will probably need documentation about the system associated with whatever user role they are authenticating as. This has been a common request in all penetration tests that I've been a part of. This should help them understand what different things do in order to not break the system. Second, they should be testing against an environment that mimics production but is not production. In my experience, security testers do things that may break the system, including attempting to send malicious payloads. Security testing should never interfere with the normal operation of the system.
My suggestion would be that you spend some time performing threat modeling and working with your security consultant to understand the system so they can perform the appropriate testing based on the risks that you face so that any findings would be relevant.