A delegation pattern where an agent runs under the identity of the person who created it rather than the person using it. This is especially risky in shared agent platforms because every downstream user can inherit the maker’s broader permissions and data access.
Expanded Definition
Maker’s Identity is a delegation model in which an agent executes under the creator’s identity instead of an identity bound to the current operator, workflow, or task. In NHI and agentic AI environments, that means the agent inherits the maker’s entitlements, audit trail, and often the maker’s broader data reach. The model can be convenient for rapid deployment, but it becomes dangerous when the identity is reused across multiple users or projects without a clear boundary between authorship and execution. That boundary is central to Zero Trust thinking and is consistent with the access-control emphasis in NIST Cybersecurity Framework 2.0.
Definitions vary across vendors because some platforms treat maker identity as a convenience feature, while others treat it as an implicit trust relationship. NHI Management Group recommends reading it as a delegation pattern that must be governed like any other privileged non-human identity, with explicit ownership, scoping, and revocation. The most common misapplication is assuming the maker’s identity is a harmless shortcut, which occurs when shared agents are deployed without per-user authorization boundaries.
Examples and Use Cases
Implementing Maker’s Identity rigorously often introduces operational friction, requiring organisations to weigh ease of collaboration against the risk of broad inherited access.
- A developer creates an internal coding agent that can read source repositories and ticketing systems, and every teammate using that agent inherits the developer’s access unless the platform rebinds identity at run time.
- An analyst shares a report-generation agent across a department, but the agent sends data through the maker’s email and storage permissions, exposing records the current user should not see.
- A support team uses a shared automation agent for customer refunds, and the agent can approve actions because it runs as the maker, not the ticket assignee.
- In shared agent platforms, maker-bound execution may appear to simplify onboarding, but it complicates auditability because attribution reflects the creator, not the person who initiated the action.
- In real-world NHI incidents, insecure delegation often resembles the credential exposure patterns described in the 52 NHI Breaches Analysis, where excessive access and weak containment turn a convenience feature into a compromise multiplier.
For implementation guidance, teams should compare maker-bound execution with identity-aware controls in the NIST guidance and with agent isolation patterns discussed in Ultimate Guide to NHIs. The right use case is narrow, usually prototyping or tightly scoped single-owner automation with strong governance.
Why It Matters in NHI Security
Maker’s Identity matters because it can silently convert one person’s permissions into many users’ effective access, undermining least privilege, segregation of duties, and clean offboarding. In NHI environments, that is especially hazardous when agents touch secrets, production systems, or sensitive customer data. NHIMG reports that 97% of NHIs carry excessive privileges, and that pattern is exactly what maker-bound execution can amplify when a creator’s permissions are reused broadly. The risk becomes more visible when teams discover that the agent’s audit trail points to the maker even though the action was triggered by someone else, making incident response and accountability much harder.
This is not just an IAM design issue. It is a governance issue tied to secret exposure, over-permissioned service accounts, and the weak lifecycle controls documented in Top 10 NHI Issues. The security model should instead align with NIST’s identity and access discipline and with explicit non-human identity management practices described in the Ultimate Guide to NHIs. Organisations typically encounter the real impact only after a misuse, exfiltration, or privilege abuse event, at which point Maker’s Identity 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 Agentic AI Top 10, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AI-04 | Maker-bound execution is a delegation risk in agentic systems with inherited authority. |
| OWASP Non-Human Identity Top 10 | NHI-01 | This pattern creates overbroad non-human access and weak ownership boundaries. |
| NIST CSF 2.0 | PR.AC | Access control and least privilege govern whether creator permissions are inappropriately reused. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires per-request authorization rather than inherited trust from the creator. | |
| CSA MAESTRO | IAM | Agent governance depends on identity isolation and controlled delegation. |
Bind each agent action to the current user and prevent creator privileges from flowing to every session.
