You give an agent access to your site because you trust the controls around it, and the audit log is where you check that the controls did what you expected. So the log has a job before it has any content: whatever it records has to be true, complete, and readable, or reviewing it tells you less than you think. Three fixes in 1.6.2 are about exactly that, and none of them change what an agent is allowed to do.
The record has to name the true cause
When a call is blocked, the row that explains the block is the one place you go to understand why. If it names the wrong control, it does not just omit information, it points you at the wrong switch.
A write call blocked by read-only mode was being recorded as “high-risk locked.” Those are two different controls with two different fixes. Read-only mode is a blanket hold that keeps writes out of the toolset entirely. The high-risk lock is a separate gate on the money-moving WooCommerce abilities, the one that needs both a per-ability toggle and a Settings switch before a refund can run. If you read “high-risk locked” on a call that was actually held by read-only mode, you go looking at the WooCommerce gate, find nothing wrong there, and either conclude the log is lying or conclude the block was for a reason that never applied. Both readings cost you. The first makes you stop trusting the record. The second sends you to un-gate a control that was doing its job.
In 1.6.2 that row names read-only mode as the reason it actually was. The value of a cause-of-block field is entirely in its accuracy. A field that is usually right is worse than no field, because it invites you to act on it. If you want the two controls it was confusing, the security page walks through how read-only mode and the high-risk lock differ and why both exist.
Every path that changes state has to be recorded
An audit log is a claim about completeness. When you scan it, you are trusting that a governance decision you do not see is a decision that did not happen. That trust breaks the moment one screen writes rows and another does not.
Enabling or disabling an ability is a governance decision no matter which screen you make it on. The main settings save wrote an audit row for it. The same change made through the Quick Connect wizard, or through the bridge tab, wrote nothing. So an admin could turn an ability on during setup, and the log would carry no trace of when that happened or who did it, while the identical change on the settings screen was fully recorded. If you later ask “when did this ability become available,” the answer depended on which screen someone happened to use, and you had no way to know which one from the log itself.
That is the expensive kind of gap, because it is invisible from the inside. A missing row looks exactly like a decision that was never made. You cannot review your way around it. In 1.6.2 every path that toggles an ability writes the row, including a blocked enable attempt while read-only mode is on, which is itself worth recording because it shows someone tried and the control held. The point is not that more gets logged. The point is that the log now means the same thing regardless of where the change came from, so “no row” can be read as “no change” again. You can see the surfaces that make these changes on the features page.
A log you cannot read is not much of a log
The last property is the one people forget until they need the log in a hurry. A record that is technically complete but buried is not something you can act on, and denial rows are the easiest thing to bury.
A caller with valid credentials arriving from a blocked IP could keep trying, and each attempt wrote its own denial row. One source could push out a flood of near-identical entries, and the rows that mattered, the real actions an agent took, sat somewhere underneath them. When you open the log after handing out access, you are usually looking for a specific thing: what did this agent do, when did that setting change, is anything hitting the site that should not be. A flood of denials from one address does not add signal, it hides it, and it does that at exactly the moment you are trying to answer a question under pressure.
In 1.6.2 those denial rows are capped per source, the same way failed logins already were. You still see that the source was denied, because that is the fact you care about, but one noisy caller can no longer drown the rest of the record. Readability is not cosmetic here. A log you have to fight to read is a log you stop reading, and a governance record nobody reads is not governance.
The three fixes point at one property split three ways. A record earns trust by naming the true cause of what happened, by covering every path that can change state, and by staying legible enough to actually use. Get one of those wrong and the log quietly stops being evidence. If you want the rest of what shipped alongside these, the release roundup covers it: What we fixed in the 1.6.2 hardening release.