Shared responsibility and best practices

AlphaAgent runs in your AWS accounts. Prometheus Research Labs is responsible for the software, the releases and the Console; you are responsible for the accounts, the identity provider, the network and the data. This page draws that line and lists the practices we recommend on your side.

Who this is for

CISOs and security engineers writing the control mapping, and administrators setting up accounts.

Before you start

The templates create nothing outside the resources listed on What runs in your account (Studio) and What runs in your account (Organisations). In particular they create no CloudTrail trail, no AWS Config rule, no GuardDuty detector, no KMS key and no Route 53 record. Those are yours.

Who is responsible for what

Area	Prometheus Research Labs	You
The AlphaAgent Console	Its availability and security; custody of the response signing key; the licence, heartbeat and usage records	Your Console account, its members and your licence keys
Releases	The images, templates, the sandbox handler, the compiled Console host and public keys, the catalogue; fixing defects	Choosing when to apply a release and running the upgrade
Organisations	The software	The account, its region, running orgctl.py, the break-glass user, Console credential custody
Studio deployments	The software and its defaults	Each account and its guardrails, sizing, retention settings, the ownership mode
Identity	Federation code in both consoles	Your Entra ID tenant, its policies (MFA, Conditional Access), who is assigned, the automation application's secret and its expiry
Network	The VPC layout the templates declare	DNS for your app domains, the regional certificates, egress policy, any WAF allow-list
Data	Encryption defaults, the erasure API, retention mechanics	What you connect, what users upload, retention values, erasure requests, backups beyond the defaults
Keys and credentials	The licence secret's issuance and one-time reveal	API keys and their rotation, connector credentials, the AWS connector roles, the PII hash key's rotation
Monitoring	Alarms the templates create; the Console's heartbeat view	CloudTrail, GuardDuty, Config, budgets and cost alarms, log retention

Best practices

Accounts and guardrails

• Use one AWS account per Studio deployment and a separate account for Organisations; see the reasons on Before you start.
• Enable CloudTrail on every Studio account (an organisation trail is simplest) and GuardDuty in the deployment region. Neither is created by AlphaAgent. CloudTrail is what shows you the engine's role assumptions, the sandbox's scoped sessions and reads of the PII key.
• Write service control policies as allow-lists of what the templates need, and test them by registering the account and pressing Verify, then by deploying to a sizing profile of xs. Do not deny us-east-1, CloudFront, Lambda@Edge, Cognito, Bedrock or aws-marketplace:* on a Studio account: the front door, sign-in, model calls and the Bedrock subscription depend on them. Permission boundaries applied to every role break the stack roles the same way. A policy that mandates CloudTrail or Config settings the templates do not set will fail resource creation; see SCPs and guardrails.
• Keep the account template current. The front door needs TemplateVersion 2.3.0 or later with us-east-1 in AllowedRegions.

Identity

• Grant StudioUser to groups rather than individuals where you can, and review the deployment's seat usage (default cap 20 per deployment).
• Enforce MFA and Conditional Access in Entra ID; AlphaAgent inherits them because every sign-in goes through your tenant.
• Remove the break-glass Cognito user once your identity administrator has verified sign-in.
• Track the expiry of the automation application's client secret under Identity Providers in the Organisations console and update it before it lapses; deployments cannot be created or their assignments changed without it.

Keys and credentials

• API keys: choose the shortest expiry that fits (30, 90, 180 or 365 days; default 90), grant only the scopes a system needs from workflows:read, runs:create, runs:read, outputs:read and runs:delete, restrict source_cidrs (up to 32) and, where the caller runs on a schedule, a UTC time window. Rotate with an overlap (default 24 hours, at most 168) so the old secret keeps working until the caller has switched. Where every caller has a fixed address, set the deployment's ApiWafIpSetCidrs so /api/v1 is blocked at the edge for everyone else.
• Licence token: regenerate it in the Console when someone who handled it leaves; re-activate the deployment with the new token.
• Connector credentials: use read-only database roles and Snowflake roles; for the AWS connector, keep your role's policy to the buckets and actions the workflow needs.
• PII hash key: rotate on your own schedule by replacing the secret and restarting agent-runtime; plan the join boundary it creates.

Network and residency

• Choose the deployment region for residency; every store is in that region, and model calls use the inference profile of that region's zone (us or eu). Only the edge function and certificate are in us-east-1.
• Point your DNS at the CloudFront distribution, never at the load balancer; the origin lock refuses direct requests.
• If you disable the NAT gateway, provide another route to the Console host and to Docker Hub, or the deployment cannot heartbeat or start two of its services.

Backups and retention

• The templates enable AWS Backup on the Neo4j file system, point-in-time recovery on 14 of the 38 Studio tables, and versioning on every bucket. Add AWS Backup plans (and cross-account copies if your policy needs them) for the tables and buckets you cannot afford to lose.
• Set Run data retention in the wizard to your policy (default 90 days) and LogRetentionInDays (default 30) to match your logging policy.

Cost

• Set an AWS Budget with alerts on every Studio account. The drivers are Fargate hours (the sizing profile), NAT gateway data, Bedrock tokens, ElastiCache node hours and EFS storage; see Infrastructure sizing and costs.
• The templates create alarms for service health and metering delivery, not for spend.

Steps: check your side of the line

1. In CloudTrail, confirm a trail covers each Studio account and the deployment region.
2. In GuardDuty, confirm a detector is enabled in the deployment region.
3. In the Organisations console, open Programmatic Access and read each key's expiry, scopes and CIDRs.
4. In Identity Providers, read the automation application's secret expiry.
5. In AWS Budgets, confirm a budget with an alert exists for each Studio account.

What you should see

• Every AlphaAgent role assumption and secret read visible in CloudTrail.
• No API key without an expiry, a CIDR list or a scope smaller than the default four.
• Budget alerts reaching a mailbox that is read.

Limits

• AlphaAgent cannot enforce your identity policies, guardrails or budgets; it inherits them.
• There is no customer-managed KMS key option today; see Data at rest and in transit.

If something goes wrong

• A deploy fails with a permission error after you added a service control policy: the failure names the denied action. Compare with the account template's statements on What runs in your account (Organisations).
• Sign-in fails for everyone after a secret expiry: update the automation application's credentials under Identity Providers.
• Spend rises unexpectedly: check NAT data processing (agent web browsing and large connector pulls) and Bedrock usage in the deployment's analytics before changing the sizing profile.

Related

• Threat model summary
• Data at rest and in transit
• SCPs and guardrails
• API keys
• Infrastructure sizing and costs