Controller-specific config creep

The accumulation of non-portable behaviour in annotations, snippets, and custom controller features. It matters because the effective policy no longer lives in the portable spec, which makes migration, review, and audit harder when the environment changes.

Expanded Definition

Controller-specific config creep describes the gradual shift from portable, declarative policy into behaviour that depends on a particular orchestration controller, admission path, or custom extension. In practice, the workload no longer behaves the same way if moved to another cluster, vendor, or runtime.

This is closely related to configuration drift, but it is more specific: the dependency is baked into controller annotations, sidecar injection rules, CRDs, templates, or operator logic. That means the effective control plane policy is split between the intended spec and hidden controller behaviour. Definitions vary across vendors because some teams treat these additions as harmless implementation details, while others classify them as policy debt. In NHI and agentic systems, the risk is especially high when identity binding, secret injection, or token minting depends on a controller feature rather than a portable standard such as Kubernetes-native workload identity patterns or NIST Cybersecurity Framework 2.0 aligned governance.

The most common misapplication is assuming a manifest remains portable because it still validates, when in reality the live policy only works because a specific controller is present and configured a certain way.

Examples and Use Cases

Implementing portability rigorously often introduces some short-term friction, requiring organisations to weigh deployment convenience against long-term migration and audit costs.

• A platform team uses controller annotations to auto-inject workload tokens, but the identity path breaks when the application is moved to a cluster that lacks the same operator.
• A secrets workflow depends on a custom admission controller to rewrite mounts and environment variables, making the deployment non-portable and harder to review against the Ultimate Guide to NHIs — Standards guidance.
• An internal AI agent service relies on controller-specific hooks to receive tool credentials, so the policy cannot be cleanly reproduced in a different environment without manual rework.
• A compliance review finds that the manifest appears least-privileged, but the controller adds hidden side effects that expand runtime access beyond the documented spec.
• An engineering team uses custom CRDs for fine-grained rollout control, yet the behaviour is not represented in baseline policy checks or external review tooling.

In each case, the portability problem is not the YAML itself. The real issue is that the operational meaning lives inside controller logic that only one environment fully understands, which is why NHI governance teams increasingly compare live behaviour against source-of-truth policy and external standards such as NIST Cybersecurity Framework 2.0.

Why It Matters in NHI Security

Controller-specific config creep matters because NHI control failures often begin as invisible implementation shortcuts. A service account, API key, or workload token may look properly governed in code review while the real access path is produced by controller behaviour that only exists in one cluster. That creates audit gaps, complicates zero trust enforcement, and makes incident response slower when identities must be rotated or reissued under pressure.

NHI Mgmt Group data shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and 73% of vaults are misconfigured, which means hidden controller logic can easily amplify an already fragile secret posture. The same pattern undermines portability during migration, because the new environment may not recreate the same identity injection, rotation, or policy enforcement behaviour. For a broader governance view, the Ultimate Guide to NHIs — Standards is useful for comparing operational controls against portable identity expectations.

Organisations typically encounter this consequence only after a failed migration, a broken secret injection path, or an audit finding exposes that the controller, not the declared policy, was enforcing access all along.

Related resources from NHI Mgmt Group

• Privilege Creep
• Why are local .env files and config notes risky in Microsoft 365?
• Should organisations use new AI-specific identity standards or existing ones?
• How should security teams prevent privilege creep in IAM and PAM programs?