AegisAI propagates the calling user's identity through STS AssumeRole chains, AWS SSO, and IAM Identity Center — so RDS row-level security, S3 bucket policies, and Bedrock agent permissions all evaluate against the actual user, not a Lambda execution role with AdministratorAccess.
✓ LIVE: RDS Data API with STS-chain identity propagation. SAP/cloud auth-object check framework.
⧉ EARLY ACCESS · Q3 2026: Bedrock middleware (sit-in-front-of agent tool calls), Lake Formation TBAC per-user, Aurora Serverless v2 per-user scaling, IAM Identity Center federation
⧉ ROADMAP · Q4 2026: S3 Access Points per-identity, Athena per-user workgroup attribution, Performance Insights per-user grouping, Redshift IAM Identity Center, Bedrock Knowledge Bases per-user vector filters
The architectural primitives (STS chains, federated identity propagation) are built once and reused. Each new service integration is ~5 engineer-days against a customer sandbox.
AWS gives you the deepest identity model of any cloud — cross-account assume-role chains, IAM Identity Center, SCP guardrails, Lake Formation row/column controls, RDS IAM auth, Bedrock agent permissions. The naive AI assistant pattern: one Lambda with one execution role, broad scope. Every control above gets bypassed.
AWS Organizations means 50–500 accounts is normal. Your AI assistant needs to span them. A shared-credential approach breaks SCP enforcement and turns audit attribution into a guessing game.
Lake Formation row filters and column-level grants apply per-principal. When your AI integration becomes a shared service principal, the per-user controls become per-service-principal controls — meaningless.
Bedrock agents that query RDS or S3 use an agent execution role. That role's scope is fixed at deploy time. Per-user behavior requires the underlying call to be made under the user's identity — not the agent's.
AegisAI exchanges the user's IdP-issued JWT for an STS-assumed-role session bound to that user's federated identity. The AWS API receives the request authenticated as the actual user. Every native AWS control fires as designed.
The user's federated identity becomes an RDS IAM database principal. Row-level security policies, GRANT statements, and SCRAM auth fire against the user, not the integration role. RDS Performance Insights and Database Activity Streams show the actual user's queries.
Redshift's native federation with IAM Identity Center maps the user's SSO identity to Redshift roles. Lake Formation column-level grants apply per-user. S3 bucket policies and Object Lambda transformations evaluate against the user's session.
Instead of a Bedrock agent calling RDS via a fixed execution role, AegisAI sits in front of the agent's tool calls. The tool invocation arrives at RDS under the calling user's federated identity. Bedrock Knowledge Bases queries against OpenSearch Serverless or Aurora pgvector respect per-user row filters.
Multi-account architectures stay enforced. AegisAI's STS chain crosses accounts under the user's identity. Service Control Policies in the management account still apply. Account-level guardrails still fire.
CloudTrail entries show the actual user's federated identity. SOC 2 audits stop being a hunt-and-correlate exercise across logs.
Service Control Policies at the Organizations layer still gate access. The AI assistant cannot accidentally route around them.
Per-user cost tags propagate. Finance can finally answer "who's driving our AI compute bill?" with names, not integration accounts.
Column-level grants and row filters work as designed — per user, not per integration principal. Your data governance team stops re-arguing scope.
30-minute architecture call. We open the operator console and run real queries through your stack — AWS, Azure, GCP, or all three. You see the audit chain tick up in real time.
