Platform Data Security & Tenancy

This page describes how the Onam platform itself protects your data: how tenants are kept apart, what is stored, how your cloud credentials are handled, and what Onam can do in your cloud accounts. The Trust Center is the authoritative, current version of this information.

Looking for the product feature that classifies PII in your buckets and databases? That is Data Security (DSPM) — a scanning engine, documented under Features in the sidebar. This page is about the security of the platform, not a feature of it.

Tenancy and isolation

Every customer's data carries a tenant identifier, and every request is checked at more than one layer.

Multi-tenant isolation — three-layer enforcement at gateway, engine, and database

API gateway. The gateway validates the session and constructs an AuthContext — tenant ID, role, permissions — on the server. Engines never trust client-supplied identity.
Engine permission check. Routes require the matching feature:action permission (e.g. findings:read, scans:create). Unauthorized calls get HTTP 403.
Database. In the main databases, PostgreSQL row-level security policies make the database itself refuse to return another tenant's rows.

What is stored — and what is not

Stored: configuration and metadata from your clouds, findings, the asset and attack-path graph (PostgreSQL and Neo4j), and your users' account details.
Audit log: reads of the product's data views are recorded — who, what, when, from where, and the result.
Not read or stored: posture scanning and data classification read configuration and metadata; they do not read the contents of your files, objects or database rows.
AI Code Fix only: when you run a fix, the repository is cloned for that run and the clone is deleted when it finishes. The Git token is used for that request only and is never stored or logged.

Credential handling

Cloud	What you create	Access level
AWS	An IAM role that Onam assumes with an External ID	AWS-managed SecurityAudit and ReadOnlyAccess policies, read of AWS Organizations account lists, and permission to start Onam's scan workflow in your account
Azure	Role assignments for Onam's service principal	Built-in Reader and Storage Blob Data Reader
Google Cloud	A service account	Viewer, Cloud Asset Viewer and Security Reviewer; billing read only if you opt in
Oracle Cloud (OCI)	A dedicated user and group	Read policies across the tenancy, including users, groups, policies, vaults, keys and secret metadata
Alibaba Cloud	A dedicated RAM user	A dedicated read-only RAM policy
IBM Cloud	A service ID	Viewer-level (read-only) access, scoped to a resource group

Where a cloud needs a stored credential (for example an OCI API key or an Alibaba Cloud access key), it is kept in AWS Secrets Manager, which encrypts it with AWS KMS. For AWS no secret is stored — Onam assumes your role. The AWS trust policy your CloudFormation stack creates looks like this — note the ExternalId condition, which prevents confused-deputy attacks:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::<ONAM_ACCOUNT_ID>:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": { "sts:ExternalId": "<your-unique-external-id>" }
  }
}

Revoking the role or credential in your cloud cuts off Onam's access.

What Onam can do in your cloud accounts

Posture scanning is read-only. It uses read permissions only.
Agentless workload scanning runs inside your account. If you enable it (AWS, Azure, Google Cloud), the template also creates resources in your account: a scan workflow, short-lived scan machines built from disk snapshots, and a storage bucket for results. Those resources hold the permissions needed to create and delete snapshots and scan machines; Onam's own role can only start that workflow, not create or delete resources itself. Leftover scan resources are removed automatically after a set number of hours.
Broad read policies. AWS's ReadOnlyAccess policy and Azure's Storage Blob Data Reader role are broad enough to read stored objects, not only configuration. Onam requests them so data security posture management can locate where sensitive data lives.

You grant access with a template run in your own account, so you can read every permission before you deploy it.

The security domains all share the same tenancy and access model

Encryption

At rest: customer data is encrypted at rest. Stored credentials are encrypted by AWS KMS through Secrets Manager.
In transit: data is encrypted in transit for all customer-facing and service-to-service traffic, with one internal job being moved to TLS. Browser-to-Onam traffic uses HTTPS.

Data residency, backups and deletion

Onam runs on AWS, in the region agreed with you — US, Europe, India or other regions — so you can meet your own compliance requirements. Databases are backed up with AWS Backup. Customer data is kept for 30 days after a customer deactivates, then deleted. See Data Retention.

Frequently asked questions

Do you store samples of my data? No. Posture scanning and data classification read configuration and metadata; they do not read the contents of your files, objects or database rows.

What exactly can you do in my cloud account? Posture scanning only reads. If you enable agentless workload scanning, resources created in your account by the template take and delete snapshots and run short-lived scan machines; Onam's role can only start that workflow.

Where are my credentials kept? Where a stored credential is needed, in AWS Secrets Manager, encrypted with AWS KMS. For AWS, no secret is stored.

Next steps

Trust Center — the authoritative summary of how Onam protects your data
Architecture overview — the 29 engines and the tenant-isolated data model in context
The scan pipeline — what those credentials are used for, stage by stage
Book a demo — bring your security reviewer

Scanning Engine

Overview