Claude as a personal assistant exposes the agent identity gap

At a glance

What this is: This is an analysis of employee-facing AI assistants and the identity controls they require, with the key finding that current human-centric access models do not separate agent actions from user actions.

Why it matters: It matters because IAM, NHI, PAM, and governance teams now have to decide how to authenticate, authorise, and audit AI agents that operate across human workflows, shared data, and internal systems.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.

👉 Read Aembit's case study on securing Claude for employee AI assistants

Context

AI agent identity refers to how a non-human actor is identified, authorised, and audited when it performs work on behalf of a person. In this case, the problem is not whether employees should use personal assistants, but whether those assistants can be governed as separate actors across email, calendar, documents, and internal applications. The primary keyword here is AI agent identity.

Most enterprises still treat the assistant as an extension of the human user, which collapses the distinction between user intent and agent action. That works only until the assistant can move through Microsoft 365, internal systems, and data repositories with enough breadth that the organisation can no longer explain who did what, when, and under which policy.

That is a typical starting position for early agent deployments: enthusiasm first, identity design later. The article shows why that order creates avoidable governance debt.

Key questions

Q: How should security teams govern personal AI assistants that act on behalf of employees?

A: Treat each assistant as a distinct non-human actor with its own identity, policy scope, and audit trail. Human delegation alone is not enough when the assistant can move across email, documents, calendars, and internal systems. Governance should bind the sponsor, the executor, and the target resource so access reviews and investigations can separate request from action.

Q: Why do AI agents complicate existing IAM and access review processes?

A: Because traditional IAM assumes the authenticated subject is also the actor whose access is being reviewed. AI agents break that assumption when they execute tasks on behalf of a person, sometimes across multiple systems in one workflow. Review cycles must therefore evaluate what the agent can do, what it actually did, and whether the current scope still matches the task.

Q: What breaks when an AI assistant uses the same identity as the employee?

A: 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.

Q: Who is accountable when an employee-facing AI agent makes a risky action?

A: Accountability should remain with the sponsoring organisation, but operational ownership must be split between the human requester, the platform team that granted access, and the governance team that approved the scope. Frameworks such as the NIST AI Risk Management Framework and Zero Trust Architecture both support that shared accountability model.

Technical breakdown

Blended agent-human identity and why separate credentials matter

A blended identity model attempts to bind the human sponsor and the agentic actor into a single verified access path. The design goal is not just login convenience, but traceability, policy scoping, and post-action attribution. Without a distinct credential boundary, the organisation cannot reliably distinguish a human-initiated request from an agent-executed action, especially when the agent is allowed to move between email, documents, calendar, and downstream systems. In identity terms, the problem is not authentication alone. It is whether the access token represents one accountable actor or two different decision-making entities operating through the same work session.

Practical implication: define whether agent access is issued as a separate actor with its own policy surface or merely as delegated human access.

Runtime policy enforcement for AI agents in Microsoft 365 and MCP environments

Runtime policy enforcement is the control layer that evaluates what an agent can do at the moment it attempts an action, not just at provisioning time. That matters when an assistant can interact with Microsoft Graph, SharePoint, or MCP-connected tools because effective risk depends on context, data sensitivity, and action type. Static permissions alone do not answer whether an agent may read, write, forward, or extract information in a given session. For agentic AI, the real governance question is whether authorisation is evaluated continuously enough to prevent scope creep as the task unfolds.

Practical implication: put policy decisions at execution time, not just at onboarding or app-consent time.

Audit logging that separates user intent from agent execution

Agentic AI creates a new audit problem because the visible user is not always the true executor of each action. If logs only show the employee identity, then investigations cannot tell whether the human asked for a result or the assistant autonomously carried out a sequence of steps. That distinction matters for incident response, access review, and accountability. Good logging must capture the agent identity, the human sponsor, the target resource, and the action path. Otherwise, the organisation has activity records but not trustworthy evidence.

Practical implication: require logs that preserve both the human sponsor and the agent executor for every sensitive action.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI assistants are becoming a new identity class, not a new interface. Once a personal assistant can access email, calendars, document stores, and internal systems, it stops behaving like a convenience layer and starts behaving like an actor with operational consequences. Identity governance has to classify that actor explicitly, or the organisation will keep borrowing human controls for a machine behaviour pattern that does not fit them. The implication is that agentic access needs its own policy and audit model, not a rebranded user session.

