Data at rest and in transit

Everything a Studio deployment stores stays in the AWS account and region you chose, encrypted at rest with keys AWS manages. Encryption in transit covers the edge and every call to an AWS service; inside the VPC the services talk over private networking. This page states exactly which key protects each store, where TLS ends, how long each class of data is kept, how a run is erased, and what is logged where.

Who this is for

Security engineers and data-protection reviewers. For the flows that leave your account see What leaves your account.

Before you start

One fact to carry through the page: there is no customer-managed KMS key today. No template creates an AWS::KMS::Key, and no bucket, table, file system, cache or secret is configured with a key you own. Encryption at rest is SSE-S3 with AES-256 for S3, AWS-owned or AWS-managed keys for DynamoDB, Secrets Manager, EFS, ElastiCache, ECR and CloudWatch Logs, TLS at the edge and to AWS endpoints, and EFS encryption for the graph store. The cross-account role's only KMS permission is kms:* conditioned on kms:ViaService, which lets those services use their AWS-managed keys and nothing more.

Encryption at rest

Store	What it holds	Encryption at rest	Retention control
S3 buckets (Studio: 7 from the core stack, the deploy bucket; Organisations: 3 foundation buckets, the release cache; the optional staging bucket)	Workspaces and run files, uploaded documents, knowledge graph build state, large payloads, code, web apps, templates, release bundles	SSE-S3 (AES-256) by default; versioning on the Studio buckets; all public access blocked	Run-data lifecycle rule on the workspaces bucket (Run data retention, default 90 days); staging objects expire after 7 days; otherwise until you delete
DynamoDB tables (Studio: 38; Organisations: 12)	Application state, run events, audit rows, usage events, API-key mirrors	Studio tables: DynamoDB default encryption with an AWS-owned key. Organisations tables: server-side encryption enabled with the AWS managed key	Studio: code execution history 30 days, soft-deleted conversations 90 days, activity cards 24 hours, API-key usage rows 90 days. Organisations: audit rows 400 days, transfer records 90 days
EFS file system (Neo4j)	Every knowledge graph version	Encrypted at rest with the AWS managed key; AWS Backup enabled	Until a version is deleted
ElastiCache Redis	Sessions and runtime cache	At-rest and in-transit encryption enabled	Cache TTLs; snapshot retention is a stack parameter
Secrets Manager (Studio: 18 shells plus runtime secrets; Organisations: 7)	Service configuration, licence credentials, Neo4j credentials, connector credentials, the PII hash key	AWS managed key aws/secretsmanager	Until the deployment is deleted; secrets are retained on stack delete
ECR repositories	Container images	AES-256	Until the deployment is deleted
CloudWatch Logs	Service and sandbox logs	CloudWatch Logs default encryption	LogRetentionInDays, default 30; SPA and auxiliary groups 30

Two details a reviewer will ask about:

• The Studio DynamoDB tables do not set an SSESpecification, so they carry DynamoDB's default encryption with an AWS-owned key. The Organisations tables set SSEEnabled: true, which uses the AWS managed key for DynamoDB. Both are encrypted; the key ownership differs.
• Stateful resources (tables, buckets, secrets, the file system, the cache) carry DeletionPolicy: Retain, so deleting a stack does not delete your data. Deleting a deployment from the Organisations console removes them deliberately; see Deleting a deployment and clearing an account.

Encryption in transit

Hop	Protection
Browser to CloudFront	HTTPS; HTTP is redirected; minimum protocol TLSv1.2_2021
CloudFront to the load balancer	HTTPS to the listener on 443 with the certificate you supplied; the load balancer's port 80 only redirects
Load balancer listener	Security policy ELBSecurityPolicy-TLS13-1-2-2021-06
Load balancer to the services	Plain HTTP on ports 8000 to 8010 inside the private subnets, restricted by security groups
Service to service	Plain HTTP over Service Connect inside the VPC
Services to Redis	TLS (in-transit encryption enabled)
Services to Neo4j	The Bolt protocol on port 7687 over the Service Connect mesh, plain TCP, reachable only inside the task security group
Neo4j to EFS	Transit encryption enabled on the mount
Services and sandboxes to AWS services	TLS to the VPC endpoints (S3, DynamoDB, Secrets Manager, STS, ECR, Logs, SQS, SSM, Bedrock Runtime)
Studio to the AlphaAgent Console	HTTPS, plus request and response signatures
Sandboxes to your data sources	Whatever your endpoint offers on TCP 443

Residency

• All stores are in the deployment region. The exceptions are the Lambda@Edge function and the CloudFront certificate, which live in us-east-1 and hold no data of yours, and CloudFront itself, which serves the web app and forwards requests from its edge locations.
• Model calls go to Amazon Bedrock through the VPC endpoint in the deployment region, using an inference profile pinned to the deployment's zone (us or eu). The runtime refuses to start if a configured model id does not match the region's zone, and there is no cross-zone fallback.
• Amazon Bedrock's published position is that prompts and completions are not stored, not used to train models and not shared with model providers; confirm the current AWS statement in your review. Bedrock model invocation logging is an account-level setting you control; AlphaAgent does not enable it.

