Panther Labs
D Panther SIEM
Panther's REST and GraphQL APIs, PAT and the Terraform provider take only a static X-API-Key token; no OIDC or workload identity path exists. Tokens are permission-scoped, API-rotatable and show last use, but do not expire and are not GitHub partner-revoked. Into your cloud it is keyless on AWS (IAM role) and GCP (Workload Identity Federation), while Azure sources and most SaaS pullers want client secrets, connection strings or API tokens.
Docs: docs.panther.com · Checked 2026-10-22 · source YAML · dispute via PR
Inbound D
How a workload running anywhere authenticates to this product.
Static Panther API token sent as the X-API-Key header, created in the Console or through the API with an explicit permission list and optional CIDR allowlist. It is the only credential the REST API, GraphQL API, Panther Analysis Tool (PAT) and Terraform provider accept; HTTP log sources take a static shared secret, HMAC key, bearer token or basic auth.
- docs.panther.com checked 2026-10-22
“API tokens are used to authenticate against and authorize access to Panther’s public API.”
- docs.panther.com checked 2026-10-22
“"securitySchemes":{"ApiKeyAuth":{"type":"apiKey","name":"X-API-Key","in":"header"}}”
- docs.panther.com checked 2026-10-22
“curl -H "X-API-Key: <API_KEY>" -d <INTROSPECTION_QUERY> <YOUR_PANTHER_API_URL>”
- docs.panther.com checked 2026-10-22
“Most PAT commands require authentication against your Panther instance using an API token.”
- docs.panther.com checked 2026-10-22
“token = var.panther_api_token”
- docs.panther.com checked 2026-10-22
“With bearer authentication, you define a bearer token value during source setup.”
Every documented automation path (REST, GraphQL, PAT in CI/CD, Terraform log-source management) authenticates with the same static API token; the OpenAPI spec declares only the ApiKeyAuth header scheme. No OIDC, GitHub Actions, cloud workload identity or token exchange is documented for inbound calls, and the PAT CI/CD guidance is to store the token as a CI secret. SAML SSO and SCIM are for humans. The Workload Identity Federation Panther documents is outbound (Panther authenticating to your GCP), not your workload authenticating to Panther. HTTP ingestion sources are likewise static shared secrets (shared secret, HMAC, bearer, basic) or no auth. Three of five hygiene checks pass, so D rather than F.
Outbound B
How this product reaches into your cloud, repos, or other SaaS.
AWS log sources (S3, CloudWatch, SQS) and Cloud Security Scanning assume an IAM role you create that trusts your Panther instance's AWS account; GCS and Pub/Sub sources, the Pub/Sub alert destination and Google Workspace logs can use Google Workload Identity Federation from Panther's AWS identity. Azure Blob Storage wants an Entra app client secret, Event Hub a SAS connection string, and SaaS pullers (Okta, Microsoft Graph, GitHub, Wiz and others) API tokens, PATs or OAuth client secrets.
- docs.panther.com checked 2026-10-22
“To read objects from your source, Panther needs an AWS IAM role with certain permissions.”
- docs.panther.com checked 2026-10-22
“"arn:<aws-partition>:iam::<panther-master-account-id>:root"”
- docs.panther.com checked 2026-10-22
“The CloudFormation stack will create an AWS IAM role with the minimum required permissions to read objects from your source.”
- docs.panther.com checked 2026-10-22
“This works by using an assumable IAM Role with ReadOnly permissions.”
- docs.panther.com checked 2026-10-22
“You may use [Common Expression Language (CEL) expressions](https://cloud.google.com/iam/docs/workload-identity-federation#mapping) to transform or combine attributes from the token issued by AWS.”
- docs.panther.com checked 2026-10-22
“Configure Workload Identity Federation with AWS by following the”
- docs.panther.com checked 2026-10-22
“for the service account, which will be used in Panther to authenticate to the GCP infrastructure.”
- docs.panther.com checked 2026-10-22
“Configure Workload Identity Federation with AWS by following the”
- docs.panther.com checked 2026-10-22
“The client secret value will be redacted in your terminal.”
- docs.panther.com checked 2026-10-22
“Copy the **Primary connection string** value and store it in a secure location”
- docs.panther.com checked 2026-10-22
“In order for Panther to access the API you need to create a new API token or use an existing one.”
- docs.panther.com checked 2026-10-22
“The Client Secret is hidden after you navigate away from this page”
- docs.panther.com checked 2026-10-22
“Generate a Personal Access Token** in GitHub and provide credentials to Panther”
- docs.panther.com checked 2026-10-22
“and store it in a secure location, as you will need it in a following step.”
Checked: AWS S3, CloudWatch Logs and SQS transports and Cloud Security Scanning (IAM role, keyless); GCS and Pub/Sub transports, the Pub/Sub alert destination and Google Workspace logs (Workload Identity Federation with Panther's AWS identity as the external issuer, keyless; a service-account JSON key file is the documented alternative); Azure Blob Storage (Entra app tenant ID, client ID and client secret) and Event Hub (shared access policy with Listen, primary connection string), with no federated-credential option documented; SaaS pullers Okta (SSWS API token), Microsoft Graph (client ID and secret), GitHub (OAuth App client secret or PAT) and Wiz (service account client secret, scoped to projects). The AWS trust policy names the root of the AWS account your Panther instance runs in, with an aws:SecureTransport condition but no sts:ExternalId; since that account is your instance's own (SaaS deployments) or yours (Cloud Connected), the confused-deputy risk is lower than with a shared vendor account, but an External ID or a named Panther role would be tighter. B because AWS and GCP are keyless while Azure has no keyless path; an Azure federated credential would lift outbound to A for the clouds, with SaaS pullers bound by what each SaaS offers.
Hygiene for any static credential the product still issues
| ✗ Expiry enforceable | The token schema has an expiresAt field that may be null, but neither the create nor the update payload accepts an expiration, and no organization policy for a maximum lifetime is documented. Panther recommends rotating every 90 days, which is advice, not enforcement (same call as elastic-cloud-api).
|
| ✓ Rotation via API | REST has POST /api-tokens, DELETE /api-tokens/{id} and POST /api-tokens/{id}/rotate (or /self/rotate, so a token can rotate itself); GraphQL has rotateAPIToken. Rotation invalidates the previous value immediately.
|
| ✓ Scoped keys | Tokens are standalone principals, not tied to a user's role: each is created with its own permission list (LogSourceModify, RuleRead, AlertModify and so on) and an optional CIDR allowlist. Caveat: the data-lake RBAC feature does not apply to tokens, so any token with query permissions sees all log data and Saved Searches.
|
| ✓ Last-used visible | The APIToken resource returned by GET /api-tokens carries a lastUsedAt timestamp.
|
| ✗ Leak revocation | Panther does not appear in GitHub's supported secret-scanning patterns table at all, so a leaked Panther API token is neither detected nor reported to Panther.
|
Notes
One card for Panther, covering both SaaS and Cloud Connected deployments (same API and token model). Three of five hygiene checks pass; an enforceable token expiry and GitHub partner revocation would make five. Inbound moves to B or A only if the Panther API accepts a federated token (GitHub Actions OIDC, cloud workload identity or a bring-your-own issuer), which would also let PAT in CI drop its stored token. Outbound moves to A with a keyless Azure option.
Badge
[](https://wif.tax/p/panther-siem/)