How to disable verbose logging by users?


I’ve looked in a few places but can’t find my answer:

I am wondering if there is a way to stop a user changing their logging level to “Verbose” and then pulling out sensitive values from the log files stored in AppData?

I know you can set individual activities to private, but this is a bit tedious for large workflows and it would be nice to be able to just set the log level during design or globally and disable the user from changing it at run time.

Note, I am not using orchestrator in this instance.

Sample of what I’m talking about:

Any ideas on how to do this?


Bump :slight_smile:

Might be worth taking a look a the nlog.config file if you can’t limit this within UiPath and changing where logs are stored to a secure environment.


When you say sensitive values, if you’ve got credentials etc. you should be using the get credentials or similar activities.

If you mean, membership numbers, phone numbers etc. then this should be discussed with your information security or risk and governance teams, as i dont think you can disable verbose logging. “Private” might be the way to go.

1 Like

@CBlanchard thank you for your reply :slight_smile:

These are good points and I’ve looked into the options you’ve mentioned. I think this will be determined by use case and data stored, like you’ve mentioned.

For anything that even computer admins shouldn’t see, I think private is the only way (otherwise admins could change NLog settings to local folder).

I noticed there is also a way to limit what gets output in “Verbose” mode by editing the UiPath.Executor.exe.config file, however it’s also susceptible to naughty admin issue. This can be done by adding logging profiles as explained here:

1 Like

Interesting points with the risk of admins accessing data they shouldn’t.

At my current company I am the only RPA dev here and we also have sensitive data.

Are you using attended automation or unattended?

If unattended, you should be able to get an email account created for your ‘bot’, then develop it only to kick off jobs via certain emails that get sent through or use a case management system and assign jobs to the bot. This way no one has to access the server, and you can lock it down.

Unsure what you can do with attended, I’ll have to have a think about that.

I am anticipating we would face similar sensitive data at my company. I’m trying to anticipate all vectors through which people might try and get data they shouldn’t, and admin rights was one of them.

Currently we deploy mostly attended automation with unattended in the works. I have started provisioning accounts for unattended, as I think it’s critical for logging, auditing etc. I’m looking at a windows account for a bot and then an account for each system it has access to. My hope is that this would give fully traceable automation through all systems that are touched in the process.

I think for attended you’d need to be able to encrypt the settings files for the logs, but I’m not sure this is currently supported (similar to Alternatively, you’d be able to set parameters per project during development that define logging behavior (which can’t be changed during runtime). However, this would mean you’d need to deploy a new version to debug properly and another to switch debug off. The goal for me is to be able to debug for a user and then switch out of debug and restrict logging easily and without deploying multiple packages.

It may also be possible to do this by adding some sort of “master” password for a project that is known to developers that can be entered at runtime to toggle debugging behavior. Similar to admin rights but for the project specifically and not the operating system.

It’d be interesting to know how other software practice handles this kind of situation. I guess maybe debugging is limited for a user in production and more open in dev/test environments. Do you have any experience in that kind of set up?

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.