Introducing Permissions & Audit
Zenmanage now ships scoped access controls and immutable audit history as a unified release-governance layer — so your team has the right permissions for every environment and a complete record of every change.
Most teams shipping features in production operate with more access than they need and less visibility than they should have. Permissions & Audit ships scoped authorization and attributable change history as a unified release-governance layer — without adding friction to every release.
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. Compliance and governance reviewers can confirm who approved, who changed, and when — without bespoke tooling or 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.
This is release governance that does not require a separate tool or a manual audit process. It is built into the same system where your flags live.
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 to work through setting this up for your team, start with the trial or reach out to book a demo.
This is the first of several governance features shipping this quarter. More soon.