Separate attribution is the governance gap most enterprises are missing. Human-centric access models assume the same subject that authenticates is also the subject that acts. That assumption weakens when an assistant can generate, select, and execute actions across the work stack on the user's behalf. If the organisation cannot distinguish sponsor from executor, recertification and incident review become incomplete by design.

Agentic AI expands the attack surface because breadth of utility requires breadth of privilege. A useful personal assistant must cross application boundaries, which means it inherits more data pathways than most service accounts ever receive. That broad access should trigger the same discipline applied to privileged non-human identities, including least privilege, scope limitation, and action-level evidence. The practitioner conclusion is simple: utility without actor separation becomes governance debt.

Runtime authorisation becomes more important than onboarding approval for agentic systems. The article describes a model where security teams would not allow rollout until the foundation was in place. That aligns with the reality that many agent risks emerge mid-task, when the assistant decides what to touch next. The issue is not whether the request was initially legitimate. The issue is whether the next action is still authorised in context.

Identity blast radius: Personal AI assistants create a blast radius that is defined by every system they can reach, not by a single application boundary. Once agents can move across Microsoft 365 and internal data systems, a single policy mistake can propagate across email, documents, and downstream workflows. Practitioners should treat that as a governance boundary problem, not just a tool deployment problem.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
• For a deeper control lens, see OWASP NHI Top 10 for agentic application risks and governance pressure points.

What this signals

The near-term signal is that personal assistants will be governed less like productivity features and more like privileged non-human identities. With 70% of organisations already granting AI systems more access than they would give a human employee performing the same job, per the 2026 Infrastructure Identity Survey, the access model is already outpacing the review model.

Delegation debt: When employee convenience expands faster than identity design, the organisation accrues delegation debt. That debt shows up later as unclear accountability, over-broad scopes, and incomplete audit evidence across hybrid human and agent workflows.

If your programme already uses Zero Trust principles, the next step is to apply them to the agent as a first-class actor rather than an implicit extension of the user. The NIST AI Risk Management Framework provides the right governance language, but the operational work is in binding policy, logging, and lifecycle ownership to the assistant itself.

For practitioners

• Assign a distinct identity to each AI assistant Do not let the assistant inherit the employee session as if it were just another browser tab. Bind the human sponsor and the agent executor into separately auditable identity records so policy, review, and incident response can distinguish them.
• Apply runtime policy checks to every sensitive action Evaluate each request against data sensitivity, action type, and target system at execution time, especially for Microsoft 365, SharePoint, and Graph-connected workflows. Do not rely on one-time app consent or broad delegation grants.
• Limit agent reach before expanding assistant utility Map the minimum systems and data required for the assistant to be useful, then restrict access to that surface area. If the assistant can read, write, forward, or summarise content, those verbs should be explicitly authorised and logged.
• Separate sponsor, executor, and target in audit records Capture which employee requested the action, which agent carried it out, and which resource was touched. That structure is essential for recertification, investigation, and evidence-based access reviews.

Key takeaways

• Employee-facing AI assistants become an identity problem as soon as they can operate across multiple business systems.
• The real risk is not only access breadth, but the loss of separation between the employee who asks and the agent that acts.
• Practitioners should treat agent identity, runtime policy, and audit separation as prerequisites, not optional hardening.

Key terms

• AI Agent Identity: The identity assigned to a software actor that can perform work on behalf of a person or process. In agentic environments, identity must support authentication, authorisation, and audit separation so that the human sponsor and the machine executor are not collapsed into one record.
• Blended Identity Model: A governance pattern that binds a human sponsor and a machine executor into one access relationship while preserving distinct accountability. It is used when an AI assistant needs to act across multiple systems but must still be controlled, logged, and reviewed as a separate actor.
• Runtime Policy Enforcement: A control method that checks whether an action is allowed at the moment it is attempted, rather than only when access is first granted. For agentic AI, this is essential because the next step may depend on context, data sensitivity, or a tool choice made mid-session.
• Audit Attribution: The ability to prove who requested an action, which actor executed it, and what resource was affected. In AI agent governance, attribution must be richer than a single username because accountability breaks when the human and the agent share one visible identity.

Deepen your knowledge

AI agent identity and runtime access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for employee-facing assistants, the course can help you translate governance into operational design.

This post draws on content published by Aembit: a case study on securing Claude as a personal assistant for employees. Read the original.