Skip to main content
The vault is the part of Studio we will explain in the most detail, because it is the part you should weight most heavily. If the vault is sound, an attacker who steals every database row and every file in object storage walks away with ciphertext that decrypts to nothing without an AWS-side authorization for the right organization. Application-layer access controls are necessary but they fail occasionally. Cryptographic isolation does not. This page describes the design end to end: the keys, the algorithm, the envelope format, the rotation behavior, the cross-organization sharing flow, the keychain caching, and the organization-deletion path that ends in cryptographic shredding.

​
The shape

LayerWhat it isWhere it lives
Customer master key (CMK)Per-organization symmetric KMS key.AWS KMS, FIPS 140-2 validated HSM, us-east-1 FIPS endpoint.
Data encryption key (DEK)Per-organization symmetric data key, one per active version.Encrypted at rest in DynamoDB, wrapped by the org’s CMK.
Resource DEK wrapA separate wrap of a record’s DEK for each organization that is allowed to decrypt it (used for cross-org shares).Persisted as scoped wrap rows in the backend store.
Per-record envelopeThe actual sensitive field as ciphertext.DynamoDB keyChainEntries, connectorEntries, mcpServerEntries, procedures, procedureRuns, connectionProtocols.
Plaintext DEK cacheDecrypted DEK held in OS keychain with a 12-hour TTL.macOS Keychain / Windows DPAPI / Linux libsecret.
Plaintext fieldDecrypted record value held in agent memory only at the moment of use.Go sidecar RAM, BoringCrypto.
Three layers of indirection — CMK wraps DEK wraps record — sound complex. They give us four properties we want:
  • The CMK never leaves the HSM.
  • The DEK can be rotated frequently without rewriting every ciphertext immediately (envelopes carry a dekRef and the corresponding wrap is fetched at decrypt time).
  • A single record can be re-wrapped for additional organizations (sharing) without re-encrypting.
  • Organization deletion is a single operation: schedule the CMK for destruction. Every wrap becomes unrecoverable; every envelope becomes garbage.

​
The algorithm

ComponentChoice
Symmetric cipherAES-256-GCM
Wrap (CMK → DEK)AWS KMS, FIPS 140-2 validated HSM
KMS endpointAWS FIPS endpoint in us-east-1
Key derivationNone at the application layer; KMS handles CMK-side derivation.
AADA canonical binding of the envelope to its organization, table, record, and field.
IV96 bits, randomly generated per encryption.
Tag128 bits, GCM standard.
Crypto libraryGo with BoringCrypto in the agent; AWS-native KMS in the cloud.
Envelope payloads are versioned so the format can evolve without breaking historical decrypts; every envelope carries a version tag and a reference to the DEK that wrapped it.

​
Additional authenticated data

Every envelope’s AAD binds it to its location. An adversary who copies a ciphertext from one record to another (transplantation attack) cannot decrypt it: the AAD they would have to forge includes the destination record’s identity, and the GCM tag fails verification. This means:
  • A field copied from one record to another in the same table fails to decrypt.
  • A field copied from one organization to another fails to decrypt.
  • A field copied between two semantically different fields on the same record fails to decrypt.
The exact AAD construction is a hardening detail we don’t publish, but the property it enforces is the one above.

​
DEK lifecycle

A new organization receives a freshly minted DEK:
1

Create the org's CMK

On organization creation, a backend handler creates a dedicated KMS customer master key, applies the org-scoped key policy, and records the binding so subsequent calls route to the right key.
2

Mint the first DEK

The same handler asks KMS to generate a fresh data key under the new CMK. The plaintext form is used once and discarded; the wrapped form is persisted as the org’s active DEK.
3

Use the active DEK for new envelopes

Encryption calls fetch the active DEK, unwrap it via KMS into protected memory, perform the AES-256-GCM operation with the appropriate AAD, and embed a reference to the DEK in the envelope so it can be located again at decrypt time.
4

Rotate on a recurring schedule

A scheduled rotation mints a new DEK version and marks the previous one retired. New envelopes use the new DEK; old envelopes still decrypt because retired DEKs are kept (encrypted) for the lifetime of the organization.
5

Admin-triggered rotation

An organization admin can also trigger rotation manually — for example, after a personnel change. The same handler runs; the same retirement semantics apply.
Rotation is idempotent and concurrent-safe: the active-version pointer is updated with a conditional write so two simultaneous rotations cannot produce two different “active” versions. Retired DEKs are never deleted while the organization exists. Old envelopes must keep decrypting. The cost of keeping them is negligible, and the benefit is that historical data does not become inaccessible after a routine rotation.

​
Plaintext DEK caching

Decrypting a record requires the plaintext DEK. Calling KMS for every decrypt is too slow for a workspace that opens hundreds of records per session, so plaintext DEKs are cached in the operating system keychain on the desktop with a short lifetime.
Cached materialWhereBehavior
Wrapped DEKOS keychain.Safe to keep; it’s only useful with a KMS unwrap.
Plaintext DEKOS keychain.Held for a short, bounded interval (hours, not days), then expired. The next decrypt requires another KMS call.
Session metadataOS keychain.Same bounded interval; purged on sign-out.
The OS keychain is itself encrypted with OS-level secrets (login keychain on macOS, DPAPI on Windows, libsecret on Linux). Plaintext DEKs never touch disk in clear. The bounded TTL is a deliberate safety margin: a stolen workstation that is signed in for a day still has limited useful key material once the cache expires, and an explicit sign-out purges every cached vault entry immediately.