Retention

Data	Where	Retention
Run inputs, working files and outputs	Workspaces bucket under each run prefix, tagged aa-data-class=run-data	Expired, current and prior versions, by the bucket lifecycle rule at the deployment's Run data retention setting: default 90 days, 1 to 3650, set in the wizard and changeable from the deployment's Overview
Conversation files and other workspace objects	Workspaces bucket	Until the user deletes them; versioning keeps prior versions
Deleted conversations	Chat tables	Soft-deleted rows expire after 90 days
Code execution history	alphaagent-code-executions	30 days
Inbox activity cards	alphaagent-activity	24 hours
Programmatic API usage rows and idempotency keys	alphaagent-api-keys	90 days and 24 hours
Organisations audit rows	alphaagent-org-audit	400 days
Library transfer records	alphaagent-org-libraries	90 days
Service logs	CloudWatch Logs	LogRetentionInDays, default 30

Deletion and the right to erasure

In a governed deployment, DELETE /api/v1/runs/{run_id}/data (scope runs:delete, on a finished run) erases one run. The API resolves runs by the key that started them: a key can erase only runs it created, and any other run id answers 404 run_not_found. For a run started in Studio, erasure is by the owner deleting it in Studio, or by the retention rule. The route erases:

• Every object and every version under the run's prefix in the workspaces bucket: inputs, working files, code, previews, outputs, result.json, the redaction manifest and placeholder registry.
• The run's event rows and board rows in the deployment's tables.
• From the run record, every attribute that holds or derives from the caller's inputs: summary, input parameters, inputs manifest, error message, result. Status, timings, counts, identifiers, error code, your client_reference and labels stay.

The response is 202 with counts: deleted_objects, deleted_versions, deleted_event_rows, deleted_graph_rows, the scopes covered and a status of purged or partial. After it, /steps, /events, /approvals and /outputs answer empty for that run, and a second call answers 409 already_purged. An audit marker with counts only is written against the key.

For everything else, deletion is by the owner in Studio (files, conversations, agents, versions) or by an administrator in the Organisations console (delete the deployment, then clear the account). Deleting a deployment removes the retained stores; clearing the account sweeps what CloudFormation left behind.

What is logged where

Log	Contents	Retention
/alphaagent/services/<service> (one per Studio service)	Structured service logs: requests, job progress, errors. The PII redactor's log lines are content-free by design	LogRetentionInDays, default 30
/aws/lambda/alphaagent-env-*	Sandbox handler messages per execution, including the credential-isolation outcome	Set by Lambda; default never expires unless you set it
/aws/lambda/alphaagent-<stack environment>-spa-server (the middle segment is the stack's Environment parameter)	Web app requests	30 days
/alphaagent/services/neo4j, searxng, kg-transfer	Graph store, search engine and transfer task logs	30 days
/alphaagent-org/services/* (Organisations)	Console and engine logs	LogRetentionInDays, default 30
Organisations audit table	Who did what in the console; see Audit trails	400 days

CloudTrail, AWS Config and VPC Flow Logs are not created by any AlphaAgent template. Enable them yourself; see Shared responsibility and best practices.

Steps: verify encryption and retention in your account

1. In S3, open alphaagent-workspaces-<account>-<region>: Default encryption shows SSE-S3; Bucket Versioning enabled; Lifecycle rules contains the run-data rule filtered on the aa-data-class tag.
2. In DynamoDB, open any alphaagent- table and read Encryption: owned by Amazon DynamoDB (Studio) or AWS managed key (Organisations).
3. In EFS, open the Neo4j file system: Encrypted yes; AWS Backup enabled.
4. In ElastiCache, open the replication group: encryption in transit and at rest enabled.
5. In KMS, list customer managed keys. None belongs to AlphaAgent.
6. In CloudWatch Logs, filter log groups by /alphaagent/services/ and read the retention column.

What you should see

• Every AlphaAgent bucket shows SSE-S3 and blocked public access.
• No AlphaAgent resource references a customer-managed key.
• The run-data lifecycle rule's expiry matches the retention you chose in the wizard.

Limits

• You cannot supply your own KMS key for any store today.
• TLS ends at the load balancer; traffic between the load balancer, the services and Neo4j is plain inside the VPC.
• The erasure route exists only on the programmatic API, which is available in governed deployments.
• Sandbox log groups are created by Lambda without a retention policy; set one if you need a bound.

If something goes wrong

• A run's prior object versions survive the retention period: check that the objects carry the aa-data-class=run-data tag; objects written by an environment image older than the deployment do not.
• DELETE /runs/{run_id}/data answers 409 run_not_terminal: the run is still running; cancel it first.
• A service control policy that denies KMS blocks services that use AWS-managed keys through kms:ViaService; see SCPs and guardrails.

Related

• What leaves your account
• Audit trails
• PII redaction posture
• Shared responsibility and best practices
• Limits, errors and codes