A configuration approach in Go that uses composable WithX functions to set provider behaviour at construction time. It lets teams pass only the settings they need, making credential provider setup more flexible while keeping the core API consistent across different cloud integrations.
Expanded Definition
The option pattern is a construction-time configuration style that passes composable Go functions, often named WithX, into a provider or client so behaviour is set before execution begins. In NHI and credential-provider code, this pattern is used to configure endpoints, caches, timeouts, retry logic, scopes, and secret sources without expanding the constructor into an unreadable parameter list.
Its main value is consistency. Teams can expose a stable API while allowing different cloud integrations, vault backends, or agent runtimes to supply only the settings they need. Definitions vary across vendors and libraries, but the core idea is the same: optional behaviour is expressed as explicit, typed configuration rather than hidden globals or ad hoc maps. In practice, that makes NHI components easier to compose and review, especially when a provider must behave differently across build, test, and production environments.
The most common misapplication is treating option functions as a substitute for policy, which occurs when security-critical defaults are left implicit and never validated at construction time.
Examples and Use Cases
Implementing the option pattern rigorously often introduces more constructor discipline, requiring organisations to weigh API clarity against the overhead of defining and validating each option.
- A Go-based secrets client accepts WithVaultURL, WithAudience, and WithCacheTTL so a workload can target one identity boundary without changing the provider interface.
- An agentic tool runner uses options to set token exchange settings, retries, and clock skew tolerance while preserving a single constructor for multiple cloud environments.
- A platform team reviews an implementation after the kind of credential exposure seen in the SpotBugs Token GitHub Supply Chain Attack, then adds options for stricter secret source selection and shorter-lived tokens.
- A service account library exposes WithRotationWindow and WithTransportConfig so operators can tune lifecycle behaviour without forking the package.
- Security engineers align client construction with guidance from the NIST Cybersecurity Framework 2.0 by making authentication and logging settings explicit options.
Why It Matters in NHI Security
The option pattern matters because NHI security failures often begin with invisible defaults. A provider that silently accepts long-lived credentials, broad scopes, or unbounded retries can increase blast radius long before a compromise becomes visible. NHIMG research shows that 71% of NHIs are not rotated within recommended time frames, and 97% carry excessive privileges, which makes poorly constrained provider configuration a real governance issue rather than a coding preference.
When used well, the pattern supports least privilege, predictable lifecycle controls, and easier review of how a workload obtains and uses secrets. It also helps teams encode secure defaults while still allowing controlled exceptions for specific environments. That is especially important when identity material is distributed across CI/CD, service meshes, and cloud SDK wrappers, where hidden behaviour can undermine zero trust assumptions.
Organisations typically encounter the operational cost of weak option design only after a secrets leak or unauthorized access event, at which point the pattern becomes unavoidable to address.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Option-based constructors can hide insecure defaults unless NHI controls are explicit. |
| NIST CSF 2.0 | PR.AC-4 | Explicit provider options support least-privilege access and controlled system use. |
| NIST Zero Trust (SP 800-207) | Zero Trust relies on explicit trust boundaries, which option configuration can enforce. | |
| NIST SP 800-63 | Credential assurance depends on how provider settings constrain authenticators and tokens. | |
| OWASP Agentic AI Top 10 | Agent tool access often depends on constructor options that govern execution authority. |
Make every security-relevant constructor option validated and default to least privilege.
Related resources from NHI Mgmt Group
- What is the difference between pattern matching and AI-native classification for sensitive data?
- What breaks when organisations use one Azure identity pattern for every workload?
- Why do standing NHI credentials remain such a high-risk pattern?
- When does a cloud-native directory become the better option?
