Material Security

F Material platform (API v1)

Material's API accepts only a static per-account token in an x-material-client-secret header, with no documented expiry, last-used timestamp, token API or leak revocation. Material reaches Google Workspace through domain-wide delegation to its own app, but Okta, Duo, OneLogin, Slack and SIEM connectors all want a pasted token or secret.

Docs: docs.material.security · Checked 2026-10-13 · source YAML · dispute via PR

Inbound F

How a workload running anywhere authenticates to this product.

Static API token created in the Material console, tied to one Material account and sent in the x-material-client-secret header; it carries that account's current role permissions.

docs.material.security checked 2026-10-13
“Each API token is tied to a specific account. You can create as many tokens as needed.”
docs.material.security checked 2026-10-13
“Requests are checked against the account's current permissions, not the permissions it had when the token was created.”
docs.material.security checked 2026-10-13
“For production use, we recommend creating a new service account to generate the API token. Once the token is created, you can reset and discard the account's login details.”
docs.material.security checked 2026-10-13
“OAuth is the recommended way to connect: each person authorizes with their own Material account, and token issuing and refresh are handled for you, so there's no long-lived secret to store or rotate.”
docs.material.security checked 2026-10-13
“Use an API token when your AI client doesn't support OAuth, or when you'd rather manage a long-lived token yourself.”

No OIDC federation, workload identity, or client-credentials flow is documented for the REST API. The Material MCP server supports OAuth, but that is an interactive per-person authorization for AI clients, not a machine flow, and the MCP fallback is the same static API token. The beta API predates v1 and is documented only in-app; it was not assessed. Material is agent-free (no on-prem collectors). Public docs (docs.material.security) are not gated.

Outbound B

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

Google Workspace is connected by granting scopes to Material via domain-wide delegation and Microsoft 365 by an in-app enrollment run by a Global Administrator; Okta, Duo, OneLogin, Slack, PagerDuty and SIEM/SOAR/webhook destinations take customer-created static tokens.

docs.material.security checked 2026-10-13
“File Search requires (2) additional Google Drive scopes to be granted to Material via domain-wide delegation:”
docs.material.security checked 2026-10-13
“When the scope is missing, your Material instance displays a warning prompting you to grant it. Click the button in the prompt to navigate to Google where you can grant it, then give Google time to apply the change:”
docs.material.security checked 2026-10-13
“In some cases it can take up to 30 minutes for your email tenant to reflect the changes and give Material access.”
docs.material.security checked 2026-10-13
“Copy your API token because you will only see it one time. Paste it into Material.”
docs.material.security checked 2026-10-13
“Token: The token you created in step 4.”
docs.material.security checked 2026-10-13
“On the Install App page, there should now be a Bot User OAuth Token. Paste this value in Material.”
docs.material.security checked 2026-10-13
“Copy the API key and API URL — you'll need both in Part Two.”
material.security checked 2026-10-13
“Your team has full access to and ownership of the underlying infrastructure. Material only has access to deploy updates.”

Connectors checked: Google Workspace (keyless: domain-wide delegation to Material, per-scope grants in Google Admin); Microsoft 365 (enrollment is an in-app flow run by a Global Administrator with the steps shown only in the product, so the mechanism, presumably admin consent to Material's multi-tenant app, is not publicly documented; no client secret is mentioned); Okta Token and Okta SSF (static Okta SSWS API token from a dedicated Okta admin, with least-privilege admin roles listed); Duo Auth API (integration key + secret key); OneLogin (API client ID + client secret); Slack (the customer creates its own Slack app from Material's manifest and pastes the long-lived Bot User OAuth Token); PagerDuty (integration key); SIEM/SOAR/custom webhooks incl. Panther and CrowdStrike NG-SIEM (customer-supplied bearer/API keys in request headers). SAML identity integrations exchange only metadata. No AWS, GCP or Azure cloud connectors are documented. The single-tenant "Semi-managed" and "Customer Managed" deployments into customer cloud are described only on marketing pages; how Material authenticates into that infrastructure to deploy updates is not public.

Hygiene for any static credential the product still issues

✗ Expiry enforceable	Token creation takes only a name; no expiry field or org-level expiry policy is documented. Admins can only toggle API token creation off entirely. docs.material.security checked 2026-10-13 “Name the token descriptively, then click Create Token. It's useful to include a use case if you have many tokens stored.” docs.material.security checked 2026-10-13 “This path uses an API token instead of OAuth, so storing and rotating it is on you.”
✗ Rotation via API	Tokens are created and modified in the console (Integrations > API and MCP > Tokens and MCP Connections). The API v1 OpenAPI spec has no token endpoints, so rotation cannot be automated without a browser. docs.material.security checked 2026-10-13 “The Material Security API v1 includes these resources: Issues, Messages, Accounts, Groups, Roles, OAuth Apps, and Trusted Entities.”
✓ Scoped keys	Tokens have no scopes of their own; they inherit the roles of the account that owns them. Passed because Material documents a dedicated service account as the production pattern and that account can be given a narrow built-in role (e.g. Analyst) limited to one tenant. A token on a human admin's account carries all of that admin's permissions. docs.material.security checked 2026-10-13 “For production use, create a dedicated service account for generating API tokens” docs.material.security checked 2026-10-13 “Global role permissions apply to all tenants. Tenant role permissions apply only to the tenant the user is assigned the role in.”
✗ Last-used visible	The token list links to a per-token Audit Log filter, but no last-used timestamp on the token is documented. Finding dead tokens means querying the audit log per token. docs.material.security checked 2026-10-13 “The Audit Log opens, pre-filtered to this token's events within the last week. Update the filter as needed.”
✗ Leak revocation	Material Security does not appear in GitHub's secret scanning partner list. docs.github.com checked 2026-10-13

Notes

Graded the Material platform's API v1 (Email Security, Account Security, Google Drive Security and OAuth Security all share it). Material sells single-tenant deployment options (fully managed, semi-managed, customer managed in the customer's own cloud); auth for those deployments is not publicly documented. Inbound improves if Material adds token expiry, a last-used field and token management endpoints (D), or any federated machine flow (B or better). Outbound would reach A only if Okta and Slack moved to vendor-owned apps (Okta OIN service app, Material-owned Slack app).

Badge

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