Security
Audit Log
Overview
SoConnective keeps an immutable, tenant-scoped record of consequential actions in the audit-logs collection. It answers "who did what, in which account, and when" — for human operators, automated system actions, and AI alike — in a way that cannot be altered or forged after the fact.
The audit log is both a security control (a tamper-evident trail) and an operational tool (the data behind the admin Activity page).
What is logged
Each audit entry captures:
| Field | Meaning |
|---|---|
actor | The identity that performed the action |
actorType | One of ai, user, or system |
action | The action performed |
target | The record or resource acted upon |
summary | A human-readable description of what happened |
metadata | Structured context for the action |
Entries are tenant-scoped — every log line belongs to a specific account and is read back under the same tenant isolation as the rest of the system (see tenancy & data isolation).
Coverage includes, at minimum:
- Every AI Operator tool action — when AI operates a tool on a user's behalf, the action is recorded, attributed with
actorType: ai. - Every marketplace install — installing a module is logged.
The forgery-proof write path
Audit integrity depends on how entries are written, not just that they exist.
- Writes go through the service key with an explicit tenant. Entries are created using the server-only
PAYLOAD_SERVICE_KEY, and the tenant is set explicitly by the server rather than inferred from a client-controlled value. A client cannot write a log entry attributed to another account. createis restricted to the platform service account. No ordinary user — at any tier — can author audit entries directly. Only the privileged, server-side service account can create them.
Because the only way to write an audit entry is the trusted server path with an explicit tenant, entries cannot be spoofed into the wrong account or authored by a user pretending to be the system.
Immutability
The audit log is append-only:
- Updates are disabled. An existing entry cannot be edited.
- Deletes are disabled. An existing entry cannot be removed.
Once written, a log line is permanent. This is what makes the trail tamper-evident: there is no supported path — for a user, an agency, or even the platform through the application — to rewrite history.
The Activity page
The trail is surfaced on an admin-only Activity page. Administrators can review the sequence of actions taken in an account — human, system, and AI — without needing database access. The page reads the audit-logs collection under the same tenant scoping as everything else, so each viewer sees only the activity for accounts they are entitled to.
Why it is designed this way
| Property | How it is achieved | What it prevents |
|---|---|---|
| Correct attribution | actor + actorType (ai/user/system) on every entry | Ambiguity over who acted |
| Tenant integrity | Explicit tenant set server-side on write | Logging into the wrong account |
| Non-forgeable | create limited to the service account via service key | Users fabricating entries |
| Tamper-evident | Updates and deletes disabled | Rewriting or erasing history |
| Reviewable | Admin-only Activity page over audit-logs | Needing raw DB access to audit |