Security teams should treat the invoking user, not the agent, as the authority being exercised. Shared agents must re-check the caller’s permissions at runtime and ensure the agent can only act within that user’s effective access. Without that second check, a builder’s privileges can silently become everyone’s privileges after the agent is shared.
Why Maker Mode Becomes a Privilege Boundary Problem
Maker mode is useful because it lets a person configure an agent once and share it with others, but that convenience becomes dangerous when the shared agent keeps acting with the maker’s standing privileges. The security issue is not the agent itself; it is the mismatch between who created the agent and who is currently using it. If runtime authorisation is not re-evaluated, a low-privilege user can trigger actions that were only safe for the original builder.
That is why shared agents need explicit identity scoping, not just feature controls. The control question is whether the agent can prove the caller’s effective access before it performs a tool call, data fetch, write action, or escalation step. Shared autonomy without that check turns a reusable workflow into a standing authorisation channel. The OWASP OWASP Top 10 for Agentic Applications 2026 is useful here because it frames agent behaviour as an access and trust problem, not only a prompt-safety problem.
In practice, teams usually notice the weakness only after a shared agent has already been distributed widely and its original maker privileges have quietly become the de facto ceiling for everyone.
How It Works in Practice
The safest pattern is to treat the agent as an execution layer that inherits authority from the active caller at runtime, not from the person who assembled the workflow. That means the agent should check the requester’s identity, evaluate the user’s current entitlements, and constrain every tool call to the intersection of the caller’s permissions and the task being attempted. For shared agents, the important question is not “who built this?” but “what is this user allowed to do right now?”
Operationally, teams usually need three controls working together:
- runtime permission checks before each sensitive action, not just at session start
- short-lived credentials or delegated tokens scoped to the caller’s role and context
- tool-specific guardrails that separate read, write, and privileged administrative actions
This matters because many agent platforms blur the line between configuration time and execution time. A maker may connect a broad service account, save the agent, then share it with a wider group. If the shared instance can still access the same upstream systems, the agent becomes a privilege multiplier. NHIMG’s research on the OWASP NHI Top 10 is relevant because it reinforces the need to govern non-human execution paths as distinct identity surfaces, not as extensions of the builder’s account.
Teams should also decide whether the agent may act on behalf of the caller at all, or whether it should only prepare drafts, recommendations, or queued actions for explicit human approval. That distinction matters when a shared agent can reach systems of record, because approval-free execution is where inherited privilege becomes most dangerous. These controls tend to break down when the agent is given a single broad connector account and then embedded into multiple workflows with different trust levels.
Common Variations and Edge Cases
Tighter runtime gating often increases friction, so organisations have to balance convenience against blast-radius reduction. The trade-off is most visible in internal productivity agents, where teams want a single reusable assistant but also need different access outcomes for executives, developers, support staff, and contractors.
One common edge case is delegated access through group membership. A user may appear to have permission because they can launch the shared agent, yet the downstream tool call should still fail if they do not personally hold the target entitlement. Another is “maker-approved” sharing, where the creator is asked to bless the workflow once and that approval is then reused forever. Best practice is evolving, but there is no universal standard for this yet; current guidance suggests treating sharing permission and execution permission as separate decisions.
A second edge case is sensitive write access. Read-only agents are easier to share safely, but the moment the agent can modify records, send messages, approve transactions, or provision access, the risk moves from convenience to control failure. Security teams should be especially cautious when shared agents connect to systems that already aggregate privilege, because the agent then inherits both the user’s authority and the platform’s reach. The practical test is simple: if a caller cannot perform the action directly, the shared agent should not be able to perform it silently on the caller’s behalf.
Risk and Threat Considerations
Shared agents create a privilege-escalation risk when maker authority is reused as execution authority. The exposure is strongest in environments where the agent can reach multiple internal systems through one connector, because that single path can amplify access across data, admin, and workflow functions.
Failure mechanism: The control fails when the agent evaluates the maker’s standing privileges once and then reuses them for later callers, or when the platform only checks whether a user can launch the agent rather than what that user can actually do. Attackers and insider-abusers can then trigger higher-value actions through a shared interface that appears ordinary.
Impact: A low-privilege user may be able to read data, change records, send privileged requests, or invoke administrative actions that should have been blocked. At scale, that creates a systemic trust failure because one shared agent can expose the permissions of the most powerful user who ever configured it.
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 MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 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 | Agentic Access Control — Agentic Access Control | Shared agents can overstep caller authority without runtime access checks. |
| Recommendation — Enforce caller-scoped checks before every sensitive agent action. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Secrets and Credential Management | Maker mode often reuses shared credentials or delegated tokens behind the agent. |
| Recommendation — Scope credentials to the active caller and rotate any broad shared secrets. | ||
| CIS Controls v8 | 6.3 — Access Rights Management | Shared agents must not preserve excess privileges across different users. |
| Recommendation — Review and remove access paths that let shared agents exceed user entitlement. | ||
| NIST Zero Trust (SP 800-207) | Policy Decision Point — Policy Decision Point | Runtime authorization should decide each action based on current identity and context. |
| Recommendation — Evaluate each agent request at runtime before granting downstream access. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Abuse of legitimate shared access can turn maker privileges into lateral privilege gain. |
| Recommendation — Monitor shared-agent use for legitimate-account abuse and privilege expansion. | ||
Practitioner Guidance
What to prioritise: Separate launch permission from execution permission. If the platform cannot enforce caller-scoped authorisation at runtime, treat shared agent action capability as high risk and limit the agent to non-sensitive tasks.
What to verify: Confirm that every sensitive tool call is checked against the active user’s current access, not the maker’s access or a cached session grant. Validate this with a user who has less privilege than the builder.
Decision rule: If the agent can write, approve, delete, or provision, require short-lived delegated access and an explicit boundary on which identities may use that capability. If it cannot enforce that boundary, remove the action rather than rely on policy intent alone.
Practitioner takeaway: The safe design goal is not “shared agents for everyone”; it is “shared agents that cannot exceed the caller’s own authority, even when the original maker could.”
Related resources from NHI Mgmt Group
- How should security teams manage permissions for AI agents?
- How should security teams govern AI agents that use OAuth access?
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams govern AI agents that can access enterprise systems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