​
Cross-organization shares

When a user shares a resource with a member of another organization, the resource’s encrypted contents must become readable to the other org without exposing the originating org’s DEK. Studio uses a per-resource DEK wrap for this:
1

Originating org unwraps the record

The originating user’s session unwraps the record’s envelope using the active org DEK and re-encrypts it under a fresh per-record DEK.
2

Per-record DEK is wrapped for each participating org

The per-record DEK is wrapped once under each participating organization’s CMK via KMS. Each wrap is persisted as its own row, scoped by (resource, organization).
3

Recipient org reads the share

A recipient’s session looks up the wrap for its own org, calls KMS with its own CMK to unwrap the per-record DEK, then decrypts the record. At no point does the recipient’s session see the originating org’s DEK or CMK.
4

Revoking a share removes the wrap

Removing a share deletes the recipient org’s wrap. The recipient’s session can no longer unwrap the per-record DEK; the underlying record is unchanged for the originating org.
This is the standard envelope-encryption pattern for multi-tenant shared records. It is meaningful because it means a share can be revoked without re-encrypting the record, and an org with revoked access cannot retroactively read the data even if it kept a copy of its own DEK.

​
Encrypted fields

The following fields are encrypted under the org DEK at rest:
DomainWhat’s encrypted
Host protocolsPer-host passwords, key references, ONVIF camera credentials.
ConnectorsThe full authentication blob (basic, bearer, OAuth tokens, custom-header secrets).
MCP serversThe full authentication blob.
ProceduresThe procedure body, which may contain inlined sensitive text.
Procedure runsArgument values, conversation messages, tool-call summaries, final output.
Keychain entriesThe credential payload itself.
Hostnames, display names, organization membership, ownership, and folder structure are intentionally not encrypted. They have to be queryable for the workspace to be usable, and they are not the secrets — they are operational metadata. This boundary is documented honestly under known limits.

​
KMS access policy

Each organization’s CMK has a key policy that only permits decryption when the caller is bound to that organization. The binding is established at sign-in: the user’s identity claim is propagated as an AWS principal tag on every signed call, and KMS will only unwrap a DEK when the tag and the key’s policy align with the encryption context the application supplies. A user signed into org A who somehow obtains a stored ciphertext for org B cannot decrypt it: the tag does not match the CMK’s policy, KMS refuses the call, end of story.

​
Organization deletion and cryptographic shredding

When an organization is deleted, an organization-lifecycle handler:
1

Schedule the CMK for deletion

KMS marks the org’s CMK pending deletion with the AWS-mandated 30-day window. Shorter windows aren’t permitted.
2

Stop minting new envelopes

The org-key state is updated so the application no longer encrypts new records against the soon-to-be-destroyed CMK.
3

Wait the AWS-mandated window

During the 30 days, an admin can cancel the deletion if it was a mistake.
4

CMK is destroyed

After the window, AWS destroys the CMK irreversibly. Every wrapped DEK for the organization is now unrecoverable; every envelope encrypted with those DEKs is now ciphertext that can never be decrypted.
This is cryptographic shredding: data may still exist in database rows, in object storage, in backups, in any cache that ever held it. None of it is readable. There is no “delete every database row” sweep that has to succeed for confidentiality to hold, because the rows themselves are inert.

​
Why this becomes a moat

The vault is described above as a security control. It is also why Studio’s value compounds the longer you use it. Per-organization cryptographic isolation means your inventory, your procedures, your memories, your conversation transcripts, your session recordings, your connector definitions, and your knowledge graph are all bound to keys only your organization can use. They are encrypted under your CMK; the local agent’s knowledge graph and embeddings index are computed against your data and live on your devices; the cross-org sharing graph is yours to grant and revoke. That body of work cannot be picked up and dropped into another tool in any useful form. A competitor can replicate the architecture. They cannot replicate three years of your team’s runbooks, the memory of which vendor port behaves which way during a maintenance window, the hundred conversations that taught Copilot what your customers actually need, or the diagram graph that has been corrected by the people who actually run the network. The encryption is what keeps that knowledge yours; the architecture is what makes it useful where it is. The implication for switching cost is the implication for defensibility. You are not buying a feature when you adopt Studio. You are accumulating an operational asset that gets denser the longer you keep using it.

​
How to verify any of this

Studio runs as single-tenant SaaS in Altostrat’s AWS account in us-east-1. The vault, the KMS keys, the CloudTrail logs, and the AppSync infrastructure live there — not in your AWS environment. The verification options reflect that:
  • FIPS endpoint and HSM: AWS’s published documentation establishes that the FIPS KMS endpoint in us-east-1 runs on FIPS 140-2 validated hardware. Our internal integration suite asserts on every release that we route to the FIPS endpoint; the assertion details are part of the security pack we share under NDA.
  • DEK rotation cadence and key isolation: producible from our CloudTrail on request as part of a security or compliance review.
  • Per-organization isolation: observable in any record export — each organization’s encrypted blobs reference a different KMS key, and sharing produces additional per-organization wraps.
  • Envelope versioning: observable in any record export — the version tag is unambiguous and lets us evolve the format without breaking historical records.
If you need formal evidence — for a SOC review, a PCI assessment, a customer security questionnaire — contact us. We share controls documentation and CloudTrail evidence under standard NDA.

Identity and access

How the principal tag that gates KMS access gets attached to your AWS calls.

Known limits

What the vault does not yet do — including audit logging of every decrypt and AI-context scrubbing.