A shared-agent access pattern where the credentials or effective permissions of the person who built the agent are reused by later users. In practice, this can create entitlement inheritance that outlives the original trust decision and obscures who should be accountable for access.
Expanded Definition
Maker’s token describes a shared-agent access pattern in which the builder’s credentials, API keys, or effective permissions are reused by later users of the agent. In NHI practice, that means the agent inherits trust from the original author rather than from the person or system invoking it. This is different from ordinary delegated access, where identity, scope, and accountability remain explicit for each use. Maker’s token commonly appears in agent templates, internal automations, and prototype workflows when teams choose convenience over per-user authorization. Because the agent can act with the maker’s standing privileges, the real access path may be invisible to reviewers, auditors, and incident responders. Definitions vary across vendors because some tools treat this as a credential-sharing flaw while others frame it as a policy and provenance problem. The control issue is the same: the effective privilege outlives the original trust decision, which should not happen in a governed NHI environment. The most common misapplication is treating the maker’s account as a harmless bootstrap identity, which occurs when later users inherit the agent without revalidating scope or ownership.
Examples and Use Cases
Implementing agent access rigorously often introduces onboarding friction, requiring organisations to weigh faster reuse against tighter identity boundaries and approval flows. The pattern appears across build systems, support automations, and AI assistants when ownership is not separated from execution authority.
- A developer publishes an internal support agent with their own cloud token embedded in the workflow, and every colleague who launches it inherits the developer’s repository and ticketing access.
- A prompt-to-action agent created for incident triage keeps using the builder’s mailbox and chat permissions after the builder changes roles, so the agent can still read restricted channels.
- A CI-connected agent is cloned into a new project without replacing the original service account, creating hidden entitlement inheritance across multiple teams.
- An ops assistant built during a pilot remains in production after the pilot ends, and users assume it is governed by their own RBAC assignment rather than the maker’s standing permissions.
- Credential exposure patterns documented in the Guide to the Secret Sprawl Challenge and in NIST’s NIST Cybersecurity Framework 2.0 show why inherited access must be deliberately broken at handoff.
Related breach patterns also appear in the Salesloft OAuth token breach, where reused access paths amplified downstream impact.
Why It Matters in NHI Security
Maker’s token matters because it collapses the boundary between identity, authorization, and accountability. When a later user can operate through the original maker’s privileges, governance teams lose the ability to answer a basic question: who actually had authority at the time of action? That confusion is especially dangerous in NHI systems where agents can transact, retrieve secrets, and chain tool calls without direct human supervision. It also undermines offboarding, separation of duties, and privileged access reviews, because the relevant access may be hidden inside the agent rather than attached to an obvious account. NHIMG research shows that 60% of NHIs are overused and 91% of former employee tokens remain active after offboarding, which makes inherited access a realistic risk rather than a theoretical edge case. The same pattern is visible when credentials surface in the wild through tickets, collaboration tools, or code, as described in the 2025 State of NHIs and Secrets in Cybersecurity and the State of Secrets Sprawl 2026. Organisations typically encounter the damage only after a role change, incident, or audit reveals that the agent was still acting on behalf of someone who no longer owned the trust.
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-02 | Covers secret exposure and reuse risks that enable inherited agent access. |
| OWASP Agentic AI Top 10 | A-03 | Addresses agent authorization boundaries and unsafe tool access patterns. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access management is directly implicated by maker token inheritance. |
| NIST Zero Trust (SP 800-207) | PL-5 | Zero Trust requires continuous verification instead of trusting inherited identity state. |
| NIST SP 800-63 | AAL2 | Assurance levels inform how strongly an agent's delegated access should be bound. |
Replace maker-scoped credentials with per-user or per-workflow authorization and rotate exposed secrets.
