• Account & identity data — the work email, display name, role assignment, and business-unit scope of each authorized user, plus a password hash for password-based accounts. Sign-in today uses email and password over standard OAuth2 token auth; when SSO becomes available, we will receive the identity attributes your provider asserts and will disclose them here.
• Organization & configuration data — your organization profile, role and segregation-of-duties configuration, tenant preferences, and — when provider connections become available — connected-provider settings.
• Connected-provider data (when provider connections become available) — credentials or tokens for the systems you choose to connect, and the telemetry and financial data ingested from them (see “Connected providers” below). Ingestion will be read-only. Today, agents report their own telemetry and spend through a single ingest endpoint; no provider credentials are collected.
• AI inventory & value data — the agents, models, owners, cost and capacity records, value claims, baselines, rate cards, evaluation results, risk findings, and attestations you and your team record in the service.
• Audit & evidence data — an immutable, hash-chained record of mutating actions (who did what, when) that underpins the audit pack. This is core to the product, not optional telemetry.
• Operational logs — security, performance, and diagnostic logs, including records of model/API calls made to render the service.

Today, Oabo does not connect to provider accounts: agents register themselves and report usage and spend through a single telemetry endpoint, so no provider credentials are collected. Direct provider connections are on our roadmap. When they become available, Oabo will ingest usage, spend, and headcount signals from systems you choose to connect, so the value math traces to your real data rather than to figures typed into a spreadsheet — for example model and infrastructure platforms for usage and cost telemetry (OpenAI, Anthropic, AWS, Azure, Snowflake) and finance and people systems for the general-ledger and headcount side of the math (NetSuite, Workday, Stripe).

When provider connections become available, they will be read-only ingestion: Oabo will pull the data needed to compute and reconcile value and will not write back to, modify, or delete anything in your source systems. Here, Stripe would be a spend/revenue data source you connect — not a consumer payment processor acting on your behalf. Credentials and tokens for connected providers will be encrypted at rest and never exposed to the browser; we will disclose the details here before the feature ships.

Oabo does not use Google OAuth and does not access, request, or process data from Google APIs (such as Gmail, Google Calendar, Google Drive, or Google Contacts) to provide the service. Because Oabo does not receive information from Google APIs, the Google API Services User Data Policy, including its Limited Use requirements, does not currently apply to Oabo. If we introduce a Google integration in the future, we will request only the minimum scopes required, disclose them here, and handle any Google user data in accordance with that policy, including its Limited Use requirements.

• To provide the service — recording AI inventory, computing the value ledger, running governance and performance views, and generating the audit pack.
• To authenticate users and enforce role-based access, segregation of duties, and business-unit scoping.
• To maintain the immutable audit trail your auditors and regulators rely on.
• To secure, monitor, debug, and improve the service.
• To communicate with authorized users about the service, including security and operational notices.

We do not sell customer data, and we do not use the business data you bring to Oabo to train AI models for other customers.

Oabo is multi-tenant and org-scoped. Every record is bound to a single organization, and access is filtered by organization on every request — a user who attempts to reach another organization’s data is treated as if it does not exist. Within an organization, the nine roles, segregation-of-duties rules, and business-unit scoping determine which slice of data each user can see and which actions they can take.

• Subprocessors — vetted infrastructure and operational providers (such as cloud hosting and, where applicable, model providers) used to run the service under contractual confidentiality and data-protection terms. A current subprocessor list is available to customers on request.
• Your connected providers — when provider connections become available, we will read data from the systems you connect; we will not send your Oabo data back to them.
• Legal & safety — where required by law, or to protect the rights, safety, and security of Oabo, our customers, or the public.
• Corporate transactions — in connection with a merger, acquisition, or sale of assets, subject to this policy.

We do not share customer data with advertisers and we do not sell it.

Data is encrypted in transit with TLS and at rest. When provider connections become available, provider credentials and tokens will be encrypted at rest and never returned to the client. Access is governed by authentication, role-based authorization, segregation of duties, and tenant isolation, and every mutating action is written to an immutable, hash-chained audit log. No method of transmission or storage is perfectly secure, but we maintain administrative, technical, and organizational safeguards appropriate to the sensitivity of the data.

We retain customer data for as long as the organization’s account is active, and thereafter as needed to meet legal, audit, and contractual obligations. Because the audit trail is intentionally immutable, historical evidence records are preserved for the duration governed by the customer agreement.

Authorized administrators can access, correct, export, and request deletion of their organization’s data, subject to the customer agreement and applicable law. Individual users should direct personal-data requests to their organization (the controller); we will support our customers in fulfilling them.

We may update this policy as the product and our practices evolve. Material changes will be communicated to customers through the service or by email, and the “last updated” date above will change.

Privacy questions and requests should use the contact channel provided in your Oabo account or customer agreement.