Keep Rule

Expanded Definition

A keep rule is a preservation directive used in build and obfuscation pipelines to prevent specific program elements from being renamed, removed, inlined, or merged. In NHI-heavy systems, that usually means protecting runtime symbols that frameworks, serializers, dependency injectors, or reflection logic locate by name rather than by a compile-time reference. The term is implementation-specific, and definitions vary across vendors, but the operational goal is consistent: preserve exactly the code paths that runtime discovery depends on. The most useful way to think about a keep rule is as a boundary between code that can be safely transformed and code that must remain stable for execution to succeed. For broader governance context, NIST Cybersecurity Framework 2.0 emphasises protecting the assets that support reliable identity and application operations, which includes preserving identity-relevant runtime behavior where needed.

The most common misapplication is keeping too much code, which occurs when teams apply broad wildcards to avoid build failures and accidentally preserve unnecessary symbols.

Examples and Use Cases

Implementing keep rules rigorously often introduces maintenance overhead, requiring organisations to weigh build stability against smaller binaries, stronger obfuscation, and simpler attack surface reduction.

• Preserving a service account model class so JSON serialization still maps the expected field names after obfuscation.
• Keeping an annotation-driven factory method that a framework loads by reflection during startup.
• Protecting API client classes whose method names are discovered dynamically by an agent or plugin host.
• Retaining certificate-loading utilities that a runtime library resolves through name-based lookup during mutual TLS setup.
• Maintaining identity-related helper objects so audit exporters and token mappers continue to function after minification.

For deeper NHI context, the Ultimate Guide to NHIs shows how fragile service-account and secret handling becomes when runtime assumptions are not documented. In application security guidance, the NIST Cybersecurity Framework 2.0 is a useful anchor for deciding which assets must remain stable because they support security functions or identity flows.

Why It Matters in NHI Security

Keep rules matter because NHI systems often depend on runtime name resolution in the exact places that are hardest to test exhaustively: service discovery, token parsing, secret loading, and policy enforcement. If an optimiser strips or renames a symbol, the failure may not appear until an agent, service account, or API client reaches production traffic. That creates a security issue as much as an availability issue, because broken identity plumbing can lead teams to widen permissions, disable validation, or hardcode secrets as a workaround. NHIMG research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations, and that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes runtime integrity especially important when those identities are embedded in application code. The same Ultimate Guide to NHIs also highlights how common visibility and rotation gaps are, which compounds the impact of a build-time preservation mistake.

Organisations typically encounter keep-rule mistakes only after a release breaks authentication, serialization, or policy lookup in production, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does an NHI become too risky to keep as-is?
• When does an OAuth integration become too risky to keep?
• When does AI agent access become too risky to keep standing?
• How should security teams keep identity security from becoming a pure IT project?