They should treat the creator’s credentials, the current user, and the agent’s effective permissions as separate governance questions. If a shared agent runs under the maker’s identity, access checks that only confirm login state will miss who really has authority at runtime. Identity governance has to follow the effective permission chain, not just the person who built the agent.
When the creator and user are different, which identity is being governed?
The key question is not just who built the agent, but who can cause it to act and under what authority. Governance has to distinguish the creator’s account, the current user’s session or delegation, and the permissions the agent actually exercises at runtime. If those are collapsed into one identity story, review and approval can miss the real control boundary.
That separation matters because maker identity, user context, and effective permissions can diverge quickly in shared or reused agents. A control that only proves the builder is logged in does not answer whether the person invoking the agent is authorised for the action it performs. In practice, the governed object is the full permission chain, not a single human actor.
How should organisations model maker, user, and effective authority?
Use a three-part model: provenance of the creator, authority of the current user, and the agent’s own operational permissions. The creator tells you who introduced the agent and what assumptions were made at design time. The user tells you who is asking for work now. The effective permission set tells you what the agent can actually touch, change, or forward to tools at execution time.
This model is especially important when agents are shared, embedded in workflows, or reused across teams. A single agent may be created by one function, invoked by another, and executed with credentials that were never intended for the current user’s business need. Governance should therefore track ownership, delegated use, and permission scope as separate records, not as one generic “agent owner” field.
Where the effective rights are broader than the current user would otherwise hold, that difference should be visible as an explicit control decision. If the agent can access production systems, sensitive records, or downstream services, the organisation needs to know whether that access is inherited from the maker, delegated per invocation, or standing on its own. That distinction is what makes review, revocation, and exception handling workable.
What changes when runtime authority is the real control point?
Once runtime authority becomes the control point, identity governance shifts from static ownership checks to continuous permission validation. The important question is no longer “who created this agent?” but “who can cause this agent to act right now, and with what effective scope?” That pushes governance toward session-aware approvals, explicit delegation records, and access decisions tied to action level rather than just account level.
It also changes how exceptions are handled. If a shared agent can act with the maker’s standing access, any missing revocation, stale delegation, or reused credential becomes an immediate governance issue rather than a paperwork issue. For that reason, controls should be designed so the current user and the agent’s authority can be independently reviewed, even when the workflow feels collaborative.
Risk and Threat Considerations
Shared agent identity can create privilege confusion, where a person with limited intent inherits the maker’s broader authority through the agent. That widens the blast radius of misuse, accidental action, and credential compromise, because the runtime path may be more powerful than the person invoking it appears to be.
Failure mechanism: The control fails when organisations validate login state or creator identity but do not validate the permissions actually available to the agent at execution time. That leaves delegated or reused access paths unexamined, which can allow unauthorised actions, overreach, or persistence through a shared tool path.
Impact: Misattributed authority can lead to excessive access, unintended data exposure, weak revocation, and poor auditability. It also makes incident response harder, because the organisation may have to reconstruct whether the maker, the user, or the agent’s standing permissions enabled the action.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Shared agent use creates runtime authority gaps and privilege confusion. |
| Recommendation — Separate creator, user, and agent authority checks before allowing action. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Delegated agent use depends on managing the credentials that enable runtime authority. |
| AC-6 — Least Privilege | The question centers on governing effective permissions rather than mere login state. | |
| AU-2 — Event Logging | Distinct maker, user, and runtime authority require traceable audit evidence. | |
| Recommendation — Rotate and revoke credentials that grant agents their effective permissions. Constrain agent permissions to the minimum scope needed for each task. Log who invoked the agent, what authority it used, and what actions it took. | ||
Practitioner Guidance
What to verify: Confirm that every shared agent has an explicit owner, an explicit current user or delegate record, and a defined effective permission set. If those three cannot be separated in audit evidence, the governance model is too weak to trust.
Decision rule: If the agent’s runtime permissions exceed what the current user should directly hold, treat the agent as a privileged intermediary and require explicit approval, scoping, and revocation handling. If the permissions are user-bound and short-lived, governance can be lighter, but it still needs to be traceable to the active session.
Practitioner takeaway: The safest model is to govern the authority that can actually execute, not the identity that merely created the agent. In shared-agent environments, runtime permission chain visibility is the difference between meaningful governance and a false sense of control.
Related resources from NHI Mgmt Group
- How can organisations reduce the blast radius of compromised agent identities?
- How should organisations govern identity lifecycle changes across users and non-human accounts?
- How should organisations govern identity when digital access and physical access are split across different systems?
- How should healthcare organisations govern access when identity is tied to relationships, not just users?