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 only | 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; on pull the credential moves from the source account's secret to the target account's secret in memory, never through a Library, S3 or a log; an AWS connector cannot connect until you extend your role's trust | Secrets and connector credentials |
| A request reaches the 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 deploy the 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.
- 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. The mechanisms above were verified on Studio 2.0.4 and Organisations 1.0.5 and are unchanged through Studio 2.0.14 and Organisations 1.0.16, the release this site describes.
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.