Monopam audit and compliance evidence
What changed
Every content update is versioned. Select a version to compare it with the one before.
Version 1 → 2
Update3 lessons updatedduration
Content update. Enrolled learners were notified.
Duration changed from 10 to 12 minutes.
Auditors rarely ask "show me the logs". They ask a concrete question about a person, a system and a period. Because Monopam brokers every session and every reveal, most of those questions have one right place to look.
| The auditor asks | Where the answer is | Not here |
| --- | --- | --- |
| Who accessed this server last quarter, who approved it and what did they do? | The server's session history, read together with its approvals and recordings: each brokered session is tiedbelongs to a named user, its approval and its recording is in `Recordings`, and the approval behind it is the matching request in `Requests` | `Live Sessions` shows only who is connected now. `Requests` alone has the approvals but not what was done |
| Who actually viewed or copied this password? | The audit event `Vault Revealed / Copied`, with the field name and the user | Opening the item's page is not a reveal |
| Which sessions were opened by an AI assistant, and what did it call? | The `AI` badge on sessions in `Recordings` and `Live Sessions`, plus one `MCP Tool Call` audit row per tool call | A session without the badge was not opened through the Monopam MCP server |
| Show me every access request in the tenant | `Requests` with the `Everyone` scope | The default `Mine` scope lists only your own requests and those waiting on you |
::diagram pam-evidence-map
Three details make these answers hold up.
**A reveal is recorded per field.** A vault item can have several protected fields, and the event names the one that was shown or copied. The value disappears from the screen after 30 seconds, but that is a convenience, not a control: it does not stop a screenshot. The evidence is the event.
**Tool calls are recorded whether they succeed or fail.** Each `MCP Tool Call` row carries the tool, the outcome and the arguments, with secret-looking argument values masked. An assistant runs with the permissions and policies of the user or identity behind it, so the badge tells you how a session was opened, not that different rules applied.
**The `Everyone` scope needs a permission.** An internal auditor who sees only their own requests and no `Everyone` toggle is missing `monopam.requests.full`. Being named as an approver does not grant it. The server enforces the same rule as the screen.
### Notes on recordings are not evidence
Reviewers can leave notes on a moment of a recording, `Shared` by default. Notes are review material. They are not part of the tamper-evident audit chain, an author can edit their own, and a super admin can delete anyone's but cannot rewrite it.
That matters when a note goes wrong. Suppose a reviewer pastes a production password into a shared note and leaves on holiday. A super admin deletes the note. Deleting does not rotate anything and the note may already have been read, so the password is treated as exposed and rotated. If the incident file needs the text, copy it before deleting.
> Tip: rehearse before the audit. Sign in with the account the auditor will use, open `Requests` and confirm that the `Everyone` toggle is there. A missing `monopam.requests.full` is easy to fix a week early and awkward to discover in the meeting.
Two questions come back at every audit: "what did this supplier do in our systems?" and "what happened at this location?". Monopam has a ready report for each, and one review process for supplier accounts.
### The vendor Activity Report
On the `Vendors` page, the row menu of a vendor offers `Activity Report`. Pick a period and use `Export CSV` or `Export PDF`. The file lists the connections made by that vendor's users with the user, email, resource, type, state, start time, last activity and whether the session was recorded. That is exactly the quarterly file an auditor asks for about one supplier.
The export itself leaves a trace: each one is written to the audit trail as a `Downloaded` event with the format, the period and the number of rows. So you can also show who took a copy of the report.
### The site report and its one trap
Every site has the same kind of activity report with the same exports. It answers "what happened at this location", but it is built from the **resources assigned to the site**, not from the gateway that carried a session.
A plant can therefore look silent on paper while being busy in reality. If the plant's gateways were assigned to the site but its servers never were, the gateways carry hundreds of sessions and the site report stays empty. Check the `Resources` count in the `Sites` list, assign the resources (`Advanced` > `Site`) and the report fills in.
::diagram pam-site-report
### Vendor access reviews
`Start Access Review` on a vendor asks the reviewer to decide on each of the vendor's external users.
| Decision | Effect |
| --- | --- |
| Approve | Access is kept. Nothing changes |
| Reject | The account is disabled and its live sessions are cut. The change shows within about a minute |
Tell reviewers this before they start. Rejecting a contractor who is in the middle of a maintenance window ends that work immediately. A user rejected by mistake can be activated again from the `Users` page. The start of a review and each disable are written to the audit trail, which is the proof that the review took place.
### A quarterly routine
1. Export the `Activity Report` of each vendor for the quarter and file it.
2. In the `Sites` list, compare the `Resources` count of each site with what you know is there. A zero next to a busy plant means an empty report.
3. Run `Start Access Review` for each vendor, and tell the reviewers beforehand that `Reject` cuts live sessions.
A record is only evidence if you know what it does and does not say. Three record types are easy to misread.
::diagram pam-record-limits
### Discovery runs
Each discovery run is kept in the run history, and its findings link back to it. Runs older than **90 days** are removed once a day. No setting changes that. The findings stay, they only lose the link to their run.
For compliance this means planning ahead. If next year's audit will ask for proof of every discovery run during the year, capture the run records while they exist, for example as part of a monthly control. Waiting for the auditor's request is too late for anything older than 90 days.
Reading the findings needs the same care:
| Finding | How to read it |
| --- | --- |
| A Unix account with uid 0 that is not in sudoers | A real administrator. uid 0 is always marked as administrator, whatever its name |
| `Exclude Built-in Accounts` is on, yet a uid 0 account appears | Correct. The option leaves out system accounts with low uids, but never root or any other uid 0 account |
| A sudo or wheel user shown as an ordinary account | An agent that cannot list administrators returns accounts without that marking instead of failing. The `Logs` rows show the warning |
| The run completed and an account is not listed | Not proof that the account does not exist. Check the `Logs` rows for that host first |
The last row is the one that hurts. A customer asks for written confirmation that a local admin account is gone because the last run did not list it. A completed run can still have skipped lines it could not read or lacked the administrator listing. Read the host's `Logs` rows before you sign anything.
### Machine reads of secrets
Pipelines and operators read secrets through machine identities, often every minute. To keep the audit readable, Monopam has a `Machine read audit window (minutes)` under `System` > `Secrets API`, 10 by default. Inside the window, a repeat of the same read by the same identity only raises a counter, and the next entry says how many reads it absorbed. Logins, writes and human reveals are always logged one by one.
If a regulator wants one record per read, for a payment pipeline for instance, set the window to `0`. Every read then gets its own row, and the audit table grows accordingly.
Reads and logins that come through the Vault-compatible API carry the suffix `(Vault-compatible API)` in the audit. That is how you tell a HashiCorp Vault style client apart from the Monopam CLI when both use the same identity.
### Database statements
The database proxy writes one audit record **per statement**, with the decision that was taken: allowed, blocked, masked or sent for approval. A statement that passed policy but failed at the database is recorded as a backend error. This is the evidence for "what did users run, and what was stopped". `Requests` holds only the approval requests.
By default the statement is stored sanitized: literals are replaced by placeholders, so you see `UPDATE customers SET email = $1 WHERE id = $2`. The option `AuditRawSql` stores the raw text including literals, from the moment it is turned on. Literals can contain personal data or secrets, so decide with the privacy officer, not alone.
> Tip: before you hand over any of these records, ask two questions about it. How long is it kept? What was grouped or left out? Run history is kept 90 days, machine reads are grouped inside the window, and statements are stored without their literals unless `AuditRawSql` is on.