Changelog

Luna now lives as a chat bubble inside the dashboard, available from any page. Open it on a resource, identity, app, or access review and Luna already knows what you're looking at — no need to paste IDs or re-state context. Ask "who owns this?", "summarise the last 30 days of activity", or "find anyone with similar access" and Luna will answer against the entity in view.

You can drag-and-drop files directly into the composer too: screenshots, CSV exports, IdP reports, anything you'd previously have to describe. When Luna queues actions that need your sign-off, you can now bulk approve or deny them by tool type rather than clicking through each one.

Click the Luna icon on any page to try it.

Guardrails are admin-authored rules that let Luna take action without a human-in-the-loop when conditions match, a more surgical alternative to broad "auto-approve" toggles. Every Luna tool now has four states: Allowed, Denied, Ask, and the new Guarded state, which only runs when your rule evaluates true.

Rules can reference attributes on the entity Luna is acting on, for example, "auto-approve membership additions to low-risk groups, but always ask for production resources." Permissions inherit from parent agents and playbook configs, with overrides shown explicitly on each tool so you always know which rule fired.

Configure under Settings → Luna → Guardrails.

You can now control exactly who signs off on an access review, what they're agreeing to, and how granular that sign-off is. Choose between three modes: let each reviewer self-attest their own work, require a separately designated person to countersign each account set, or have one person certify the entire review once every set is in. Set an org-wide default, then override it per campaign or per cycle so routine reviews stay light while quarterly compliance certifications can be stricter. Once a cycle starts, its settings are locked, so later changes to your defaults never affect a review already in flight.

You can also tailor the statements each signer must confirm: edit the wording, add or remove statements, reorder them, and mark each as required or optional. Statements can include real values like the cycle name and resource name, captured at the moment the sign-off is recorded so the historical record shows exactly what was agreed.

Ploy now detects dynamic-membership groups from your IdPs, the ones whose membership is computed from a rule rather than maintained by hand, and labels them throughout the UI. The membership rule is shown alongside the group, so you can see exactly why a user is included.

Luna can also see these rules and help you make changes/suggestions to better suit how your organisation manages their identities.

Ploy now surfaces recommended source of truth configurations in a review queue, so you can set up cascade access relationships in bulk instead of configuring each app one at a time. When Ploy notices a group, license, or role granting access to an app that has no source of truth yet, or a connected integration whose domain matches an app, it adds a suggestion to the queue with sensible defaults already filled in.

For each suggestion you see the target app, its existing sources, and the recommended source, along with a short explanation of why those defaults were chosen. For group, license, and role suggestions you can adjust the defaults before applying: whether the source is the authoritative identity, whether its identities take priority, whether removing someone there revokes their app access, and whether only active members count. Then choose to apply it alongside your existing sources, apply it and replace what's there (with a confirmation step, since that one is destructive), or dismiss it.

Once you apply or dismiss a suggestion, Ploy won't surface that same pairing again. New pairings show up within a minute or two. To get started, open the new Source of Truth Suggestions tab on the Resources page, where a badge shows how many are waiting for review.

Access request policies can now specify time windows users are able to make requests within, such as “only between 9-5”. Combined with conditions, you’re now able to craft complex logic around access policy approvals.

Ploy now has a public API allowing you to manage everything from user access to resource access policies programatically, including via IaC tools.

Ploy now scans Anthropic and OpenAI for API keys, service accounts, and other non-human credentials, and surfaces them in your NHI inventory. Each key shows up alongside the workspace or team it belongs to, when it was created, when it was last used, and what scopes it carries.

This is a starting point for governing shadow AI usage - every API key your team has created sitting in .env files, terminal history, and contractors' laptops - without having to chase down individual developers. Combined with the rest of the NHI feature set, you can review and attest AI credentials the same way you handle any other access grant.

To get started, integrate with either of the applications and then visit the non human identities page in your dashboard to see them.