wif.tax

Zenity

C AI Agent Security platform

Zenity's API is reached with an account API key (client ID plus client secret) exchanged through an Auth0 client-credentials grant for a short-lived bearer token; there is no federation. Its docs are behind a customer login, so key hygiene is mostly unverifiable, and the public connector pages show an IAM role for AWS Bedrock but customer-generated API keys for ChatGPT Enterprise and Claude Enterprise.

Docs: docs.zenity.io · Checked 2026-10-13 · source YAML · dispute via PR

Inbound C

How a workload running anywhere authenticates to this product.

An account API key (client ID + client secret) is exchanged through an Auth0 client_credentials grant for a short-lived bearer token scoped to the account's organization; the client secret is the long-lived root.

docs.zenity.io (including the API and integration docs) redirects to a customer login, so the API's auth is graded from Zenity's own public artifacts: the boundaries-as-code template repo on GitHub and the README.md bundled inside the signed zenityctl 0.1.0 release archive on get.zenity.io (the two zenityctl quotes come from that README; the archive is public, the README is not served as a standalone page). Zenity's own GitHub Actions deploy workflow stores the client secret as a repository secret and requests only `contents: read`, with no `id-token` permission, so there is no sign of GitHub OIDC or any other federation. The zenityctl README describes "Account API key (`client_credentials`)" as "the only mode"; the public API is labelled `v1-beta`. Deployable components: the Cursor inventory plugin enrolls with a pasted enrollment key that is exchanged for a short-lived device token (https://raw.githubusercontent.com/zenitysec/zenity-cursor-plugin/HEAD/zenity-inventory/README.md: "the enrollment key is exchanged for a short-lived device token"), so endpoint agents also rest on a static root. If the gated docs show a federated or keyless path, this grade should be revisited.

Outbound B

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

AWS Bedrock is connected with IAM roles; ChatGPT Enterprise and Claude Enterprise are connected by pasting an API key the customer generates on the OpenAI or Anthropic platform.

Graded from marketing pages only; the connector setup guides are in the gated customer portal ("Zenity customers can view step-by-step documentation in the customer portal"). Checked: AWS Bedrock (IAM roles, keyless per the vendor's wording; the page does not say whether this is a cross-account role with an external ID); ChatGPT Enterprise and Claude Enterprise (customer-generated Compliance API keys, static); Slack / Claude Tag ("Connect your Slack workspace", mechanism not stated, plausibly an app install). Microsoft Copilot Studio, Microsoft 365 Copilot, Microsoft Foundry, Agent 365, Salesforce/Agentforce, ServiceNow, Google Vertex AI and Cursor are all marketed as integrations, but no public page says how Zenity authenticates to them, so they could not be classified. B rests on the single AWS IAM-role statement plus two documented static-key connectors; if the AWS role turns out to need access keys, this drops to D or F.

Hygiene for any static credential the product still issues

✗ Expiry enforceable
No public statement that account API keys can be given an expiry or that an org policy can enforce one. Docs are gated, so this is unverified rather than confirmed absent. The short-lived bearer token expires; the client secret that mints it is what this check is about.
  • raw.githubusercontent.com checked 2026-10-13
    “Repository **secrets**: `ZENITY_CLIENT_ID`, `ZENITY_CLIENT_SECRET` — an account API key.”
✗ Rotation via API
No public API or CLI command for creating or revoking account API keys; zenityctl only manages boundaries, taints and variables. The zenityctl binary's help text says keys are created in the console (Settings, API keys). Unverified against the gated API docs.
  • get.zenity.io checked 2026-10-13
    “There is no `login`, no `logout`, and no credential storage”
✓ Scoped keys
Account API keys are an organization-scoped machine principal carrying a role (`viewer` or `operator`), so a CI key can be held read-only. How many roles exist, and whether a key can be limited further, is in the gated docs.
  • get.zenity.io checked 2026-10-13
    “**`push` requires `operator`; every other `boundaries` command needs `viewer`.**”
  • raw.githubusercontent.com checked 2026-10-13
    “Both commands need the same credentials as `diff`, and only the `viewer` role.”
✗ Last-used visible
No public evidence that Zenity shows when an account API key was last used. Unverified against the gated docs.
✗ Leak revocation
Zenity does not appear anywhere in GitHub's supported secret-scanning patterns, partner or user.

Notes

Zenity's documentation (docs.zenity.io) is entirely behind a customer login, so this card is built from Zenity's public GitHub repos (zenitysec/boundaries-as-code-template, zenitysec/zenity-cursor-plugin), the public zenityctl release archive on get.zenity.io, and marketing pages on zenity.io. The C rests on zenityctl's documented Auth0 client_credentials flow; the three failed hygiene checks are failures of public evidence, not confirmed gaps, and matter less at C than they would at D/F. Grade would move to A/B only if Zenity accepts federated tokens (for example GitHub Actions OIDC, which its own deploy template does not use).

Badge

wif.tax grade C

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