Audit logs¶
Venturi keeps an append-only, hash-chained audit trail of every consequential action in your tenant: administrative mutations, exports, access decisions, overrides, configuration changes, and support sessions. The trail is written to your object storage, write-only from Venturi, and read-accessible to your security team. Venturi has no delete or update path to it. This is the record your auditor reconciles against, and it is the substrate of Venturi’s SOC 2 control set.
The audit log is yours, not Venturi’s
The admin audit trail is written append-only to customer-controlled object storage. Venturi can append; it cannot rewrite history. An auditor can verify that property, the Object Lock mode, and the 5-year retention period directly from the storage configuration; they are enforced by architecture, not asserted in a contract.
What is recorded¶
Every security-relevant and consequential action emits an audit event. The set includes, at minimum:
| Category | Examples |
|---|---|
| Authentication | Sign-in, sign-out, every auth failure, MFA/step-up challenges, SSO-only enforcement, session revocation |
| Authorization | Every authorization denial, role and role-binding changes, custom-role authoring, delegation start/end, impersonation start and each impersonated action |
| Identity lifecycle | Invite, provision (manual/SCIM/JIT), suspend, deactivate, offboard, ownership transfer, recertification attest/downgrade/revoke |
| Provisioning | SCIM create/update/deprovision, IdP/SCIM configuration changes, credential and API-key rotation |
| Governance | Pricing, policy, and budget changes; manual attribution overrides; intervention lifecycle transitions; dispute resolutions |
| Data & exports | Export-job create and deliver; dashboard and report access; deployment-mode changes |
| Privacy | Erasure (crypto-shred) with deletion certificate; legal-hold placement and release; retention-compliance reports |
| Support | Break-glass request, approval, MFA evidence, every accessed resource, expiry, and revocation |
Each event carries a consistent set of fields: actor, action, target, timestamp, outcome, tenant, source IP where applicable, and a before/after where a value changed. Actor and subject references are pseudonymized (recorded as opaque, stable identifiers) so the trail remains useful for investigation while limiting personal data.
No prompt or completion content, ever
The audit log records that an action happened and who did it, never the
content of any AI request. Audit entries carry actor, action, target, and
details only, with a reference to the affected object rather than a copy of
it, and the normalized InvocationEvent schema has no field for prompt or
completion text. A content scanner checks every audit record before it is
persisted and blocks any record that contains prompt or completion text or
a credential.
Immutability and tamper-evidence¶
Audit immutability has three layers, and each one makes a different promise. An evidence packet names the deployed Object Lock mode and retention period rather than using “WORM” (write once, read many) alone.
| Layer | What it guarantees | Who can remove or shorten a record before it expires |
|---|---|---|
| Application: append-only | No product surface, API, or Venturi workflow edits or deletes an audit entry. Each entry carries the hash of the entry before it, so a removed, reordered, or altered entry fails chain verification. | No one, through Venturi. |
| Storage: Object Lock in Governance mode (default) | Every audit object is written under S3 Object Lock in Governance mode with a 5-year retention period. Locked object versions cannot be overwritten or deleted, and their lock settings cannot be altered, by ordinary principals. | Only a principal holding the s3: permission that also sends the explicit x-amz-bypass-governance-retention: true request header. Venturi’s writer and audit-retrieval roles never hold that permission. The account that holds the bucket controls every other principal: withhold the permission from routine roles there, and enable AWS CloudTrail data events on the bucket so any deletion or retention change made with it is recorded. |
| Storage: Object Lock in Compliance mode (selected at onboarding) | Root-resistant retention for deployments that require it: a locked object version cannot be overwritten or deleted, and its retention cannot be shortened, by any user, including the AWS account root user. | No one before the retention period expires, short of closing the AWS account that holds the bucket. |
Only an audit trail stored in Compliance mode can be described as undeletable by anyone.
Who holds the audit bucket¶
The trail is written to customer object storage, write-only from Venturi:
Venturi’s writer can append entries, and no Venturi role can update or delete
one. In self-hosted mode, the audit bucket is an Amazon S3 bucket that the
data-plane deployment creates in your AWS account, next to the data plane, with
Object Lock, versioning, public-access blocking, encryption under your KMS key,
and S3 server access logging to a separate log bucket. Your account’s
administrators therefore decide who, if anyone, holds
s3:, and they can verify the Object Lock mode and
retention period directly on the bucket. Because the lock is S3 Object Lock,
the audit bucket is always an Amazon S3 bucket. Audit entries survive a graph rebuild because they live on append-only
event topics, not in a rebuildable view, and the object store keeps its retention
independent of operational data.
This layered immutability is what makes the trail trustworthy for a repudiation defense: if an actor later denies a configuration change, an override, or an export, the append-only, hash-chained record settles it.
Retention¶
The audit trail is retained separately from operational data, under its own named lawful basis:
- Operational data follows the platform default of 13 months (a 12-month operational cycle plus one reconciliation period), or the tenant override you set, from 30 days to 5 years.
- Audit and override records are retained for 5 years under Object Lock, in Governance mode by default or in Compliance mode where you selected it at onboarding, so the compliance record outlives the operational clock. The evidence names the mode and the configured retention period.
When a data subject’s personal data is erased via crypto-shred (within 30 days, with a deletion certificate), the audit trail keeps only a pseudonymized, non-personal record that the action occurred, which is how the append-only audit log and the right to erasure coexist without contradiction. A legal hold can pin specific records, a subject, or a tenant scope so they are skipped by both the retention worker and the erasure pipeline for the hold’s bounded, reviewed duration; placing and releasing a hold is itself an audited, fail-closed action.
Reading and exporting the log¶
Your security team reads the audit trail directly from the object store and from
the audit-log viewer at Settings / Admin / Audit log in the
admin console. Typical uses:
- Investigate an incident: filter by actor, target, action, or time window to reconstruct exactly what happened.
- Review access changes: see every role binding, delegation, impersonation, and recertification decision over a period.
- Reconcile an export: trace a chargeback export back to its creation event, the actor, and the parameters used.
- Evidence a control: an Auditor grant gives time-boxed, read-only access to the trail and the evidence chain so a reviewer can reproduce a control end-to-end.
Reading the trail through Venturi is itself recorded. Venturi serves the audit-log viewer, the API, exports, Auditor grants, and support or break-glass sessions through a single audit-retrieval role. Each read, query, or export made through that role appends its own event (actor, scope, query, time, and result size) to the same hash-chained trail. The role has no permission to modify or delete a record.
Direct reads from your own bucket do not pass through Venturi, so the hash chain cannot record them. Your storage access logging records them instead. The self-hosted audit bucket ships with Amazon S3 server access logging enabled; enable AWS CloudTrail data events on the bucket as well for a record you can query and alert on.
The trail is also part of your tenant data export and is included in the final export at offboarding, so the compliance record leaves with you.
How it supports your compliance program¶
The audit subsystem is the backbone of Venturi’s controls posture:
| Standard | How the audit trail contributes |
|---|---|
| SOC 2 | The append-only trail is the evidence layer for access, change-management, and monitoring controls. SOC 2 Type I readiness/report target on our security roadmap with Type II targeted within 12 months; it is not yet held. See Compliance. |
| GDPR / CCPA | Auditable evidence of access, lawful processing, erasure (with deletion certificates), and legal holds, with personal references pseudonymized. |
See Security, privacy & compliance for the full controls posture and how to run a security review.
Next steps¶
- Manage who can read the trail in Roles & access control.
- Configure identity and policy events at their source in the admin console.
- Review the trust center with your security team.
Sign in to send feedback. Opens in a new tab.
Copy page details
Docs feedback: Audit logs
Page: https://docs.venturi.systems/administration/audit-logs/