How Trueno accesses AWS, isolates your data, and stays out of your write path.

Trueno never asks for AWS access keys. Access is short-lived, external-ID gated, and revocable in one step.

1. 01

   You create a read-only IAM role

   In your AWS account, you create a tiny IAM role whose trust policy names the Trueno principal and the external ID you generated in the dashboard.

2. 02

   You attach AWS-managed read-only policies

   Examples: ReadOnlyAccess, SecurityAudit, AmazonEC2ReadOnlyAccess. No custom policies, no write actions. You choose the exact policy set during onboarding.

3. 03

   Trueno assumes the role via STS

   On each scan, the platform calls sts:AssumeRole with your external ID. STS returns short-lived credentials. Nothing is persisted server-side beyond the role ARN and the external ID hash.

4. 04

   Read-only AWS API calls happen on the server

   All AWS SDK calls originate from server-side code marked import "server-only". SDK packages never ship in the client bundle.

• Row-level security on every workspace table

  Findings, resources, scans, recommendations, comments — every row carries an organization_id, and every read is gated by an RLS policy. A workspace cannot read another workspace's rows even if the application code regressed.

• Service-role writes are scoped to system paths

  Only the async processor and scan runners use the Supabase service-role key. User-facing routes always use the request-scoped user client. The boundary is enforced at the repo layer.

• No cross-tenant aggregation

  We don't pool findings across workspaces. There's no "benchmark vs. your peers" feature. There's no training data extracted from your environment.

• External-ID gated trust

  Your workspace generates a unique external ID. The IAM trust policy you write in AWS includes that external ID as a sts:ExternalId condition. This defeats the confused-deputy pattern at the AWS layer, not just in our application.

You revoke Trueno's access from your AWS console, not from the Trueno dashboard. The IAM role you created is the single point of access. Delete it and the relationship ends.

1. 1

   Open the AWS IAM console and delete the role Trueno assumes.

2. 2

   From that moment forward, AssumeRole calls return AccessDenied — no further scans can run for that account.

3. 3

   Optionally, also disconnect the account in /dashboard/aws-accounts to remove the stored ARN and external ID.

The biggest risk in a security page is overclaiming. Here is what we have NOT done yet:

• No SOC 2 / HIPAA / ISO 27001 / PCI-DSS today

  We are early access. None of these certifications have been audited or are in flight. We will publish the roadmap once a customer commits to a paid plan that requires one.

• No bug bounty program yet

  Responsible-disclosure reports are welcome at the contact below — but there is no monetary reward or formal program in place during early access.

• No penetration test on file

  The platform has not been third-party pentested. We rely on Next.js, Supabase, and Vercel's hardened defaults, plus the AWS read-only access model. This will change before GA.

• Backups are managed by Supabase

  Workspace data lives in Supabase Postgres. Backups follow Supabase's published policy. We do not maintain a separate backup pipeline today.

Email info@gigant.tech with the workspace id, the affected behavior, and any reproduction steps you have. We respond from real engineers, not a bot.