Security starts with how we handle yours.
ROS is a security decision platform. The people who buy it are CISOs and security-conscious operators who will scrutinize our own posture before they trust us with a connector to theirs. This page explains — specifically and honestly — how we protect what you share with us.
Written by the Sapien9 security team. Last reviewed July 2026.
The principles behind the platform
Each section below maps to a specific design decision or implementation detail — not a marketing claim. Where we cite technical specifics, you can verify them in the source.
Read-only and non-intrusive by design
ROS connectors that use your provider APIs (AWS, GitHub, Okta, Google Workspace) communicate exclusively through read-only API calls and cannot write, create, update, or delete resources. The one exception is the external attack-surface scan, which — by nature — sends network requests; it uses only safe, non-intrusive detection probes (never exploitation) against the targets you explicitly designate, and holds no credentials to your systems.
- AWS: Prowler runs read-only CSPM checks against S3 and IAM using your credentials passed via environment variable — never as CLI arguments.
- GitHub: Uses a read-only Personal Access Token. The connector calls GET endpoints only: org metadata, secret scanning alerts, repo listings, and branch-protection status.
- Okta: Reads password policies, MFA enrollment policies, and active user lists via GET /api/v1/policies and GET /api/v1/users. No Okta mutations are issued.
- Google Workspace: Uses the Admin SDK Directory API in read-only mode to enumerate users and 2-Step Verification enrollment status.
- External surface (Nuclei): a detection-only scanner. It fingerprints technologies, misconfigurations, and exposures on the hosts you list — it does not run exploitation or intrusive payloads, and it authenticates to nothing. You control which targets are in scope.
- For the API connectors, the read-only constraint is enforced at the token-scope level, not just in application code: a scoped read-only token has no permission to mutate even if the code tried.
Least privilege
ROS requests the minimum token scope required to read the specific signals it assesses. You are never asked for administrative or write access.
- AWS: Credentials are used only to invoke Prowler against the s3 and iam service scopes. A read-only policy (e.g., SecurityAudit) is sufficient and recommended.
- GitHub: Required scopes are read:org (2FA enforcement), secret_scanning_alerts:read (exposed secrets), and repo (branch-protection metadata). No write, admin, or delete scopes.
- Okta: A read-only API token is sufficient. ROS does not request Super Administrator or application-creation rights.
- Google Workspace: A service account with the Admin SDK Reports API and Directory API read scope. No domain-wide write delegation is required.
- External surface (Nuclei): requires no credentials at all — it only needs the list of hostnames you want assessed.
- Connection credentials are stored encrypted (AES-256-GCM) and are only decrypted in-process, in server-only code, at scan time.
Encryption at rest
Every credential and session token ROS persists is encrypted using modern, authenticated cryptography. We do not store plaintext secrets.
- Connection credentials (API tokens, access keys): AES-256-GCM with a per-encryption random 96-bit IV. The GCM authentication tag prevents ciphertext tampering. Scheme prefix v1 enables future key rotation.
- Encryption keys: Derived from the master secret using HKDF-SHA256 with a named purpose string ("aegis-cred-enc"), so the signing key and the encryption key are cryptographically independent.
- Passwords: Hashed with scrypt (N=2^14, r=8, p=1 in Node defaults) using a 128-bit random salt per user. Comparison is performed with timingSafeEqual to prevent timing attacks.
- Session cookies: HMAC-SHA256 signed using a separately derived key ("aegis-cookie-sign"). The payload is base64url-encoded; the MAC is appended and verified on every request.
- In demo mode with no AEGIS_SECRET set, an ephemeral random 256-bit key is generated at startup. Sessions and credentials do not survive a restart, which is by design for a demo environment.
Data minimization
ROS stores security findings, evidence artifacts, and assessment metadata — not your data plane. We do not exfiltrate user records, application data, or business content.
- GitHub: ROS stores the alert number, secret type name, and repository full name from secret-scanning alerts. The actual secret value is never returned by the GitHub alerts API and is never stored.
- AWS: Prowler OCSF output records (control check results, resource identifiers, remediation text) are parsed and stored. S3 object contents and IAM policy documents are not stored.
- Okta: Policy configuration metadata and aggregate user counts (e.g., number of dormant accounts) are stored. Individual user passwords, tokens, or personally identifiable profile data beyond login counts are not stored.
- Google Workspace: Admin count and 2SV enrollment status per user are stored. Email body content, Drive files, and calendar data are never accessed.
- External surface (Nuclei): only the matched template id, name, severity, and the matched URL are stored — enough to describe the finding, nothing more.
- Evidence artifacts contain source, control mapping, and a structured summary — not raw data dumps from your environment.
Multi-tenant isolation
Every assessment, connection, finding, and evidence artifact is scoped to an organization. Cross-tenant data access is prevented at the data model level.
- All database records carry an orgId foreign key. API routes validate the authenticated session orgId before any query is executed.
- Connection credentials are encrypted with a key derived from the platform master secret, not an org-specific secret. This means the application layer enforces isolation — a defense-in-depth architecture.
- Assessments and their findings are only retrievable by the organization that ran them. There is no shared findings pool.
- Session tokens are HMAC-signed and carry the orgId in the payload. Tampering with the orgId claim invalidates the MAC.
Audit trail
Every assessment run, finding, and evidence artifact is persisted with a timestamp and provenance. You always know what was checked, when, and what was found.
- Assessment records include start time, completion time, provider, and the number of resources scanned.
- Each finding carries an externalId derived from the source system (e.g., aws:prowler:<uid>, github:secret-alert:<number>:<repo>), making findings traceable back to the originating system.
- Evidence artifacts record the NIST CSF control they map to, the source connector, and a structured data snapshot taken at scan time.
- Board-ready reports are generated from this persisted record — not recomputed on-the-fly — so the report reflects exactly what the assessment found.
- Prowler scan output is cleaned up from the local filesystem after parsing; only the normalized findings are retained.
Where we are, and where we are going.
We will not overstate our certification status. The table below reflects the current, honest state of our compliance program. We update it as status changes.
- SOC 2 Type IIIn progress
SOC 2 Type II — in progress. We are building the operational controls and evidence collection program required for a Type II audit. We will share the report under NDA with enterprise customers and partners when it is complete.
- NIST CSF 2.0By design
ROS maps all findings and evidence to NIST CSF 2.0 functions (Identify, Protect, Detect, Respond, Recover). The platform is designed around this framework at the data model level.
- HIPAABy design
ROS does not store PHI. Customers in healthcare use ROS to assess their own HIPAA technical safeguard posture. A Business Associate Agreement (BAA) is available for enterprise customers.
- CMMC Level 2Planned
CMMC Level 2 assessment support is on the roadmap. ROS already maps findings to NIST SP 800-171 controls, which form the CMMC L2 practice set.
- NIST AI RMFBy design
AI governance assessments within ROS are structured around the NIST AI RMF (Map, Measure, Manage, Govern) taxonomy. The platform itself is evaluated against these principles.
- ISO 27001Planned
ISO 27001 certification is on the compliance roadmap following SOC 2 Type II completion.
Honest disclosure: SOC 2 Type II is in progress, not complete. If your procurement process requires a current SOC 2 Type II report, please contact us to discuss a design-partner arrangement with contractual security commitments while we complete the audit cycle.
Third parties that process data on your behalf
We maintain a complete list of subprocessors and will notify customers of material changes with reasonable advance notice.
Anthropic (Claude API)
United States (Anthropic-managed)AI reasoning engine. ROS sends anonymized, structured finding summaries to Claude for risk-prioritization reasoning and narrative generation. Raw credentials and PII are never included in these payloads.
Privacy policyInfrastructure (US / EU)
US / EUApplication hosting, database, and object storage. ROS operates on infrastructure in US and EU regions. Data residency preferences are available for enterprise customers.
Privacy policyAnthropic payload scope: When ROS sends data to the Claude API for reasoning, it sends structured finding summaries — control IDs, severity, remediation text, and resource identifiers (e.g., a repo name or IAM policy name). It does not send raw API tokens, passwords, S3 object contents, user email addresses from identity providers, or any other credential or personal data. Anthropic processes these payloads under their API Terms of Service and Privacy Policy.
Report a vulnerability or ask a hard security question.
If you believe you have found a security vulnerability in ROS, please report it responsibly. We commit to acknowledging your report within two business days and to keeping you informed as we work toward remediation.
Security questionnaires, penetration test requests, and compliance inquiries are also welcome at the same address.
PGP key available on request. Please do not report vulnerabilities via public GitHub issues.
See the assessment in action.
The public demo runs on a fictional, anonymized client with seeded data — no real systems are touched. In a real assessment, every API-connector call is read-only and the external surface scan is non-intrusive. You can watch the agent reason about findings in real time.