Attribution breaks first, then policy enforcement and investigation quality. If the assistant and employee share one identity, security teams cannot tell whether an email was drafted, a file was moved, or a system was queried by the human or by the agent. That makes accountability incomplete and weakens incident response.
Why This Matters for Security Teams
When an AI assistant uses the same identity as the employee, the problem is not just cleaner logs versus messy logs. It collapses two different actors into one trust boundary. That means the organisation loses the ability to apply different policy, different revocation rules, and different risk scoring to a human and to an autonomous agent. For agentic systems, that is especially dangerous because the assistant may chain actions across email, chat, SaaS apps, and internal tools in a way the employee never directly intended.
The control failure is easiest to see in identity governance: a single account cannot express who initiated the action, what the agent was authorised to do, or whether the action should have expired after a task completed. NHI governance guidance from the Ultimate Guide to NHIs is clear that visibility and lifecycle control matter because NHIs behave differently from people. NIST’s NIST Cybersecurity Framework 2.0 also places a premium on identity, access, and traceability as core security outcomes.
In practice, many security teams only notice this failure after a review or incident has already turned into a guessing game about whether the employee or the agent clicked, queried, or exfiltrated something.
How It Works in Practice
The right pattern is to give the agent its own workload identity and separate policy path, then connect that identity to the human who delegated the task. That lets security teams preserve attribution while still allowing the assistant to act. For autonomous workflows, static RBAC is usually too blunt. An agent does not follow a fixed daily pattern; it may need different tools at different times, depending on prompt, context, data classification, and task phase. Current guidance suggests using intent-based authorisation, JIT credentialing, and short-lived secrets so access exists only for the task window, not for the whole account lifetime.
A practical implementation often includes:
- A distinct agent identity, ideally backed by cryptographic workload identity rather than a shared username.
- Per-task approval and context-aware policy evaluation, so access is decided at runtime, not pre-granted indefinitely.
- Ephemeral secrets and revocation on completion, which reduces the blast radius if the agent is compromised.
- Policy-as-code and audit trails that record both the delegating human and the executing agent.
This is where NHI incident patterns become useful. Research in the 52 NHI Breaches Analysis and the Top 10 NHI Issues shows that visibility gaps, excessive privileges, and poor secret hygiene are recurring causes of compromise. For implementation, align the architecture with NIST’s guidance on identity and risk control, and treat the agent as an autonomous workload rather than a human proxy.
These controls tend to break down when the assistant inherits a long-lived employee session cookie or mailbox token, because the agent can keep operating long after the human believes the task ended.
Common Variations and Edge Cases
Tighter identity separation often increases operational overhead, requiring organisations to balance attribution and containment against developer convenience and workflow latency. That tradeoff is real, especially in fast-moving agentic environments where teams want the assistant to “just work” inside chat, email, and ticketing systems. Best practice is evolving, but there is no universal standard for this yet, which is why framework alignment matters more than point-in-time vendor features.
One common edge case is delegated workflow execution. If an employee asks an assistant to draft an email, the assistant may only need read access, but if it also files the message, posts to a CRM, or triggers an API call, the identity should reflect those distinct actions. Another edge case is multi-agent orchestration, where one agent calls another through MCP or a tool chain. In those cases, a shared identity becomes even riskier because the security team loses the ability to see which autonomous component performed the action.
For current governance, the emerging direction is to separate human intent from agent execution and to record both in the control plane. The DeepSeek breach and JetBrains GitHub plugin token exposure are reminders that exposed secrets and over-broad access can turn an operational shortcut into an enterprise-wide exposure. In agentic environments, the safest assumption is that the assistant will eventually do something the employee did not explicitly plan.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Shared identities hide agent autonomy and break accountability. |
| CSA MAESTRO | MAESTRO addresses governance for autonomous multi-agent workflows. | |
| NIST AI RMF | AI RMF GOVERN and MAP support accountability for autonomous AI behaviour. |
Assign each agent a separate workload identity and evaluate access at request time.
