A Hash Is Not a Transcript
When support signs in as you, every request is written down: who, as whom, which route, from where, and a fingerprint of what was submitted. A fingerprint rather than a copy, deliberately — a log that could be read back into your data would be a second copy of it.
Our take, first
Support access is the permission nobody negotiates and everybody grants. It is in the contract, it is necessary, and the honest position is not to pretend it does not happen but to make it leave a trail the customer can read. What follows is a description of exactly what that trail contains and — more usefully — what it does not. The single design decision worth arguing about is that the record of what was submitted is a fingerprint rather than a copy. That choice trades the ability to reconstruct a support session against the refusal to keep a second copy of your data in a log table, and we would make it the same way again.
Somebody from support signing in as you is the most powerful thing that will ever happen to your account, and in most systems it leaves a single line saying it began.
The feature has an ugly name — impersonation — and it exists for a good reason. A customer reports that a screen shows the wrong figure. The screen depends on their permissions, their workspace, their configuration and their data. Reproducing it from outside is guesswork; seeing it is a minute.
So the ability exists. The question is what it leaves behind.
One row per request, not one per session
The distinction matters more than it sounds. A session record tells you support was in your account for eleven minutes on Tuesday. A request record tells you which forty pages they opened and which four forms they submitted.
Every web request made while an impersonation is in progress writes a row. Here is the whole of it.
| Recorded | What it answers |
|---|---|
| The impersonator | Which member of staff, by account |
| The target | Whose identity was being used — a user or a supplier portal login |
| The workspace | Which organisation the request belonged to |
| The guard | Which login system, so a supplier session is not confused with a staff one |
| Method and route name | Whether this was a read or a change, and to which part of the product |
| The path | Which page or endpoint |
| IP address | Where from |
| User agent | On what |
| A payload fingerprint | For a change, a hash of what was submitted |
| The instant | When, to the second |
The table is indexed four ways: by impersonator, by target user, by supplier login and by workspace, each with time. That is what makes it an evidence trail rather than a log file — you can ask "everything this member of staff did, ever" and "everything that was done to this account, ever" and get an answer to both in the same time.
Nothing is logged when you sign in yourself
The writing is conditional on an impersonation being in progress, so this table contains support access and nothing else. Your own use of your own account does not appear in it. That keeps the table small, keeps it fast to search, and — the point — means every row in it is a row somebody outside your organisation should be able to justify.
The fingerprint, and why it is not a copy
When the request changes something — a create, an update, a delete — what was submitted is hashed and the hash is stored. Not the values. A fixed-length fingerprint from which nothing can be read back.
The reason is worth stating plainly, because the alternative is superficially more attractive. A log that recorded the submitted values would let you replay a support session exactly. It would also be a second copy of your data, held in a table nobody thinks of as containing customer data, retained on a different schedule, backed up separately, and shown on an audit screen to whoever can see audit screens. Every protection you have applied to the original record would have to be applied again to its shadow in a log, and in practice it never is.
A log you can read your own data out of is your data, wearing a name that stops people treating it that way.
So the fingerprint is the deliberate answer, and it is more useful than it first appears.
-
Fields are sorted before hashing
Two submissions of the same values produce the same fingerprint even if the browser sent the fields in a different order. Without that, an identical submission could hash differently and the comparison below would be worthless.
-
So identical actions are provably identical
Two rows with the same fingerprint submitted the same thing. That is enough to establish a repeat, a retry, or a pattern across sessions — without anybody reading a value.
-
And a specific claim can be tested
The genuinely powerful property. If you have a record and want to know whether a support session set it to that value, the submission can be reconstructed, hashed, and compared. A match is strong evidence. This works because you already hold the data — the log adds the confirmation, not the content.
-
An empty submission still hashes
A form posted with nothing in it produces the hash of nothing rather than a blank. So "submitted an empty form" and "did not submit a form" are different rows, which is the kind of distinction that matters exactly once and then matters enormously.
Before any of that, fourteen field names are stripped out — passwords, tokens, secrets, one-time codes, recovery codes, the multi-factor secret. Twice, through two different mechanisms, on the same list. Those never reach the hash, which means a fingerprint cannot be attacked by guessing a password and checking whether it matches.
What the trail does not contain
Three limits, each real, and stating them is the point of publishing this at all.
What was typed
Recoverable only by testing a guess against the fingerprint. This is the deliberate trade described above and we would not reverse it.
The query string on a read
The path is recorded and the query string is not, so a report opened filtered to one employee logs as the report and not as the filter. On a screen whose whole purpose is filtering, that is most of what was looked at.
Requests outside the web session
The recorder runs on web requests. An interface that authenticates differently is a different path and is not covered by this table.
Who, as whom, when, from where, and to which route
All recorded, on every web request, indexed from both ends.
Whether a change was made at all
Recorded — the method distinguishes a read from a write, and the fingerprint is present only on a write.
The middle one is the most interesting and the least obvious. Reading is the commonest thing a support session does, and a filtered report is the commonest way to read a lot at once. An entry saying somebody opened the payroll report is meaningfully different from one saying they opened it filtered to a single named employee, and the trail records the first.
The bug where looking made the thing look different
One story from building this, because it is the best illustration of why support access is harder than it looks.
Signing in stamps a last-login time on the account. That stamp feeds a workspace-activity view — the one used to tell an active organisation from a dormant one.
An impersonation is a sign-in. So every time anybody looked at a quiet workspace to see whether it was still being used, the act of looking stamped it as used.
A dormant workspace looked active the moment anyone looked at it.
The fix is delicate for a reason worth understanding. The marker saying "this is an impersonation" is written into the session after the login event fires on the way in, and cleared before the login on the way out — so at the exact moment something would want to check, the session cannot answer. A separate flag is therefore raised around the identity swap itself, purely so a listener can tell a support sign-in from a real one.
The general lesson generalises well beyond this product: an audit mechanism that shares a code path with the thing it audits will eventually record itself. It is worth checking, of any monitoring you own, whether its own activity appears in its own figures.
How long it is kept
Two years, and then deleted. The policy is active rather than sitting switched off waiting to be chosen, which is the right default for this particular table for two reasons that point the same way. A support-access trail that is kept forever accumulates a permanent map of who looked at what, which is itself sensitive. And two years comfortably outlasts the window in which anybody asks about a support session, which in practice is measured in weeks.
What AWRA OpsHub does today
- A row per web request made during an impersonation, rather than a single record that a session began.
- Both identities on every row — which member of staff, and whose account they were using — plus the workspace and the login system involved.
- Method, route name and path, so a read is distinguishable from a change and both are attributable to a part of the product.
- IP address and user agent on every row.
- A sorted, hashed fingerprint of what was submitted on any create, update or delete, so two identical submissions are provably identical and a specific claim can be tested against a value you already hold.
- Fourteen sensitive field names stripped before hashing — passwords, tokens, secrets, one-time codes, recovery codes and the multi-factor secret — applied twice through two mechanisms.
- An empty submission hashed rather than left blank, so submitting nothing is distinguishable from not submitting.
- Four indexes covering impersonator, target user, supplier login and workspace, each with time, so the trail is queryable from either end.
- Nothing written for an ordinary sign-in, so the table contains support access exclusively.
- A separate marker raised around the identity swap so that a support sign-in does not stamp the account's last-login time and make a dormant workspace read as active.
- A two-year retention policy on the trail, active by default rather than awaiting configuration.
More we can add to your workspace
- The query string on a read, so a report opened filtered to one named person is distinguishable from the same report opened whole. This is the largest of these by value.
- A notification to the workspace owner when a support session begins, so the trail is something you are told about rather than something you go and look at.
- A field-level record of what changed during a support session, naming the fields altered without storing their values — the middle ground between a fingerprint and a transcript.
- Coverage of interfaces that authenticate outside the web session, so the trail is complete across every route into the product rather than the one support actually uses.
- A customer-initiated approval before a support session may start, turning contractual access into access granted per occasion.
- A plain-language summary of a session for the customer, rendering forty rows of routes into the sentence a person actually wants.
Where we point you to a specialist
- Payload records stay as fingerprints rather than plaintext values, and that is a position we hold rather than a staging post on the way to storing them. A log that can be read back into your data is a second copy of your data, held under a name that stops people protecting it as carefully as they protect the original.
- Where a regulator requires a specific form of access log for a class of record — a health record, a statutory register — that requirement governs the design and we will implement it rather than offering our general-purpose trail as equivalent. Establishing which regime applies to you is a question for your own advisers.
- We would decline to make the trail editable or deletable by anybody, including us, ahead of its retention window. An audit record that the audited party can remove is not an audit record, and the two-year deletion is a scheduled policy rather than an action available to a person.
The query string on a read and a notification when a session begins are the two that change what a customer can see about support access. Both are contained pieces of work against a table that already exists.
From a trail you can request to a trail you are told about
Everything above is a record that exists and can be produced. The work worth scoping moves it from something a customer can ask for to something a customer is handed.
Told when a session starts
A notice to the workspace owner at the moment support signs in, rather than a record they would have to think to request.
The filter on a read
Recording the query string alongside the path, so viewing a report filtered to one person is visible as exactly that.
Which fields changed
Naming the fields altered during a session without storing their values — most of the value of a transcript, none of the second copy.
We publish scope, not dates.
Scope support-access visibilityFive questions for any vendor about support access
Can your staff sign in as one of our users?
A good answer sounds like
Yes, and here is what it leaves behind.
What ours actually is
Yes. Almost every hosted product can; the ones that say no are usually describing a policy rather than a capability, so follow up on what the system enforces.
Do you log the session or every request in it?
A good answer sounds like
Every request.
What ours actually is
Every web request, with method, route and path. This single question separates a real trail from a line in a table.
Is what was submitted recorded, and in what form?
A good answer sounds like
A clear answer either way, with the reasoning.
What ours actually is
A sorted hash on any change, never the values, with fourteen sensitive field names stripped first. Be as wary of a vendor storing plaintext payloads as of one storing nothing.
Can we see the trail without asking you for it?
A good answer sounds like
Yes, here is the screen.
What ours actually is
The record exists, is indexed by workspace and target, and is produced on request. Being told at the time is on the list above as work we can commission.
How long is it kept, and can anyone delete it early?
A good answer sounds like
A stated period, and no.
What ours actually is
Two years, then deleted by policy. Not an action available to a person, which is the half of that answer worth insisting on.
Ask for the trail before you need it
The best time to find out what a support-access record contains is a quiet week, not the week you have a question about a changed figure. If you would like to see what your workspace trail looks like, or talk through what your own regulator expects of one, we are glad to.
Ask about support accessFrequently asked questions
Can support sign in as me without my knowing?
A session can begin without a notification to you today, and every request in it is recorded. Being told at the time rather than being able to look afterwards is a real difference, and it is on the list of work we can add rather than something we claim. What is not possible is a session that leaves no trace: the recording is not optional and is not something a member of staff can switch off for their own session.
Why store a hash instead of what was actually submitted?
Because a log holding submitted values is a second copy of your data in a table nobody treats as containing your data. It would be retained on a different schedule, backed up separately, and visible to whoever can see audit screens, and every protection applied to the original record would have to be applied again to its shadow. The hash keeps the useful properties — proving two actions were identical, confirming a specific claim — without creating that copy.
What can I actually do with a fingerprint?
Two things. You can establish that two submissions were identical, which finds repeats and patterns across sessions. And you can test a claim: if you believe a support session set a field to a particular value, that submission can be reconstructed, hashed and compared, and a match is strong evidence. Both work because you already hold the data — the log confirms rather than reveals.
Are passwords ever caught in the hash?
No. Fourteen field names are removed before hashing — password fields, tokens, secrets, one-time codes, recovery codes and the multi-factor secret — and the removal is applied twice through two separate mechanisms on the same list. They never reach the hash, so a fingerprint cannot be attacked by guessing a password and checking for a match.
Does the trail show what support looked at, or only what they changed?
Both, at different resolutions. Every request is recorded with its method and path, so reads appear alongside changes and you can see which pages were opened. What is missing on a read is the query string, so a report opened filtered to one named employee is recorded as the report rather than as the filter. On screens whose purpose is filtering, that is a meaningful gap and it is stated as one.
How long is the trail kept?
Two years, then deleted under an active retention policy. The period is a deliberate balance: long enough to outlast any realistic question about a support session, which in practice arrives within weeks, and short enough that a permanent map of who looked at what does not accumulate indefinitely. It is not something a person can delete early.
