Skip to main content

Granular API key permissions for password and OTP visibility

APISecurity & credentials

API keys currently only offer a single "view passwords" permission, which also grants access to OTPs. There's no way to grant access to one without the other.

Request

Split this into two separate permissions on API keys:

View passwords – grants access to stored passwords only

View OTPs – grants access to OTP codes only

This lets admins scope API keys more tightly, for example, issuing a key that can pull passwords for an integration without also exposing OTPS.

1 comment

Log in to comment and vote

Comments1

  • Aqua Iguana

    •

    Sep 24

    •

    Merged request

    More API Control - especially passwords & OTP Secrets

    Right now, the asset_passwords endpoint returns OTP secrets bundled together with password data. Any integration that needs password data — like a password rotation/PAM platform (e.g., CyberQP) — ends up pulling OTP secrets too, even though it has no legitimate use for them.

    Ask: Remove OTP secrets from the standard asset_passwords response, and expose them only through a separate field or endpoint that requires its own distinct API permission/scope.

    Why this matters: This lets us scope third-party integrations to exactly the data they need. A password rotation platform needs passwords, not OTP secrets — bundling the two together means every integration we authorize inherits access to OTP data by default, regardless of whether it needs it. Separating them follows basic least-privilege/need-to-know practice and shrinks the blast radius if any single integration is ever compromised.

    Bonus: Be able to scope a key to only allow specific clients. Right now, you can do that, but that "client" field is limited to only a specific client.