Security

• All customer data is hosted in AWS eu-west-1 (Ireland). Nothing is processed or stored outside the EU by IRIS itself.
• We never store your AWS credentials. Access is granted via cross-account IAM role assumption with a customer-controlled external ID.
• AI provider keys (OpenAI, Anthropic) are encrypted at rest in AWS Systems Manager Parameter Store using AWS KMS, scoped per organisation.
• All databases use AWS-managed encryption at rest and point-in-time recovery.
• All traffic between your browser, our API, and AWS services uses TLS 1.2+.
• IRIS is operated by a small UK-based team. Access to production is restricted to engineers who need it, and audited via AWS CloudTrail.

From your AWS account, via a read-only IAM role:

• Cost & Usage data via AWS Cost Explorer (Get*, Describe* operations).
• Resource metadata for compute, storage, and database services (e.g. EC2 instance types, RDS sizing, S3 bucket counts) — names, IDs, regions, tags. No object contents, no database rows.
• CloudWatch metrics used for rightsizing recommendations (CPU, memory, network averages).

From your AI provider accounts, via your own admin keys:

• OpenAI: usage and cost data via the Usage and Costs APIs.
• Anthropic: usage and cost data via the equivalent admin endpoints.

IRIS does not read prompts, completions, customer data inside your services, or any payload data. We only read the metadata required to compute and explain spend.

You don't give us AWS keys. Instead, you create an IAM role in your account (IrisScannerRole) that trusts the IRIS production AWS account, gated by an external ID secret that only your team and IRIS know.

The role is granted least-privilege, read-only permissions: Get*, Describe*, List*. IRIS cannot create, modify, or delete anything in your account. You can revoke access at any time by deleting the role — no IRIS action required.

OpenAI and Anthropic admin keys, when you connect them, are encrypted at rest in AWS Systems Manager Parameter Store as SecureString values, encrypted with the AWS-managed KMS key (alias/aws/ssm).

Keys are stored under per-organisation paths: /iris/{env}/orgs/{org_id}/{provider}_api_key. The IRIS API task role is scoped to read and write only under /iris/{env}/orgs/*. No engineer at IRIS has direct console access to your keys; access is logged in CloudTrail.

• Compute: AWS ECS Fargate, eu-west-1 (Ireland).
• Database: Amazon DynamoDB, eu-west-1. Point-in-time recovery enabled. Encrypted at rest with AWS-managed KMS keys.
• Object store: Amazon S3, eu-west-1. Encrypted at rest with AWS-managed KMS keys. Used to hold daily snapshot data per organisation.
• User authentication: Amazon Cognito, eu-west-1.
• Logs and metrics: Amazon CloudWatch, eu-west-1. Logs scrub credentials and request bodies.
• Frontend: Vercel (global edge network). The frontend serves UI assets and proxies API requests to our eu-west-1 backend; no customer data is stored at the edge.

IRIS is multi-tenant. Customer data is partitioned by org_id at the row level inside shared DynamoDB tables. Every API request is authenticated via Cognito or an IRIS API key; the resulting org_id is attached to the request server-side and used as a query filter on every read and write.

org_id is never read from the request body or query string — this is an architectural rule enforced in code, so a forged or malformed request cannot reach another organisation's data.

• In transit: TLS 1.2+ for all browser → API, API → AWS, and API → AI-provider traffic.
• At rest (database): AWS-managed KMS keys on DynamoDB.
• At rest (object store): AWS-managed KMS keys on S3.
• At rest (secrets): AWS-managed KMS keys on Systems Manager Parameter Store (SecureString).

• Production access is limited to a small set of engineers using IAM users with MFA enforced and short-lived session credentials.
• All production AWS API calls are logged in CloudTrail.
• There is no shared, long-lived production database password. All database access is via IAM-authenticated AWS service roles.
• Code changes to production go through pull request review on GitHub and are deployed via CI/CD.

• DynamoDB point-in-time recovery is enabled on all customer-data tables, allowing restoration to any second within the last 35 days.
• S3 buckets retain prior versions of daily snapshots.
• We do not export backups outside AWS eu-west-1.

IRIS uses a small set of subprocessors to operate the service:

International transfers to US-based subprocessors rely on Standard Contractual Clauses and the providers' respective data processing addenda. Customers can opt out of the IRIS chat feature to avoid Anthropic processing of their data on a per-organisation basis.

If you believe you have found a security issue in IRIS, please email security@irislabs.co.uk. We aim to acknowledge reports within 48 hours and will keep you updated on remediation. We do not currently run a paid bug bounty, but we're happy to credit researchers (with permission) for responsibly disclosed issues.

IRIS is a young company. We are not yet SOC 2 or ISO 27001 certified. We have built the platform with those frameworks in mind — least-privilege IAM, encryption at rest and in transit, audit logging, multi-tenant isolation enforced in code — and we plan to pursue formal certification as the company grows. If you need a security questionnaire completed for procurement, email security@irislabs.co.uk and we'll get it back to you quickly.