Employee-installed AI agents create visibility and control gaps because they can be launched through the GUI or terminal without formal approval. They may access data, connect to external models, or execute actions outside security oversight. That breaks the assumption that managed endpoints only run approved software, so teams need discovery, policy enforcement, and audit trails to govern the actual runtime behavior.
Why This Matters for Security Teams
Employee-installed AI agents complicate endpoint security because they collapse the old boundary between “approved software” and “user-driven capability.” A laptop that looks compliant at install time may still be executing autonomous workflows, sending prompts to external models, reading local files, or chaining tools in ways that never pass through traditional software request, packaging, or change-control processes. That makes standard endpoint assumptions weaker: inventory alone does not show intent, and allowlisting alone does not explain runtime behavior.
Current guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to the same operational reality: agentic systems need runtime governance, not just deployment-time approval. NHIMG research also shows why this is not theoretical. In AI Agents: The New Attack Surface, SailPoint reports that 80% of organisations say their AI agents have already performed actions beyond intended scope. In practice, many security teams encounter this only after an agent has already accessed data or external services that no one expected it to touch.
How It Works in Practice
Effective endpoint security for employee-installed agents starts with discovery, then moves to policy enforcement and auditability. Security teams should treat the agent as a workload with its own identity and permissions, not as a normal desktop app. That means identifying what launched the agent, what models it can reach, what local and cloud resources it can access, and which tokens or credentials it inherits from the user session.
Several controls matter most:
- Application discovery that flags agent runtimes, plugin hosts, browser extensions, and local automation frameworks.
- Prompt, tool, and network telemetry so the endpoint can show what the agent tried to do, not just that it existed.
- Policy-as-code for runtime decisions, so access can be restricted by context instead of fixed install-time labels.
- Short-lived secrets and just-in-time access, because long-lived credentials turn a temporary task into a persistent endpoint risk.
- Separate workload identity for agents, aligned to patterns such as SPIFFE or OIDC, so the system can verify what the agent is and what task it is performing.
This is where endpoint governance intersects with broader NHI practice. NHIMG’s The State of Non-Human Identity Security highlights that weak rotation, poor logging, and over-privileged accounts are major causes of NHI incidents, which maps directly to agent-installed tooling that quietly inherits too much power. For a concrete attacker lens, see the CoPhish OAuth Token Theft via Copilot Studio analysis and Replit AI Tool Database Deletion, which show how tool access can become real operational impact.
These controls tend to break down in BYOD-heavy environments where users can install agents outside managed software channels and where endpoint agents cannot reliably observe cloud-side tool calls.
Common Variations and Edge Cases
Tighter control over employee-installed agents often increases user friction and support overhead, so organisations must balance productivity gains against the risk of unsanctioned automation. There is no universal standard for how much autonomy an endpoint agent should have yet, and current guidance suggests using different policy tiers for low-risk drafting assistants, code assistants, and agents with write or execute privileges.
One common edge case is shadow AI inside legitimate productivity workflows. A browser-based assistant may look harmless, but it can still read mail, issue API calls, or move data into an external model. Another is local developer tooling, where a trusted terminal agent inherits broad file and network access and behaves more like a privileged automation service than a user app. In these cases, endpoint EDR alone is not enough; teams need governance that spans identity, network, and data controls.
Practitioners should also watch for situations where the agent is installed by the employee but authenticated with enterprise SSO. That creates a false sense of control, because the identity is managed while the runtime behavior remains unconstrained. The OWASP NHI Top 10 and CSA MAESTRO agentic AI threat modeling framework both reinforce the need to distinguish human approval from machine execution. Current best practice is evolving toward runtime authorization, but many endpoint programs still assume that a signed-in user equals a safe action, which is exactly where agentic abuse starts.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic apps need runtime controls when installed agents act beyond intended scope. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Employee agents often rely on long-lived secrets and weak rotation. |
| CSA MAESTRO | TR-2 | MAESTRO addresses autonomous agent threat modeling and control gaps. |
| NIST AI RMF | AI RMF helps govern unpredictable agent behavior and accountability. | |
| NIST CSF 2.0 | PR.AC-4 | Endpoint agents need least-privilege access aligned to their actual tasks. |
Replace static agent credentials with short-lived secrets and automate revocation after task completion.
