Introducing Permissions & Audit
Zenmanage now ships scoped access controls and an immutable audit trail, included in the plan — so your team has the right permissions for every environment and a complete record of every change.
Two risks tend to converge quietly in production environments. The first is over-privileged access: developers with account-wide write access who can change environment variables in production when their work only touches a staging flag. There is no practical barrier between a test change and a live customer impact. The second is weak change attribution: when something goes wrong, the audit trail is either absent or too coarse to answer the questions that matter — who changed what, in which environment, and exactly when.
Today, Zenmanage addresses both with Permissions & Audit.
Scoped permissions
Access is now granted at the account, project, or individual environment level. A developer working on a feature flag in a staging project does not automatically inherit write access to production. Production-sensitive operations — enabling flags, changing rollout percentages, modifying environment variables — can be restricted to named roles. Delegation is explicit, minimal, and reversible.
This is not a flat all-or-nothing permission bit. The granularity follows the shape of how teams actually work — by project and by environment. A team can give a developer full write access to staging and read-only access to production, and the boundary is enforced at the point of change, not via a policy document nobody reads.
Production-sensitive controls
Some operations carry more risk than others. Enabling a flag in production, adjusting a rollout percentage, writing an environment variable — these actions have immediate, customer-facing consequences. Permissions & Audit lets you restrict those specific operations to a defined set of roles so the people who should be making production changes are the ones making production changes.
Production protection is not a manual review gate that adds latency to every release. It is a targeted control around the specific operations that carry real customer risk. Developers who do not need production access keep moving at full speed.
Immutable audit history
Every flag evaluation change, configuration write, and permission modification is captured with actor identity, timestamp, and environment context. The record cannot be altered retroactively. Every change is attributable.
When something goes wrong in production, the answer is already there. No log reconstruction, no asking around in Slack, no gap in attribution. Engineering leads can reconstruct a release timeline during incident review without relying on memory or chat history. And when a customer or procurement asks who has access to what, and can you prove it, you already have the answer — no spreadsheet, no manual log parsing.
What this means in practice
Teams reduce blast radius from misconfigured or prematurely enabled changes because access is scoped rather than blanket. When a flag gets enabled in production unexpectedly, the audit log tells you immediately who did it and from which context. When a rollout percentage changes during an incident window, the timeline is already captured.
None of this needs a separate tool or a manual audit process bolted on afterward. It's built into the same system where your flags live — and it's included in the plan, not a sales call away.
What's next
Permissions & Audit is available to all Zenmanage customers today. The capability page has the full feature breakdown including scope levels, production-sensitive controls, and audit log detail. If you want help setting this up for your team, start with the trial or just email us — no sales call required.
This is the first of several permissions and audit features shipping this quarter. More soon.