Skip to main content
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 used to keep and improve the application—performance, errors, feature events, and configured interaction replay. Studio has both. They are governed by different rules and are documented separately on this page.

Audit

Studio runs as a managed SaaS in Altostrat’s AWS account; you don’t sign into Altostrat’s AWS console or query its CloudTrail directly. Audit visibility is split between records exposed in Studio, records held in Altostrat’s service accounts, and logs held by identity or target-system providers: 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 KMS unwrap fail? CloudTrail can provide the KMS request, principal, encryption context, and denial detail where the event is retained. It does not by itself identify every application field later decrypted with the unwrapped data key.
  • Did a user share or change the visibility of a resource? Start with the resource and application history, then correlate infrastructure evidence if the encrypted data path is relevant.
  • 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

Dedicated audit events use redacted event data; they are not a credential store. The durable desktop stream records bounded, redacted inputs rather than full tool output. Conversation and procedure transcripts can still contain sensitive content that a user or tool supplied. Treat exported evidence as sensitive and review it before sharing. Operational counters and infrastructure events are separate from the application audit streams. 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

Use the surface that matches the action you are investigating: Signed-in desktop entries are buffered locally and uploaded after connectivity returns. The recent session view is bounded; clearing it does not clear the durable trail. Signed-out session entries do not have the same cloud durability. Desktop and worker streams link entries with hashes. Verify chain detects breaks or changes in the recorded sequence. A valid chain does not prove an action was correct, that an external system accepted it, or that every event outside Studio was captured. Correlate important changes with target-system evidence.

Org Brain evidence

A cited answer identifies the sources used for that answer. Citations are evidence references, not approval records. A source may later change, be deleted, or become inaccessible. Inspect the current authorized source before acting; a stored answer is not a live authorization check or a guarantee of current truth. The Org Brain Registry is an administrative view of organization-visible indexed documents. It does not expose every private or channel-scoped source. Dream runs, the review queue, and consolidation history provide separate evidence about proposed knowledge improvements. See Org Brain.

Telemetry

Studio sends telemetry to third-party vendors for reliability and product analysis. Content scrubbing, blocking, masking, and sampling differ by vendor; the current desktop app does not expose a general customer-facing telemetry switch.

Sentry (error reporting)

Sentry receives selected desktop errors, crashes, warnings, and performance traces from the Electron renderer, main process, and local agent paths that are instrumented for it. 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 product-usage and interaction analysis. Its replay masking reduces exposure but is not equivalent to disabling capture. Do not display secrets in unprotected UI text, and contact Altostrat before deployment if replay collection conflicts with your policy.

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 managed SaaS—you don’t run its service control plane in your own account—so telemetry control depends on the options exposed by the current desktop release:

Data residency in audit and telemetry

If your organization has a strict residency requirement that conflicts with any of the above, talk to Altostrat before deployment. The AI inference region selector does not relocate audit, identity, billing, or other control-plane records; see control-plane residency versus inference region.

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.
  • Coverage remains surface-specific. Desktop and worker organization audit views are available, but they do not unify all infrastructure, identity, endpoint, and external-system evidence. Signed-out desktop entries lack cloud durability; signed-in offline entries need reconnection to upload.

Vault and keys

The cryptography that determines what audit logging at the decrypt boundary even means.

Known limits

The remaining boundaries of per-decrypt audit, cross-system evidence, and customer telemetry controls.