AAA Sentinel
Secure access

How we enter your account

Giving a third party access takes trust. We read costs, what is open, and AI spend. We write only if you grant the agents' role.

Start for free now AAA Sentinel — Security

Cloud, security and AI. We read when you connect; write is a second role, the agents' role.

Illustrative example

Cloud

AI services

By default

We read costs, inventory, AI spend and whether anything was left open. Nothing is written.

If you grant the role

Agents apply what you approve: costs, exposure and AI spend.

Read by default

Read by default

The AWS, Azure or GCP role, and the keys for AI services, connect in read-only. Write lives in a second role, the agents' role: you create it, you approve each action. Without that role we do not stop or delete anything.

  • AWS: CloudFormation role with ViewOnlyAccess and SecurityAudit (we read metadata and configuration, not data in your databases or Secrets Manager or Parameter Store values; we do not store the values of function environment variables) and Cost Explorer; plus only reading your FOCUS export and searching logs for traces if you turn on flows
  • Azure: Service Principal with Reader and Cost Management Reader (no Contributor or Owner)
  • GCP: Service Account with read roles (Viewer) and read access to billing in BigQuery, no Editor
  • The autonomous agent (Business plan) requires a second role that you grant voluntarily
  • If you revoke the role, AAA Sentinel loses access immediately

By default

  • Costs and inventory
  • What is open or misconfigured
  • AI spend and usage

With the agent

  • Close exposure you approve
  • Start and stop on the schedule
  • Act in cloud, security and AI
KMS encryption

KMS encryption of credentials

Azure, GCP and AI service keys are stored in a private S3 bucket, encrypted with AWS KMS and our own key. For AWS we store no keys: only the role ARN.

  • Customer Master Key (CMK) rotated automatically every year by AWS
  • S3 server-side encryption with KMS (SSE-KMS)
  • AES-256 symmetric encryption
  • The master key never leaves the AWS KMS HSMs
  • The functions that use the credentials get decrypt permission through IAM; the bucket blocks public access

  1. You generate a cloud credential

    Azure Client Secret, GCP Service Account key or AI API key

  2. We seal the envelope

    KMS encrypts the credential. The master key never leaves AWS.

  3. Stored encrypted in S3

    Private, versioned bucket, HTTPS only. The master key never leaves KMS.

ExternalId

A unique code per organization

The confused deputy attack lets a malicious third party assume an IAM role in your account by impersonating a legitimate service. To prevent it, your organization has a random 128-bit code that your AWS role requires as the ExternalId.

  • Random, 128 bits: not derived from any data about your organization
  • Generated once and the same for every AWS account in your organization
  • Without the correct ExternalId, AWS rejects any AssumeRole
  • Prevents confused deputy attacks even if the role ARN leaks
  • You see it in the connection wizard because it goes in your role's trust policy

With your unique code

AAA Sentinel requests access with your organization's code. Your role recognizes it and lets it in to read.

Without your code

Another account, even if it knew the role name, does not have your code. The cloud refuses access.

Without this exact ExternalId, any AssumeRole attempt is rejected by AWS.

JWT + Cognito

JWT + Cognito

Authentication with Amazon Cognito (User Pools + Hosted UI) for people and OAuth2 Client Credentials with 1-hour HS256 JWTs for the API. API tokens carry your organization and its scopes.

  • 1-hour tokens with automatic refresh
  • The organization and role are resolved on the server from your user, not from the request
  • The session travels in an httpOnly cookie and is verified by an API Gateway Lambda authorizer
  • API tokens (Client Credentials) are signed with HS256 and a secret stored in Parameter Store (SecureString)
  • Separate rate limiting for API tokens
  • If your organization requires MFA, the API checks it on every request, owner included; people who sign in with Google or company SSO handle it in their identity provider
  • Restriction of allowed email domains for login and invitations
  1. 01

    You sign in

    Sign-up, sign-in and recovery go through Cognito.

  2. 02

    We check who you are

    MFA and email domain, if your organization requires them.

  3. 03

    You get a session token

    Signed, short-lived, with your organization inside.

  4. 04

    Every request carries that organization

    The API never takes the tenant from the request body.

Tenant isolation

Tenant isolation

Each organization's data is stored under its organization identifier. That identifier comes from your verified session, never from what the request sends.

  • DynamoDB: tables are partitioned by organization; scans and findings by account, and the account is checked against your organization first
  • The organization comes from the authenticated user, not from the request body
  • Without a signed, verified session or token, no organization is resolved
  • Each account is looked up with your organization's key; if something does not match, access is denied and logged as a security incident

Your organization

Looks up findings and costs for your accounts.

Sees only its own data

Another organization

Tries to read the same data.

Blocked: different tenant

Each organization only sees its own rows. The organization comes from the session, never from the request.

Audit log

Audit log

Every relevant action (scans, configuration changes, access and agent actions) goes into a dedicated DynamoDB table, encrypted with KMS and kept for one year. The application only appends entries: no write overwrites another.

  • DynamoDB encrypted with KMS, with point-in-time recovery (PITR)
  • 1-year retention; after that each entry expires on its own
  • Fields: date, organization, actor (person, token, agent or system), action, resource and result
  • Agent actions are recorded with their proposal, approval and execution
  • You can view your activity and export it as CSV from your profile

Sample audit record

Illustrative example

  1. Today, 09:12

    Posture scan of production

    Scheduled · read-only

  2. Today, 11:40

    Ana approved stopping staging-web-03

    Agent · with write permission

  3. Today, 16:05

    Exposure alert sent to the channel

    Notification · no change in the cloud

Secrets

Secrets

Platform secrets (API token signing, payments, bot verification) live in AWS Systems Manager Parameter Store as SecureString and are read at runtime. The Jira and Linear keys you configure are stored in DynamoDB, encrypted with our KMS key, and the interface only shows them masked.

  • Master key rotation

    AWS rotates the KMS key every year

  • Encryption at rest

    Parameter Store SecureString and KMS-encrypted tables

  • No env vars

    Loaded at runtime via SDK

Connect your account with the rules in the open

Read when you connect. Write only if you grant the agents' role. To see what is open in your accounts, go to Security.

Start for free now

No card · Read when you connect · Write if you grant it