Skip to main content
Version: Next (unreleased)

Data residency and security

AlphaAgent is built for organizations that cannot hand their data to a third-party SaaS. This page states precisely where your data lives, the one narrow channel that leaves your account, how model inference is pinned to a residency zone, how users sign in, how users are isolated from each other, and how data is protected at rest. It is the reference for a security or data-architecture review.

Everything stays in your account​

Studio runs inside your own AWS account, and your data stays there. There is no shared multi-tenant backend — each customer self-deploys the entire stack into their own account, so your deployment is your isolation boundary.

The following all live in your account and never leave it:

  • Agent and swarm definitions — your agents' instructions and configuration (DynamoDB).
  • Conversations — every chat message and its history (DynamoDB, with oversized payloads in S3).
  • Workspaces and datasets — the files agents produce when they run code (S3), and the dataset records that index them (DynamoDB).
  • Connector credentials — the secrets used to reach your databases, APIs, and AWS resources (Secrets Manager).
  • Knowledge graphs — the graphs built from your documents, in your Neo4j — whether self-hosted by Studio in your VPC or your own external instance (see Knowledge graphs in depth).
  • Uploaded documents — files you upload for knowledge graphs or document analysis (S3).

The only outbound channel​

The single exception to "everything stays in your account" is the license and usage channel to the AlphaAgent Console. It carries no customer data — only what is needed to keep your subscription valid and metered:

  • Activation — once, when the deployment first comes online.
  • Heartbeats — a small signed status message roughly every five minutes.
  • Usage metering — counts of model usage, delivered durably.

Every message on this channel is cryptographically signed in both directions, so neither side can be impersonated or tampered with. The Console never initiates a connection into your account. The exact fields and timing are documented in Licensing and telemetry.

Model inference and residency zones​

All AI inference runs on AWS Bedrock in your own account. There are no direct calls to Anthropic, Cohere, or any other third-party inference API.

Bedrock model access is pinned to a single residency zone — the United States or the European Union — chosen at deployment time and matched to your AWS region. This pinning is enforced, not advisory: Studio validates at startup that every model it will use is in your zone and refuses to start otherwise, and it re-checks on each call. A deployment can never silently route inference out of zone. Inference traffic also stays on AWS's private network through an in-account Bedrock endpoint.

The practical guarantee: if you deploy in an EU region, your prompts and your data are processed by models in the EU zone, and the platform will not fall back to an out-of-zone model.

Access is SSO-only​

Users reach Studio through your own identity provider over SAML — Okta, Microsoft Entra, AWS IAM Identity Center, or any compliant SAML IdP. There is no self-signup and no local password store. Every request is authenticated at the load balancer before it reaches any Studio service, so unauthenticated traffic never touches the application. Identity, group membership, and access policy remain governed by your IdP.

Per-user isolation​

Within a single deployment, resources are owned by the user who created them. Agents, conversations, connectors, workspaces, and datasets all carry their owner's identity, and Studio scopes every list and lookup to the caller. If a user requests a resource that is not theirs, the platform responds as if it does not exist — it does not reveal that the resource exists but belongs to someone else. This prevents one user from discovering or reading another user's resources by guessing identifiers.

Encryption and credential handling​

  • Encryption at rest. S3 buckets are encrypted and fully blocked from public access; the operational data stores and secrets are encrypted as well. Secrets Manager can use a customer-managed KMS key for the license secret if you require one.
  • Encryption in transit. User traffic arrives over HTTPS; the signed Console channel runs over HTTPS.
  • Credentials are never embedded in compute. Connector credentials are stored in Secrets Manager and fetched only at the moment they are needed. When an agent runs code, credentials are resolved at invocation time rather than baked into any function's configuration, and AWS connectors hand the sandbox short-lived temporary credentials. The mechanics are in Connector data in the sandbox.

The license kill-switch​

Because the deployment is yours, AlphaAgent enforces its license with a local safety mechanism rather than a remote off-switch into your account. If the deployment cannot reach the Console for an extended period, or the license is revoked, Studio degrades itself: agent traffic is refused while diagnostic and re-activation endpoints stay available. This is a property of the running deployment, never an inbound action from PrometheusRL. The state machine and timing are detailed in Licensing and telemetry.

Where to go next​