A model where the resource owner or administrator decides who gets access and at what level. It is flexible and easy to understand, but governance quality depends heavily on individual judgement and local discipline, which makes it harder to scale cleanly across large or fast-changing environments.
Expanded Definition
Discretionary Access Control, or DAC, is an access model in which the resource owner or an administrator decides who can use a resource and at what level. In NHI environments, that might mean a developer granting a service account access to an API, a platform owner approving a secret read path, or an operator delegating use of a certificate-backed workload identity. The model is highly flexible, but that flexibility cuts both ways: decisions are local, permissions can multiply quickly, and access often inherits the judgement of the last person who changed it.
For non-human identities, DAC is often contrasted with centralised policy enforcement and Zero Trust controls. The distinction matters because an AI agent or service account may receive access based on convenience rather than verified business need, especially when teams rely on manual approvals. The OWASP Non-Human Identity Top 10 highlights this as a recurring governance weakness, while the NHI Management Group Ultimate Guide to NHIs frames it as a lifecycle problem as much as an access problem. Definitions vary across vendors when they describe DAC in cloud and agentic AI contexts, but the core idea remains owner-driven permissioning. The most common misapplication is treating ad hoc owner approval as governance, which occurs when teams equate speed of access with controlled access.
Examples and Use Cases
Implementing DAC rigorously often introduces review overhead and inconsistent outcomes, requiring organisations to weigh developer autonomy against the cost of drift and privilege sprawl.
- A software team grants a build service account read access to a repository so a deployment job can retrieve artifacts without requiring a central IAM change.
- An application owner approves an API key’s access to a limited data set, then later expands that access during troubleshooting without a formal review.
- An AI agent is allowed to invoke a ticketing tool because the workflow owner judged the permission acceptable, even though the broader platform policy has not been updated.
- A platform administrator relies on local ownership rules for secret retrieval, which can work well for small teams but becomes brittle as key challenges and risks grow across environments.
- In a PCI-scoped environment, a team grants a batch process access to payment-related logs for reconciliation, then must prove that the access path remains limited and justified under PCI DSS v4.0.
These scenarios show why DAC is common in fast-moving engineering organisations: it is easy to use, but each owner decision becomes part of the security posture. The NHI Management Group 52 NHI Breaches Analysis shows how small access decisions can cascade into larger compromise conditions when they are not revisited.
Why It Matters in NHI Security
DAC matters because many NHI incidents begin with permission that looked reasonable at the time but was never revisited. In practice, owner-driven access can produce excessive privileges, weak revocation discipline, and unclear accountability when service accounts, secrets, and agent credentials are shared across teams. NHI Management Group reports that 97% of NHIs carry excessive privileges, and that pattern is exactly where DAC becomes dangerous: local convenience outpaces central control, especially when access is granted to keep pipelines moving or automation unblocked. The same guide also notes that only 20% have formal processes for offboarding and revoking API keys, which means discretionary access often persists long after the original task is finished.
That risk is not purely theoretical. If a workload identity is granted broad access by a product owner, the team may not discover the exposure until audit, incident response, or a failed rotation exposes the gap. At that point, the organisation must answer who approved the access, why it was needed, and whether the same judgement was reused elsewhere. Organisations typically encounter the consequences only after a secret leak, unauthorised API call, or lateral movement event, at which point discretionary access control becomes operationally unavoidable to address.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
