.webp)
Personal agents are becoming more popular and present risks to enterprise environments that security teams can’t always see.
Agents like Meta's Muse allow users to connect services and delegate tasks through their existing access - borrowing the identity of the user.
When those services hold corporate data, an employee's decision to connect an account becomes an enterprise security concern. Whether that use is approved or not, once the agent accesses enterprise data and systems, security teams need to be able to establish what it accessed, what it changed, whose authority it used, and why those actions were permitted.
That is difficult when the agent's actions are indistinguishable from the user's. Muse gives the individual user an activity trail, but Meta’s published security materials do not describe an equivalent enterprise view through centralized audit exports or integrations with security monitoring systems.
This illustrates why enterprises can't rely on agent vendors to provide the controls security teams need. It's also a lesson in why agents should never share the identity of a human user, and what enterprises lose when they do.
Borrowed access feeds the problem
Agents that borrow a user's identity, access, and authority are incredibly common and once connected, the agent can do anything the person can.
This access model creates several risks. The agent receives the user's full permissions rather than only what the task requires, so an agent asked to summarize one folder can reach every file the employee can. In system logs, its actions appear under the employee's name, so security teams can't separate a person's actions from an agent's or apply different rules to each.
The exposure grows if the agent is manipulated or compromised. An agent tricked by malicious instructions in an email or document, or hijacked by an attacker, acts with everything its user can reach. There have been countless examples of this in recent months.
Agents should be recognized as distinct actors, operating with their own identity and authority explicitly delegated by a person and scoped to a purpose. Their access can then be limited, monitored, and revoked without affecting the person they work for.
Governing actions, not just access
Controlling which agents employees can connect is a start, but it won't catch everything, and it says nothing about what an approved agent does once it is inside the enterprise environment.
Governance and control need to be applied as the agent acts, not just at login. Each request should be evaluated based on dynamic policies that consider who has tasked the agent, what authority was delegated, how the requester relates to the data, how sensitive that data is, and the context of the request.
AI agent governance should also ensure every agent action and decision leaves traceable evidence. When an agent acts, security teams should be able to see the person it acted for, the authority it used, the policy applied, and the outcome, and live context that contributed to its decisions.
Don't repeat the Muse model
Security teams will keep working to find and restrict unsanctioned agents like Muse, however the lesson for enterprises extends to the agents they approve and deploy. Approval should not give an agent unrestricted use of a person’s access.
Each agent needs its own identity, explicitly delegated authority, and oversight through an enterprise-owned AI control plane. That layer should use current identity and data context to enforce policy on each request and record why access was permitted or denied. Security teams can then trace an agent’s actions to the authority and decisions behind them to ensure agents remain accountable and compliant.
Learn more in the AI Agent Security Playbook.
