> ## Documentation Index
> Fetch the complete documentation index at: https://altostrat.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# AI safety in Studio

> How Altostrat Studio runs AI against production networks safely — the architecture, the controls, the cryptography, and the honest limits. Written for the security engineer reviewing whether to authorize this in their environment.

Studio is an AI-assisted operations IDE that connects directly to production network and server infrastructure. That combination — autonomous agents, persistent credentials, real device access — sets a high bar for safety. This section is the engineering account of how we meet that bar, and where we're still working.

We wrote it for the person who has to sign off on Studio for their environment. It's not a marketing page. It cites the actual controls we've built, names the cryptographic primitives, and is honest about the things that aren't done yet. If you find a gap, [tell us](../troubleshooting) — that's how this gets stronger.

## The principles

Six commitments shape every safety decision Studio makes:

<CardGroup cols={2}>
  <Card title="Plaintext minimization" icon="lock">
    Secrets exist as plaintext in the smallest possible blast radius for the shortest possible time. Nothing sensitive is stored on disk in clear; nothing sensitive enters the AI provider's context unless you explicitly substituted it.
  </Card>

  <Card title="Approval before consequence" icon="shield-check">
    Read-only operations move freely. Anything that changes external state — a device command, a connector write, a credential decrypt for execution — passes through a classifier and an approval gate the user can see.
  </Card>

  <Card title="Tenant isolation by cryptography" icon="key">
    Organization isolation is enforced not just by API guards but by per-org encryption keys in an HSM. Two orgs sharing infrastructure cannot read each other's data even if the access control logic fails.
  </Card>

  <Card title="One AI provider, controlled region" icon="cloud">
    All model inference goes through AWS Bedrock in `us-east-1`. There is no path that ships your data to a third-party AI vendor or to Anthropic's hosted API directly.
  </Card>

  <Card title="Auditability over autonomy" icon="file-text">
    Every meaningful action the agent takes — tool call, command staged, credential decrypted, share granted — is observable in real time and recoverable from history. Autopilot exists; surveillance of it is the price of using it.
  </Card>

  <Card title="Honest limits" icon="eye">
    Some things are not built yet. Some things never will be (because they conflict with operational reality). We document both. Buying decisions made on incomplete information cost more than the truth.
  </Card>
</CardGroup>

## What's on this tab

<CardGroup cols={2}>
  <Card title="Threat model" icon="target" href="./threat-model" arrow="true" cta="Read">
    What we're defending against, what we're not, and the assumptions our controls rely on.
  </Card>

  <Card title="Identity and access" icon="user-check" href="./identity-and-access" arrow="true" cta="Read">
    Clerk for the user, Cognito for the AWS calls, organization isolation enforced top to bottom.
  </Card>

  <Card title="Vault and keys" icon="key" href="./vault-and-keys" arrow="true" cta="Read">
    Per-org KMS keys in a FIPS-validated HSM, AES-256-GCM envelope encryption, automatic 30-day DEK rotation, cryptographic shredding on org deletion.
  </Card>

  <Card title="Human in the loop" icon="hand" href="./human-in-the-loop" arrow="true" cta="Read">
    The trust-level model, tool classification, the approval gate, and how the steering controls let you stop or redirect a running agent in real time.
  </Card>

  <Card title="AI provider and data flow" icon="brain" href="./ai-provider-and-data-flow" arrow="true" cta="Read">
    Bedrock-only, model and region pinning, three-tier prompt cache, secret redaction before model context, and the boundary between local and cloud.
  </Card>

  <Card title="Agent and local runtime" icon="cpu" href="./agent-and-local-runtime" arrow="true" cta="Read">
    Electron + Go sidecar architecture, what stays on your device, the local embeddings model, and how the desktop process talks to the backend.
  </Card>

  <Card title="Audit and telemetry" icon="bar-chart" href="./audit-and-telemetry" arrow="true" cta="Read">
    What's logged, what's redacted, what third parties get (Sentry, Amplitude), and how to disable optional telemetry.
  </Card>

  <Card title="Connectors and MCP safety" icon="plug" href="./connectors-and-mcp-safety" arrow="true" cta="Read">
    How third-party API credentials are stored, how MCP tool catalogs are gated, and what happens if a remote MCP server tries to misbehave.
  </Card>

  <Card title="Supply chain and updates" icon="package" href="./supply-chain-and-updates" arrow="true" cta="Read">
    Code signing, notarization, update signature verification, the build pipeline, and the path from source to your machine.
  </Card>

  <Card title="Known limits and roadmap" icon="alert-triangle" href="./known-limits-and-roadmap" arrow="true" cta="Read">
    The honest list of what isn't done yet and what we're working on. Read this before committing.
  </Card>
</CardGroup>

## A one-paragraph version

If you read nothing else: **Studio's user identity is Clerk; AWS access goes through Cognito Identity Pool short-term credentials; sensitive fields are encrypted with AES-256-GCM under per-organization data keys wrapped by AWS KMS FIPS 140-2 customer master keys, with rotation on a recurring schedule and cryptographic shredding on organization deletion; the AI agent runs through approval gates classified by tool risk class with three trust levels (manual, supervised, autonomous); all model inference uses Anthropic models via AWS Bedrock in us-east-1 only; the desktop app is a signed Electron binary with a Go sidecar that holds plaintext keys only in OS-protected memory; and there are some things — most notably AI context scrubbing of substituted secrets, and audit logging of every decrypt call — that are not yet GA, documented honestly under [known limits](./known-limits-and-roadmap).**

## Why the safety architecture is also the moat

The same controls that keep your data isolated also make Studio's accumulated value structurally hard to extract. Per-organization keys mean your procedures, memories, conversation transcripts, and host inventory are bound to keys only your organization can use. That connective tissue — the runbooks, the topology corrections, the vendor behavior memories — gets denser the longer you use Studio, and specifically against *your* network.

For the full argument, including the compounding-workspace framing, see [Why Studio](../why-studio).

## How to read this section

If you're a CISO doing initial diligence: read [threat model](./threat-model), [vault and keys](./vault-and-keys), [known limits](./known-limits-and-roadmap), in that order.

If you're a security engineer doing the deep review: read every page. The vault and HITL pages have the most engineering detail; the supply chain page has the most surprises.

If you're an MSP or ISP team lead deciding whether your operators can use Studio: read [overview](./overview), [human in the loop](./human-in-the-loop), and [audit and telemetry](./audit-and-telemetry).