An operating pattern where an AI agent runs using the credentials of the person who created it rather than a tightly scoped runtime identity. This can overstate privilege, weaken accountability, and expand blast radius because the agent inherits human authority that may exceed the workflow’s needs.
Expanded Definition
Maker mode describes a deployment pattern in which an AI agent operates under the creator’s own credentials rather than a purpose-built runtime identity. In NHI governance, that matters because the agent is not just acting with delegated access, it is acting as if it were the human itself. That can blur ownership, complicate audit trails, and make access reviews look cleaner than they are in practice.
Definitions vary across vendors because some tools frame maker mode as a convenience feature, while others treat it as a temporary development setting. NHI Management Group recommends treating it as a high-risk exception state, not a default operating model. The correct comparison is not “human versus agent,” but whether the agent has a narrowly scoped identity, traceable authorization, and revocation path. Guidance in NIST Cybersecurity Framework 2.0 aligns with this principle through identity governance and least-privilege expectations.
The most common misapplication is leaving maker mode enabled after testing or prototyping, which occurs when the agent is promoted into production without identity redesign.
Examples and Use Cases
Implementing maker mode rigorously often introduces friction, because teams must choose between faster agent rollout and stronger separation of duties, traceability, and revocation control.
- A developer launches an internal coding agent that can commit changes, open pull requests, and read repositories using the developer’s own access token.
- A customer support AI drafts refunds or account changes under the employee’s session, creating a false impression that the human approved every action.
- An operations agent triggers infrastructure changes with the creator’s cloud permissions instead of a scoped service account, making emergency access indistinguishable from routine automation.
- A workflow prototype is moved into production before a dedicated NHI identity is issued, leaving the agent tied to the maker’s long-lived credentials.
These patterns show why NHI visibility matters. The Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which makes maker-mode inheritance especially hard to detect. For runtime identity design, teams should compare the pattern against the authorization and audit expectations described in NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Maker mode becomes dangerous when a human’s broad authority is silently extended into automated execution. That can inflate privilege, weaken accountability, and let an AI agent access systems, secrets, or data that the underlying workflow does not actually require. It also undermines offboarding, because revoking the creator’s access may unintentionally break legitimate work while leaving the agent’s real dependency chain unclear.
This is especially consequential in environments where secrets are already poorly controlled. NHI Management Group reports that 97% of NHIs carry excessive privileges and 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, according to the Ultimate Guide to NHIs. In practice, maker mode can turn a single compromise into a much broader incident because the agent inherits the maker’s trust context rather than operating as a bounded identity.
Organisations typically encounter the full consequence only after an agent misuses inherited access or a creator leaves the company, at which point maker mode becomes operationally 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 | Maker mode is a privileged identity design anti-pattern that expands NHI blast radius. |
| OWASP Agentic AI Top 10 | A-03 | Agent autonomy and delegated authority need explicit limits when using maker mode. |
| NIST CSF 2.0 | PR.AA | Identity and access assurance practices govern whether an agent may act as its creator. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero Trust rejects implicit trust based on the maker's human identity. |
| NIST SP 800-63 | AAL2 | Assurance concepts help distinguish human authentication from agent authorization. |
Replace maker credentials with a scoped runtime identity and remove inherited human privilege.
