wif.tax

Obsidian Security

F Obsidian Security Platform

Obsidian's API takes a static bearer token made by an admin in the console. Third-party docs tell you to set its expiry to "Forever". How Obsidian connects into your SaaS tenants is documented only behind login; the one public outbound setup, pushing data to Microsoft Sentinel, has you hand Obsidian an Entra app client secret.

Docs: docs.datadoghq.com · Checked 2026-10-13 · source YAML · dispute via PR

Inbound F

How a workload running anywhere authenticates to this product.

Static API token created by an admin under Settings > API access tokens and sent as "Authorization: Bearer <token>" to the regional API server (api.obsec.io, api.obsec.eu, etc.). No federation, OAuth client-credentials or other short-lived token path is publicly documented.

Obsidian's own API docs are gated (the docs.obsec.io host returns 404 publicly), so the inbound story comes from third-party connector docs (Datadog, Axonius) and Obsidian's own public Codex plugin on GitHub, which reads OBSIDIAN_API_TOKEN from the environment and sends it as a bearer token. All three describe the same static API token; none mentions any alternative. Federation may exist behind login, but nothing public supports it, so the grade cannot go above F. Obsidian also ships a browser extension and offers Databricks Delta Sharing of its dataset; how the extension authenticates back to Obsidian is not publicly documented. Obsidian's Lakewatch blog says Delta Sharing recipients use "a bearer token or identity-provider federation", but that describes the Delta Sharing protocol, not an Obsidian API feature, so it does not count here.

Outbound C

How this product reaches into your cloud, repos, or other SaaS.

Public receipts cover only the Microsoft Sentinel data-sharing push. For it, the customer deploys an Entra app registration scoped to a Data Collection Rule and gives Obsidian the app's tenant ID, application ID and client secret. Setup for the 200+ SaaS connectors (Okta, Microsoft 365, Google Workspace, GitHub, Salesforce, etc.) is not publicly documented.

Low confidence. The only outbound integration with a public setup receipt is the Sentinel push. There, the customer creates an Entra app registration and a client secret and gives the secret to Obsidian. The app is scoped to Monitoring Metrics Publisher on one DCR. That matches the cohort rule for a customer-managed OAuth client secret, so it is graded C. Checked and not publicly verifiable: Okta, Microsoft 365 / Entra ID, Google Workspace, GitHub, Salesforce, ServiceNow, Snowflake, Workday, Slack and Databricks. Obsidian's integration pages for these are marketing pages with no setup or auth details, and the Okta OIN listing covers only SSO/SCIM into Obsidian. Obsidian lists no AWS, GCP or Azure subscription connectors; it covers AI platforms such as Amazon Bedrock and Azure AI Foundry, but no public page says how it authenticates to them. If the gated docs show admin-consent or OAuth app installs for the core SaaS connectors, this would likely move to B. It cannot move to A or B on public evidence today.

Hygiene for any static credential the product still issues

✗ Expiry enforceable
Tokens have an expiry-date field, so one can be set, but "Forever" is an allowed choice and partner setup guides recommend it. No public evidence shows an org policy that can force an expiry, so this fails as written.
✗ Rotation via API
Every public description creates tokens in the console UI. No token-management API is publicly documented, and the public Codex plugin's GraphQL client has no token operations. The API reference is gated, so a create/revoke endpoint may exist unseen; graded conservatively.
  • docs.datadoghq.com checked 2026-10-13
    “Click Create token and provide the following details:”
  • docs.axonius.com checked 2026-10-13
    “Admin permission is needed to create the API token.”
✓ Scoped keys
The token-creation form sets a role (with a dedicated "API" role) and a per-service and per-tenant access setting independent of the creating admin, which counts as scoping. Weak pass: the role catalog and the narrower service-access options are inferred from the Datadog guide, not shown in Obsidian's own public docs, and that guide asks for full access.
  • docs.datadoghq.com checked 2026-10-13
    “Token access > Role: Choose API.”
  • docs.datadoghq.com checked 2026-10-13
    “Service access: Enable Full data access to all services and tenants.”
✗ Last-used visible
No public source mentions a last-used timestamp on the API access tokens page. Docs are gated; graded conservatively.
  • docs.datadoghq.com checked 2026-10-13
    “Log into Obsidian Security using admin account and navigate to Settings > API access tokens.”
✗ Leak revocation
Obsidian Security does not appear in GitHub's supported secret-scanning patterns, partner or user.

Notes

Graded the Obsidian Security Platform API (the GraphQL/REST API at api.obsec.io and its regional siblings), the surface SIEM, SOAR and asset-inventory tools automate against. Obsidian documents everything behind customer login: docs.obsec.io is not public and per-connector setup guides are not on the website. Every receipt above comes from partner docs (Datadog, Axonius, Microsoft Sentinel content hub), Obsidian's public GitHub Codex plugin, or Obsidian marketing pages. A public Splunk, Cortex XSOAR, Tines or Torq connector with auth details was not found; web search was unavailable during this check, so those were looked for only through GitHub code search. Both grades are conservative and would move with public docs: inbound off F with settable-and-enforced expiry, a token API, a last-used column or GitHub partnership; outbound to B with any published admin-consent or app-install connector setup.

Badge

wif.tax grade F

[![wif.tax grade](https://wif.tax/badge/obsidian-security.svg)](https://wif.tax/p/obsidian-security/)