Audit
Studio runs as single-tenant SaaS in Altostrat’s AWS account; you don’t sign into our AWS console and you don’t query our CloudTrail. Audit visibility is split between what’s exposed in the application surface and what we hold internally and can produce on request:| Plane | What’s captured | Visibility |
|---|---|---|
| Application audit | Conversation transcripts, procedure run history, tool-call invocations, approval decisions, share grants, ownership changes, organization membership changes. | Encrypted in DynamoDB under the org DEK. Visible to organization members per the resource’s access scope. |
| AWS infrastructure audit | Every signed AWS API call: AppSync queries, KMS decrypt and rotation calls, Bedrock invocations, S3 presigned-URL issuances, Cognito credential issuance. | CloudTrail in the Altostrat AWS account. We retain it for incident investigation and produce evidence on request as part of a security or compliance review. |
| Identity audit | Sign-in attempts, MFA prompts, session creation, organization membership changes, SSO events. | Clerk’s audit log. We can produce relevant events on request; if your organization uses SSO, your IdP also has its own log. |
- Who ran a procedure against a host on Tuesday? Application audit (procedure run history) + the user’s session record.
- Why did a particular KMS decrypt fail? Producible from our CloudTrail on request —
KMS:Decryptevents carry the denial reason. - Did a user re-share a resource with another organization? Application audit (share-grant record); the corresponding KMS re-wrap call is also producible from CloudTrail.
- When did our DEK rotate last? Producible from our CloudTrail (
KMS:GenerateDataKeycalls against your CMK on the 30-day cadence).
What’s in a procedure run record
A single procedure run captures, encrypted under the org DEK:- The procedure’s identifier and version at execution time.
- The argument values supplied.
- The full transcript of the agentic conversation: prompts, model responses, tool calls, tool results, approval decisions, sub-agent activity.
- Timing and token usage.
- The final output and the success/failure verdict against the procedure’s success criteria.
What’s not in audit
The application audit deliberately does not record:- The plaintext of any encrypted field.
- The plaintext of any credential, even when one was used during the run.
- Background telemetry counters that aren’t tied to a user-visible action (those live in CloudWatch metrics, not in the per-user audit).
purpose: DecryptPurpose parameter — but the structured event emission keyed by (purpose, recordId, userId) is on the roadmap. Until then, decrypt events are recorded only at the KMS layer in our CloudTrail, where they’re producible on request but not surfaced inside Studio’s own audit views.
The user-facing audit surface
Inside Studio, the/audit slash command opens the recent action history for the current conversation: tool calls, approvals, model invocations. Cross-conversation organization-wide audit views are on the roadmap; for now, requests outside the per-conversation view are answered by us pulling the relevant CloudTrail and Clerk evidence on your behalf.
Telemetry
Studio sends two kinds of telemetry to third-party vendors. Both are designed for product reliability, both have aggressive content scrubbing, and both can be reduced or disabled.Sentry (error reporting)
Sentry receives uncaught exceptions, promise rejections, and explicitconsole.error calls from both the Electron renderer and the Go sidecar.
| Property | Behavior |
|---|---|
| What’s sent | Stack traces, the exception message, breadcrumbs of recent user actions (UI navigation, tool invocations by name only), the application version, the OS version. |
| What’s redacted before send | Authorization headers, password / secret / token / credential value patterns, private keys, and console messages matching sensitive-content patterns. Breadcrumbs drop request/response bodies. |
| Sample rate (production) | 10% of traces; 100% of session replays only when an error fires. |
| Sample rate (development) | 100% of traces; 100% of session replays. |
| Region | The Sentry endpoint defaults to the US Sentry region. |
Amplitude (product analytics)
Amplitude receives event-level analytics about which features are used.| Property | Behavior |
|---|---|
| What’s sent | Event names (e.g., “conversation.created”, “procedure.run.started”), event properties (counts, durations, tool categories), application version, OS, anonymous user identifier (per Amplitude session), is_electron flag. |
| What’s not sent | Conversation content, procedure bodies, host names, credentials, organization names, file content, tool arguments. |
| Session Replay | Configurable sample rate (default 10% production, 100% development). When enabled, Amplitude captures interaction events (clicks, navigation) without DOM contents of sensitive fields. |
| Region | Amplitude US data centre. |
Web analytics on the docs site
This documentation site uses Fathom and Google Tag Manager. They are scoped to docs.altostrat.io traffic — they do not run inside the Studio desktop app and they do not see your operational data.Disabling telemetry
Studio is a single-tenant SaaS — you don’t run your own copy, so per-customer telemetry toggles aren’t a configuration knob you turn. What we do support:| Telemetry | Today | If your posture requires more |
|---|---|---|
| Sentry | On for all installs at the production sample rates above. Sensitive-content scrubbing applies to every event. | An organization-level opt-out (no Sentry events emitted from your users’ installs) is on the roadmap; reach out if this is a blocker and we’ll prioritize. |
| Amplitude | On for all installs at the production sample rates above. No conversation, host, credential, or tool-argument content is captured. | Same as above — organization-level opt-out is the planned mechanism. |
| Web analytics on this docs site | Fathom and GTM, scoped to docs traffic only. They never run inside the Studio desktop app. | Standard browser controls (Do Not Track, privacy mode, content blockers). |
Data residency in audit and telemetry
| Surface | Region |
|---|---|
| Application audit (DynamoDB) | us-east-1. |
| AWS CloudTrail (Altostrat-side) | us-east-1. |
| Clerk audit | Clerk’s hosted region. |
| Sentry | Sentry’s US ingestion endpoint. |
| Amplitude | Amplitude’s US ingestion endpoint. |
us-east-1 form may not be the right product for you today. Multi-region availability is on the roadmap, but it isn’t built. Talk to us early if residency is a hard requirement.
Retention
| Surface | Default retention |
|---|---|
| Application audit (procedure runs, conversation transcripts, share grants) | Until explicitly deleted by the user, or until the organization is deleted (in which case cryptographic shredding applies immediately to encrypted contents). |
| AWS CloudTrail (Altostrat-side) | Retained per our internal security policy for incident investigation; details available on request as part of a security review. |
| Clerk audit | Per Clerk’s policy for the plan in use. |
| Sentry | Per Sentry’s policy for the plan in use; Studio configures standard retention. |
| Amplitude | Per Amplitude’s policy. |
The honest gaps
Two telemetry/audit limits are worth being explicit about:- Per-decrypt audit logging is not yet GA. As described above and in known limits, decrypts are recorded at the KMS layer in our CloudTrail today; structured per-purpose events at the application layer (visible inside Studio) are the next iteration.
- No first-party in-app audit explorer for an organization. Today the audit surface inside the application is per-conversation. Cross-conversation organization-wide audit views are a roadmap item; in the meantime, the operational answer is for us to pull the relevant CloudTrail and Clerk evidence on your behalf.
Related
Vault and keys
The cryptography that determines what audit logging at the decrypt boundary even means.
Known limits
The roadmap for per-decrypt audit and the cross-org audit explorer.