The Audit Log is not an actual audit log due to wrong actor names.

Hi Dave, 

You're absolutely right that Zendesk should never be used as the Actor when the event was the result of an action by a specific user. This is a blocker for any new events that we or other teams add, but unfortunately there are older events (done before the audit log was owned by the current team) where this is still the case. 

We create stories on our backlog when we see it or, or are made aware of it by other teams and users, and we will address it as part of our ongoing work and ownership of the audit log. 

Thanks, Caroline

I regularly see triggers misattributing actions to agents, as well. For example, one scenario I figured out is that if an agent updates a ticket with a macro that adds a tag, and the tag triggers a change a requester's language, the log says the agent did it, even though they did not, and may not even have the permissions to do so. Incorrect attribution is pretty alarming thing to see in an audit log and makes it very difficult to figure out what actually happened. 

Caroline Kello This is a serious security issue, do you have plans to address this? 

Hey CJ, we don't have a dedicated or concerted project planned to update and ensure the Actor is correctly attributed across all of the Audit log event. Our approach is the same as from my comment in April, that we address it as part of our ongoing work.

Looping back here as CJ raised the topic in a recent Announcement post related to Audit log and we should restart this conversation. I realize my previous comments here were dismissive and it's not my intention to pawn this concern off just because it was introduced before my time, for that I apologize. 

I'd like to better understand the full scope of what you're seeing. From what I can tell those are related to:

• Zendesk is incorrectly attributed as the Actor when an agent removes an email domain on the domains field of an organization
• The wrong agent is attributed as the Actor where macros add tags that fires a trigger. CJ, for this specific scenario can you help me understand who's attributed as the Actor? And what Actor would be accurate in this scenario?  

Are there more scenarios you're coming across where the wrong Actor is associated with the change? Would like to understand if there's a theme and we can go in and address Triggers as a whole for example, or if there's no pattern to where these show up. 

Hi Caroline, 

"The wrong agent is attributed as the Actor where macros add tags that fires a trigger. CJ, for this specific scenario can you help me understand who's attributed as the Actor? And what Actor would be accurate in this scenario?" 

The system is recording an Agent as having changed the language on a requester profile. Agents do not have permissions to do this. They should not show up in the log showing they have done things they do not have permissions to physically do, as they obviously did not do them.  As outlined in the feature request here, Zendesk has no method for recording when a change was triggered by a trigger or automation, so I'm not sure what Actor should be recorded. 

Here are more scenarios I've encountered: 

- Zendesk incorrectly marks whoever recovers suspended tickets as having created hundreds of accounts for users each day and having updated their email. It attributes roughly half of these to being done by "Zendesk", and half to the user, so even if you argue the user technically did do it, it's still doing something wrong here. 

- Zendesk records the wrong or no IP address for itself and agents regularly. 

- Zendesk has a problem in recording changes to triggers and automations, resulting in being unable to tell from the audit log what was actually changed accurately. The field names are returned as "" for all actions that are taken, with only the value remaining. This makes the log unreadable and unusable. 
 
- The audit log contains entries with no identifiable data as to what it is referring to. 

However, I would strongly urge you to re-read the post at the top and the linked documentation. The things they are calling out are a big deal and high level changes that really need to be implemented, even before the things I've laid out above.

>To be an acceptable Audit log, the actual actor who triggered the action being logged is required, not the name of the platform the log lives on. Also required are is the time stamp, type of action (create, modified, delete, etc), and object or data impacted.  

This is not happening. This is the number one most important thing you can do -- record all of these for all actions, and most importantly, do so in a secure, uniquely identifying manner of the actor.

Currently, you can trick the audit log because it records the actor's displayed name on the profile, as it appeared at the time of the action. So I can change my name to "Caroline Kello", delete all our macros, then change my name back, and guess who the log will say made that change? Same deal with the customer name, I can alter a customer name to  "John Doe", do malicious things to their profile, suspend them even, then change their name back, and there's no way for you find the changes in the audit log that were made to that user anymore. They are all recorded as changes to "John Doe" with no unique identifiers to be able to tell which profile it occurred on. And changes to a user's name, aren't recorded at all.  Because of this, there is no way to trace the changes and find the bad actor. 

I agree with CJ's post above and would also implore the Zendesk team to review the content of the original post as well as the linked documentation.

In case it has not been mentioned here explicitly before, the 'Actor' field can also sometimes contain a string of digits which we cannot logically associate with any user or system.

Hey Victoria, 

Thanks for chiming in. We're definitely reviewing comments and try to stay on top of new perspectives, hence me showing up as well!


If you have any specific events where that is the case, I would be glad to look into it more. 

I'm not quite as familar with the ins and outs of Audit logs as Caroline has been, but I'll do my best to understand and at very minimum surface to our team.