TL;DR: At /dev/mtl 2025, speakers focused on how legacy systems, feature-flag complexity, database tracing, and secrets security all reward guardrails, feedback loops, and deliberate lifecycle discipline, according to GitGuardian's event recap. The security lesson is that operational complexity becomes governance risk when teams cannot observe, retire, or constrain access patterns with confidence.
At a glance
What this is: This recap of /dev/mtl 2025 links developer tooling, testing, and observability lessons to the security discipline of secrets and NHI governance.
Why it matters: IAM and NHI practitioners should treat release complexity, legacy behaviour, and plaintext credentials as related control problems, not separate engineering concerns.
👉 Read GitGuardian's recap of /dev/mtl 2025 and the developer lessons behind it
Context
Legacy software and release complexity often create the same governance problem seen in NHI environments: systems accumulate states, access paths, and exceptions faster than teams can reason about them. When feature flags, test environments, and service credentials multiply, the real risk is not just operational friction but loss of control over who or what can do what at runtime.
The /dev/mtl 2025 recap is useful because it shows developers arriving at the same conclusion security teams reach in NHI work. Guardrails, lifecycle discipline, and observability are more reliable than heroic cleanup after the fact. That starting point is typical for modern engineering teams, and it is exactly why NHI governance needs to be built into day-to-day development habits.
Key questions
Q: How should teams govern temporary access controls in legacy systems?
A: Treat temporary controls as time-bounded assets with owners, expiry dates, and removal criteria. If a flag, token, or service credential can stay active indefinitely, it is not temporary in practice. Governance should require rotation, revocation, and review to be part of the normal delivery workflow, not an afterthought when incidents happen.
Q: Why do observability and NHI governance belong together?
A: Because you cannot govern access you cannot see. Observability shows how identities, tokens, and service calls behave in production, which reveals hidden fan-out, stale privileges, and unintended dependencies. Without that evidence, access reviews become speculative and teams miss where the real control failures are happening.
Q: What is the difference between a temporary control and standing privilege?
A: A temporary control has a documented end state, while standing privilege persists beyond the task that justified it. In practice, many short-lived exceptions become standing access because nobody enforces expiry. Good governance makes removal automatic or at least mandatory before the control is considered complete.
Q: When should security teams retire a feature flag or service credential?
A: Retire it as soon as the release, experiment, or automation no longer needs it. The risk is not only exposure but state drift, because old controls create extra paths that complicate testing, auditing, and incident response. Lifecycle discipline matters more than retaining flexibility forever.
Technical breakdown
Why feature-flag state explosion breaks deterministic testing
Feature flags create a combinatorial state problem. Each flag adds a new branch to the test matrix, and percentage rollouts make the same code path behave differently across users and time. That means end-to-end tests stop being a pure validation of application logic and become a mixed test of configuration, caching, identity targeting, and environment drift. The architectural issue is not the flag itself, but the hidden dependency between release logic and runtime state. In NHI terms, this is the same pattern that appears when access decisions depend on mutable context the team cannot fully enumerate.
Practical implication: Treat flags as temporary control points and retire them on a defined schedule so test scope stays bounded.
How tracing exposes hidden performance and access paths
Tracing shows how one request fans out into many downstream operations, which is often the only way to understand why systems feel slow or unpredictable. In modern application stacks, the visible action is rarely the full action. Lazy loading, ORM behaviour, backend calls, and middleware can multiply work in ways that logs alone do not reveal. For security practitioners, the same logic applies to NHI flows: a single identity action may trigger multiple token exchanges, API calls, or policy checks that are invisible without runtime telemetry. The governance problem is that hidden paths tend to hide hidden privilege.
Practical implication: Use tracing to map where identities, secrets, and service calls actually propagate before tightening controls.
Why secrets governance needs lifecycle discipline, not cleanup
Secrets security fails when teams treat credentials as static assets instead of living artifacts with an expiry, an owner, and a retirement path. Plaintext credentials, unmanaged rotation, and ad hoc exceptions all create durable exposure because the control model assumes someone will remember to clean up later. That assumption breaks under release pressure and legacy constraints. The architectural lesson mirrors NHI governance more broadly: access that is easy to create must also be easy to expire, revoke, and audit. Otherwise, standing exposure becomes the default state.
Practical implication: Build rotation, revocation, and ownership into the delivery workflow so credential hygiene is enforced by process.
Breaches seen in the wild
- Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
- MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Legacy complexity is now an identity governance problem, not just an engineering inconvenience. When systems accumulate flags, service accounts, and environment-specific exceptions, access paths become harder to explain and harder to verify. That makes the NHI control surface expand faster than many teams realise. Practitioners should treat legacy control drift as an access governance issue, not a cleanup backlog.
Feature-flag sprawl is a useful proxy for ephemeral trust debt. Temporary controls tend to survive longer than intended, and once they do, they behave like standing privilege in practice. The point is not to ban feature flags. The point is to assign them an owner, a retirement date, and a test plan that reflects how access and behaviour actually change over time. Practitioners should make flag lifecycle reviews part of release governance.
Observable systems are governable systems. The event’s strongest throughline was that teams trust what they can inspect in production, not what they assume from design docs. For NHI and secrets management, that means tracing credential usage, rotation outcomes, and service-to-service paths rather than relying on policy statements alone. Practitioners should prioritize telemetry that proves control effectiveness.
Guardrails beat heroics in both development and identity control. The recap points to a discipline that security teams should recognise immediately: safe defaults, explicit lifecycles, and constrained exceptions scale better than manual judgment. In NHI governance, this is the difference between hoping operators remember the rule and engineering the rule into the workflow. Practitioners should design controls that make the safe path the easiest path.
Secrets governance and agentic access will converge around lifecycle management. As software systems become more autonomous and more connected, the burden shifts from granting access to continuously proving that access still belongs. That makes lifecycle management the central control plane for future NHI programmes. Practitioners should prepare for more automated provisioning, but also for stricter revocation and review expectations.
From our research:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
- The average estimated time to remediate a leaked secret is 27 days, which means temporary exposure often outlives the release cycle that created it.
- For the broader identity lifecycle context, see Ultimate Guide to NHIs - 2025 Outlook and Predictions for how NHI growth changes governance priorities.
What this signals
Ephemeral controls do not eliminate governance debt. When teams create temporary flags, test credentials, or release-specific service accounts, they still inherit ownership, revocation, and audit obligations. That is why the operational question is not whether temporary controls are useful, but whether the organisation can prove when they end.
With 6 distinct secrets manager instances on average, fragmentation itself becomes a control failure because no team can see the full credential estate. The practical response is to reduce the number of independent paths that secrets and service identities can take before governance breaks down.
The next maturity step is not more policy language, but tighter lifecycle enforcement. As NHI programmes expand into software delivery and AI-assisted operations, teams should expect stronger demands for expiry, traceability, and revocation evidence across all non-human access paths.
For practitioners
- Map flag and credential lifecycles together Inventory temporary feature flags, service accounts, tokens, and test credentials in the same lifecycle register so owners can see which controls are still active and which should be retired.
- Use tracing to expose identity-driven fan-out Instrument the paths where a single request triggers downstream calls, token exchanges, or policy checks so you can spot hidden privilege and unexpected dependency chains.
- Assign expiry dates to temporary controls Require a named owner and removal date for every temporary access path, including release flags, emergency permissions, and short-lived service credentials.
- Automate rotation and revocation checks Build verification into delivery pipelines so expired secrets, stale tokens, and dormant service accounts are detected before they become standing exposure.
Key takeaways
- Legacy systems, feature flags, and secrets sprawl create the same core risk: controls that outlive the context that justified them.
- Observable runtime behaviour is the difference between access you can explain and access you only hope is safe.
- Security teams should treat lifecycle discipline as the operating model for NHI governance, not as a cleanup activity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Temporary credentials and flags need lifecycle control to avoid standing exposure. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access review map directly to these lifecycle and revocation themes. |
| NIST Zero Trust (SP 800-207) | Continuous verification fits the need to inspect runtime behaviour before trusting access. |
Review non-human access entitlements against PR.AC-4 and remove stale permissions on schedule.
Key terms
- Feature Flag Lifecycle: The full lifecycle of a feature flag covers creation, targeting, testing, rollout, and retirement. In practice, flags become a governance issue when they remain active after the feature has stabilised, because they keep behaviour and access paths mutable long after the original change window has closed.
- Secrets Fragmentation: Secrets fragmentation occurs when credentials are spread across multiple tools, environments, or ownership boundaries. It weakens central control because no single team can reliably see every secret, enforce consistent rotation, or prove that all exposures have been removed.
- Identity Fan-out: Identity fan-out is the expansion of a single request or authentication event into multiple downstream actions, tokens, or service calls. It matters because hidden fan-out can multiply privilege, obscure dependency chains, and make access behaviour harder to audit in production.
- Ephemeral Trust Debt: Ephemeral trust debt is the accumulation of temporary access, exceptions, and short-lived controls that outlive their intended use. It describes how non-human access can become effectively standing privilege when expiry, ownership, and revocation are not enforced consistently.
What's in the full article
GitGuardian's full article covers the operational detail this post intentionally leaves for the source:
- Speaker-by-speaker highlights from the three-track /dev/mtl agenda, including the testing, performance, and security sessions.
- The developer discussion around plaintext credentials and how practitioners reacted to the secrets security session.
- Additional context on the cross-community setting, including the local groups that helped organise the event.
- The broader event framing that connects developer habits to security guardrails and production discipline.
Deepen your knowledge
NHI lifecycle discipline, runtime observability, and secrets governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is working through the same legacy and access constraints discussed here, it is worth exploring.
Published by the NHIMG editorial team on 2025-12-03.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org