Threat model summary
This page lists the threats the design addresses, the mechanism for each, and the page that documents it in full. It ends with what the design does not protect against, so your own controls can cover it.
Who this is for
Security engineers and CISOs.
Before you start
The trust boundaries are drawn on Architecture overview. Everything below assumes them: the Console is ours, the accounts are yours, and the only code of ours that runs with credentials in your accounts is the engine in your Organisations account and the Studio services in each deployment.
What the design protects against
| Threat | Mechanism | Where |
|---|---|---|
| A stolen licence secret is used to send heartbeats or usage in your name | The secret signs requests only; it cannot produce a Console response. Requests are bound to the licence's tenant, must carry a fresh timestamp (300 s skew) and an unused nonce (600 s window), and can be limited to your egress CIDRs. The activation fingerprint is recorded. You revoke the licence or regenerate the token in the Console | What leaves your account |
| A deployment is pointed at a mock Console to lift a hold or a revocation | The Console host and the Ed25519 public keys are compiled into the release. A response without a valid Ed25519 signature blocks the deployment; a response whose signature fails verification stops it until re-activation | What leaves your account |
| One user reads or changes another user's resources in a standard deployment | Every row carries its owner; a read of another user's row answers 404, the same as a missing row; workspace reads are confined to the caller's prefix; pinned references must be owned | Identity and access |
| Model-written code escapes the sandbox to the account's credentials | The Lambda execution role holds no data grants; the handler re-executes with a clean environment and is non-dumpable, so the child cannot read its credentials; every AWS call for the user runs on a session narrowed to one user's prefix and one agent's secret; egress is TCP 443 plus the approved ports to the approved internal ranges | Sandbox isolation |
| Code from one execution poisons the next user's execution on a warm container | A fresh working directory per execution, a private home per scope, and a hash-verified cache | Sandbox isolation |
| A credential leaks through sharing | A push catalogues a pointer and display fields only; membership is re-derived by the engine from its own rows, never from the request; a pull copies a connector's definition only and never reads or writes a credential secret, so each deployment supplies its own credential; a role-based connector cannot connect until your role's trust names the receiving Studio and its own External ID | Secrets and connector credentials |
| Model-written code reads an MCP server's credential, or a prompt-injected agent changes data through an MCP tool | The sandbox holds only an MCP connector's type and name; Studio's data-connector service signs in and makes every call. Only tools enabled on the connector are offered or accepted, and a tool that does not declare itself read-only waits for a person's decision, enforced in the service and bound to the exact arguments; tokens are kept in the service's memory, never logged | Secrets and connector credentials |
| Someone on the internet reaches a deployment | New deployments and the Organisations console sit behind an internal load balancer with no internet-facing listener; only your user access ranges are routed and admitted, over your Transit Gateway | What runs in your account (Studio) |
| Agent code or a connector reaches parts of your network it should not | Only the internal service ranges an administrator lists are routed; sandboxes may use only the approved ports; connectors and the browsing tool refuse private addresses outside the list, and always the deployment's own range and the metadata addresses, checking every address a name resolves to and every redirect; with outbound traffic through your Transit Gateway every other private range is dropped inside the VPC | Sandbox isolation |
| A request reaches an existing public deployment's load balancer without passing through CloudFront | Every listener rule requires the origin-lock header carrying a per-deployment secret; the default action is 403 | What runs in your account (Studio) |
| An unauthenticated browser reaches a service | authenticate-cognito on every rule except the API-key-protected /api/v1 | What runs in your account (Studio) |
| The Organisations engine is used to create identities or act as your users | The cross-account role denies iam:CreateUser, access keys, login profiles and the Cognito admin sign-in actions; role changes are limited to alphaagent* roles; the engine's own role denies the same | What runs in your account (Organisations) |
| The engine operates outside the regions you allow | The cross-account role denies regional actions outside AllowedRegions | What runs in your account (Organisations) |
| A different account impersonates your Organisations account to assume the target role | The trust policy names one principal and requires an External ID that only your Organisations account holds | What runs in your account (Organisations) |
| Images are substituted between our release and your account | Images are copied by digest from your Organisations repositories into each deployment's repositories; the running task definition references the digest | Updates and rollback |
| A stale account template silently lacks a permission | The engine reads the registration stack's TemplateVersion and refuses to update an existing public deployment's front door below 2.3.0 | What runs in your account (Organisations) |
| Personal data leaves a workflow run unredacted | Deliverables are withheld with 409 redaction_pending until the final sweep completes | PII redaction posture |
What the design does not protect against
- Your own IAM administrators. Anyone with administrative access to a Studio account can read the buckets, tables and secrets, assume the roles and change the stacks. AlphaAgent runs inside your trust boundary; it cannot protect data from the account's owner. CloudTrail is your record of what they did.
- A compromised identity provider, or an assigned user acting within their rights. Sign-in is delegated to your Entra ID tenant. A user who is assigned can see what the ownership model allows, and in a governed deployment that is every resource in the deployment, by design.
- What agent code sends out on port 443. A sandbox can reach your connectors and the public web over HTTPS. What it sends is decided by the code the model wrote for your user's request. Connector credentials are scoped by you (read-only roles), and web access can be withheld by not giving an agent those tools. An MCP tool that declares itself read-only runs without asking, so the server's own annotations matter: turn Ask before running on for any tool you do not trust to be read-only.
- Model provider handling. Prompts and completions go to Amazon Bedrock in your account and zone. Their handling is under AWS's terms; the design does not add a control there.
- Availability of external dependencies. If the Console is unreachable, the deployment fails closed and stops serving; if Docker Hub is unreachable at task start, two services cannot start. These are availability risks, not confidentiality risks.
- A background process left in a warm sandbox container. Every child is the same operating-system user on one
/tmp; a process one execution leaves running is bounded by the Lambda timeout, not by the isolation layers. - Data inside a run when a redaction stage is off. That visibility is a workflow author's choice within your deployment's floor.
Steps: map this to your controls
- For each row in the first table, note the verification step on the linked page and who in your organisation runs it.
- For each item in the second list, name the control on your side (CloudTrail and GuardDuty, Conditional Access, connector role policies, network egress policy, Bedrock terms review).
- Record the release you assessed. This site describes Studio 2.1.0 and Organisations 1.1.0. Its model rows (Claude 5.5 through
us.andeu.inference profiles only, the task role's deny onglobal.profiles, and the model access check before a deployment changes) arrived with that release. The private network rows (the internal load balancer, the internal service ranges and the sandbox's approved ports) arrived with Studio 2.0.15 and Organisations 1.0.17, and the route that drops unlisted private ranges with Studio 2.0.18; the other mechanisms were verified on Studio 2.0.4 and Organisations 1.0.5 and are unchanged since.
What you should see
A one-to-one mapping from each threat to a mechanism you can verify in your own account, and from each residual risk to a control you own.
Limits
This page is a summary. It does not enumerate every control in the templates, and it does not replace your own assessment against your obligations.
If something goes wrong
If a verification step on a linked page does not produce the result described, treat the discrepancy as a finding and report it to us with the release version and the step.