The security architecture, hardening advice, and what it takes to make this production-ready.

Cognito authentication is built in and on by default. The ALB authenticates users through the Cognito hosted UI before it forwards anything to Fargate. Two groups, operators and viewers, control what a user can do.

A few things worth calling out:

• The ALB-signed x-amzn-oidc-data token (which carries the user's identity and email) is signature-verified (ES256) before it's trusted. A malformed or invalid token returns 401 and doesn't fall through to a weaker auth method.
• The Cognito User Pool uses Managed Login v2, and the User Pool Client runs the SRP (userSrp) auth flow with the authorization-code grant. Both are provisioned in CDK (infra/lib/ui-stack.ts).
• API key comparison uses secrets.compare_digest() to avoid timing attacks.
• The DEFAULT_ROLE fallback is deliberately viewer (least privilege). Only move it to operator in a trusted environment.

For production, a few enhancements are worth making:

1. Verify the access-token signature against Cognito JWKS. The backend verifies the ALB-signed x-amzn-oidc-data token (identity), but it reads the cognito:groups claim — the one that decides operator vs viewer — from the x-amzn-oidc-accesstoken by base64-decoding it without checking its signature. The code logs a warning about this. In production, validate the access token's signature against the Cognito JWKS endpoint (https://cognito-idp.{region}.amazonaws.com/{userPoolId}/.well-known/jwks.json) before trusting the group claim, so a forged access token can't escalate to operator.
2. Federate with your corporate IdP. Cognito supports OIDC/SAML federation with Okta, Ping, Azure AD, or AWS IAM Identity Center. Map your IdP groups to the Cognito groups (operators, viewers). See the Cognito federation docs.
3. Add IAM session tags for CloudTrail attribution. Pass --tags operator={email} when assuming the execution role so audit trails point at the human, not just the service role.
4. Use a custom domain. Swap the ALB DNS name for a Route 53 alias with an ACM public certificate.

The spoke role (infra/lib/spoke-iam-stack.ts) trusts the hub account root, but an ArnLike condition narrows down which hub principals can actually assume it:

new iam.ArnPrincipal(`arn:aws:iam::${props.hubAccountId}:root`).withConditions({
  ArnLike: {
    'aws:PrincipalArn': [
      `arn:aws:iam::${props.hubAccountId}:role/AgentCore-*`,
      `arn:aws:iam::${props.hubAccountId}:role/AmazonBedrockAgentCoreSDKRuntime-*`,
      `arn:aws:iam::${props.hubAccountId}:role/Patchy-UI-*`,
    ],
  },
}),

Only these hub role patterns can assume into spoke accounts:

• AgentCore-* / AmazonBedrockAgentCoreSDKRuntime-* — the agent runtime (patch operations, fleet queries)
• Patchy-UI-* — the dashboard Fargate task (read-only cross-account queries)
• The SSM service principal is also trusted, for Automation document execution

Arbitrary IAM users or other roles in the hub account can't assume PatchySpokeRole. That's the default — no extra hardening needed.

Cross-account resources are managed by two independent StackSets:

Each deploys and destroys independently via ./deploy.sh spoke and ./deploy.sh docs.

Before you build custom audit infrastructure, look at what AWS already gives you:

• CloudTrail: every SSM StartAutomationExecution, S3 PutObject, and EC2 API call is already logged with the IAM principal, source IP, timestamp, and full request parameters.
• SSM Automation History: ssm:DescribeAutomationExecutions returns the full execution history — status, timing, target accounts/regions, and the document name.
• S3 Object Metadata: compliance reports carry S3 object metadata (operator, cve-id, environment, severity, decision-type, sla-met, team, product, frameworks), queryable via S3 Inventory + Athena without reading the JSON body.
• CloudWatch Logs Insights: agent logs include structured PATCH_EXECUTED: entries with operator, environment, instance count, and execution ID, all searchable in real time.

The custom S3 compliance reports fill the gap CloudTrail leaves: business-level context like SLA assessment, before/after compliance delta, and framework attribution.

Future enhancement: pass IAM session tags (e.g., operator={email}) on AssumeRole calls so CloudTrail attributes each action to the human operator, not just the service role. Right now the operator identity flows through the compliance report and CloudWatch logs, but not the CloudTrail session context.

• Custom domain: register a domain in Route 53, point an alias record at the ALB, and use an ACM public certificate. Clean URL, no cert warnings.
• AWS Client VPN: for internal-ALB mode, deploy a Client VPN endpoint in the VPC so the wider team can reach the UI beyond individual SSM tunnels.
• VPC endpoints: add interface VPC endpoints for SSM, EC2, S3, STS, and Bedrock to cut NAT gateway traffic and data transfer cost.
• WAF: put AWS WAF in front of the public ALB for request filtering, SQL injection protection, rate limiting, and managed rule sets.

• S3 bucket retention: switch removalPolicy to RETAIN and drop autoDeleteObjects in core-stack.ts to keep compliance reports after a stack teardown. The current default is DESTROY for a clean teardown.
• S3 Object Lock: turn on Object Lock (compliance mode) to make audit data immutable — no accidental or malicious deletion.
• KMS encryption: replace S3-managed encryption with a customer-managed KMS key. That gets you key rotation policies and CloudTrail key-usage auditing.
• Cross-account backup: replicate the compliance reports bucket to a separate audit account with S3 Cross-Region Replication.

• Multi-AZ Fargate: bump desiredCount to 2+ in ui-stack.ts for high availability. The ALB already spans multiple AZs.
• Auto-scaling: add ECS Service Auto Scaling based on CPU/memory or request count.
• Multi-region: deploy to a secondary region with Route 53 health checks for DR. The agent is stateless, so failover is straightforward.
• ALB health check tuning: tighten the thresholds for faster failover, and consider a deeper check that validates downstream connectivity.

• Guardrails: run python agent/setup_guardrail.py to create a sample guardrail, then extend it with more denied topics, PII redaction, and custom word filters. See the Bedrock Guardrails docs.
• Token budget limits: set per-invocation token limits so a runaway conversation can't spiral.
• Dead letter queue: add an SQS DLQ for failed agent invocations.
• Idempotency: add idempotency keys so a retry doesn't patch twice.

• CI/CD pipeline: add CodePipeline or GitHub Actions. Run npx tsc --noEmit and Python linting on PR, deploy to staging on merge, and promote with a manual approval.
• Infrastructure testing: add CDK snapshot tests and integration tests.
• CloudWatch dashboards: build one with agent invocation count, latency P50/P99, error rate, patch success rate, and SLA compliance percentage.
• CloudWatch alarms: agent error-rate spikes, unhealthy Fargate tasks, ALB 5xx rate, SLA breach count → SNS → PagerDuty/Slack.
• Cost monitoring: tag every resource with Project=patch-automation, set up AWS Budgets alerts, and watch Bedrock token usage in GenAI Observability.

Swap the self-signed certificate for an ACM public certificate tied to your domain — it's free, auto-renewing, and drops the browser warnings:

1. Request a certificate in ACM with DNS validation.
2. Add the CNAME record to Route 53.
3. Set the ARN in .env as ACM_CERTIFICATE_ARN.
4. Redeploy: ./deploy.sh ui.