Altostrat Studio is here — the AI-native network operations IDE for engineers running production. Terminal, diagrams, runbooks, and Copilot in one workspace. Get started →
What Studio records about your work, what it sends to third parties, what’s redacted from error reports, and how to disable optional telemetry. With the honest gap: per-decrypt audit logging is on the roadmap.
Use this file to discover all available pages before exploring further.
Two different things get called “logs” in most software. Audit is the record of meaningful actions taken in the application — who did what, when, against which resource. Telemetry is the operational signal a vendor uses to keep the application working — performance, error reports, feature usage. Studio has both. They are governed by different rules and they are documented separately on this page.
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:
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.
Clerk’s audit log. We can produce relevant events on request; if your organization uses SSO, your IdP also has its own log.
The combination is the answer to most “who did this and when” questions:
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:Decrypt events 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:GenerateDataKey calls against your CMK on the 30-day cadence).
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.
This is the artifact you reach for when you need to reconstruct a change after the fact. Sharing a procedure run shares the full transcript with the recipient, subject to the resource’s access scope.
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).
The honest gap: per-decrypt audit logging is not yet implemented at the application layer. The infrastructure for it is in place — every decrypt call carries a 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.
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.
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 receives uncaught exceptions, promise rejections, and explicit console.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.
Sentry’s default scrubbing is aggressive in Studio because the workspace contains terminal output that may have secrets in it by accident. False-positive redactions are preferred over false-negative leaks.
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.
Amplitude is for understanding “do operators use procedures more than memories” and “is the diagram editor crashing on Windows”. It is not the right tool to send sensitive content to and we do not.
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.
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).
If your organization has a strict residency requirement that conflicts with any of the above, Studio in its current single-tenant 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.
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.
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.
