Audit and telemetry

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.

​

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: 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).

​

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.

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.

​

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).

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.

​

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 explicit console.error calls from both the Electron renderer and the Go sidecar. 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.

​

Amplitude (product analytics)

Amplitude receives event-level analytics about which features are used. 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.

​

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:

​

Data residency in audit and telemetry

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.

​

Retention

​

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