Month: September 2026

Logging in proves who you are. It says nothing about what you should be allowed to do next. 

Picture this. Priya works in finance. She signs in to her company laptop in the morning, approves the MFA prompt on her phone, and connects to the VPN. Every check passes. Her identity is verified, her device is managed, and she’s allowed on the network. 

At 10:40 she opens an email with an invoice attached. It isn’t an invoice. The file quietly runs a piece of malware, and because Priya’s account has local admin rights (IT gave them to her two years ago so she could install a printer driver), the malware has them too. Within minutes it has switched off the antivirus, pulled saved passwords out of memory, and started looking for other machines to reach. 

Nothing in that story broke the company’s Zero Trust controls. The login was genuine. The trouble started after it.

Where most Zero Trust programs stop 

Most Zero Trust work focuses on the front door. Is this the right person? Did they pass MFA? Is the device one we know? Those checks matter, but they happen once, at login. After that, whatever the user is allowed to do on the laptop tends to go unquestioned. 

NIST’s Zero Trust architecture (SP 800-207) asks for more. It says access should be granted per session, decided by policy, and limited to the least privilege needed for the task. That principle doesn’t stop at the network. It applies on the laptop too, every time someone tries to do something that needs admin rights. 

Why admin rights on laptops are such a big deal 

Attackers usually get onto a laptop in one of two ways: a stolen password or a software flaw. According to the 2026 Verizon Data Breach Investigations Report, exploited vulnerabilities (31% of breaches) have now overtaken stolen credentials as the most common way in. 

Either way, the attacker ends up with whatever rights the user has. With admin rights, the usual next steps in an attack, like dumping passwords, disabling security tools, or installing a backdoor, become easy. Without them, many of those steps simply fail.

And this is far from rare. When NSA and CISA listed the ten most common misconfigurations their teams find in large organizations, giving users more admin privilege than they need came second. 

There’s a timing benefit as well. The same Verizon report found that organizations now take a median of 43 days to patch known vulnerabilities. Removing unnecessary admin rights limits how much damage an unpatched flaw can do while you wait.

So why do so many users still have admin rights? 

Because taking them away hurts. The developer can’t install the tool she needs. The sales rep can’t update a plugin ten minutes before a client demo. The help desk drowns in tickets. So, companies leave admin rights in place “for now,” and “for now” lasts for years. 

This is the problem Endpoint Privilege Management (EPM) solves. Most users don’t need to be admins. They need to do a handful of specific admin tasks. EPM lets them do exactly those tasks without handing over the keys to the whole machine.

What this looks like day to day 

A developer installs Docker. His request is checked against policy: Docker is on the approved list, he’s in the engineering group, and his laptop is compliant. The installer runs with elevated rights, and when it finishes, the rights disappear. He never became an admin, and he didn’t wait on a ticket. 

An unknown file asks for admin rights. It isn’t on any approved list, so the request is blocked and the security team gets an alert. This is Priya’s story with a different ending. The malware still ran, but it couldn’t turn off the antivirus or grab passwords, because it never got admin rights. 

A contractor needs access for two weeks. He must configure software on three machines. He gets elevated rights for that job, on those machines, until the engagement ends, and every action is logged. That matters: Verizon’s latest report found third parties involved in 48% of breaches [2]. 

A help-desk engineer fixes a broken driver. Instead of being a permanent admin on every laptop in the company, she gets elevation for the approved support tools she uses, and each session is recorded. 

In each case, the question goes beyond “who is this?” It becomes: which app, on which device, for what task, and for how long?

Rolling it out without making enemies 

Pulling admin rights from everyone on a Monday morning is the quickest way to kill an EPM project. A few things work much better: 

• Watch before you block. Run EPM in monitoring mode for a few weeks to see what really needs admin rights. 
• Remove rights in waves. Build rules from what you learned, then start with low-risk teams and expand. 
• Make asking easy. If getting elevation takes a day, people will find workarounds. 

Where ARCON EPM fits 

ARCON Endpoint Privilege Management is built for exactly these situations. It manages Windows, macOS, and Linux endpoints from one console [5] and gives security teams: 

• Just-in-time elevation that expires on its own once the task or time window ends 
• Application control, with allow and block lists based on each app’s risk 
• Request and approval workflows that work even when users are off the corporate network 
• Vaulting and automatic rotation of local admin passwords 
• Audit trails and behaviour analytics that flag unusual activity 
• Integration with ARCON Privilege Account Management, so endpoint privileges are managed alongside servers, databases, and cloud accounts 

One more reason these matters: AI 

AI agents are starting to run on employee laptops, reading files, running scripts, and installing packages on the user’s behalf. They do it with the user’s permissions. If the user is an admin, so is the agent, and it moves far faster than any person would. Verizon also found that employee use of unapproved AI tools has tripled, to 45% [2]. Checking each privileged action, rather than trusting the whole session, is the only approach that keeps pace. 

The bottom line

Priya’s login was fine. What went wrong was everything her account was allowed to do afterward. Zero Trust is meant to remove assumptions, and “this person signed in, so they can do anything on this laptop” is one of the biggest ones left. That’s why Zero Trust can’t stop at login. It must carry on to the endpoint, where the real work happens.

References

• NIST, Special Publication 800-207: Zero Trust Architecture. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
• Verizon, 2026 Data Breach Investigations Report. https://www.verizon.com/about/news/breach-industry-wide-dbir-finds
• MITRE ATT&CK, OS Credential Dumping (T1003) and Impair Defenses (T1562). https://attack.mitre.org/techniques/T1003/
• NSA and CISA, Joint Advisory AA23-278A: Top Ten Cybersecurity Misconfigurations. https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-278a
• ARCON, Endpoint Privilege Management. https://arconnet.com/endpoint-privilege-management/

Part 3 of 3 in ARCON’s Endpoint Privilege series. Written for CISOs, platform engineers and compliance leaders.

Executive takeaway

Most enterprise privilege programmes distinguish between human users and conventional non-human identities such as service accounts.

AI agents require a third operational category.

They are still non-human identities from an access-control perspective, but they behave differently from traditional service accounts. An agent can interpret a goal, select tools, process untrusted content, chain actions and interact with multiple systems on a user’s behalf.

That changes the privilege question.

It is no longer enough to ask: Which account is running this process?

Security teams must also ask: Which human initiated the agent, what objective was it given, which tools may it invoke, what authority may it inherit, and which actions require a human decision before execution?

The answer should not be a new permanent “AI administrator” role. It should be a privilege model based on dedicated identities, standard-user operation, task-scope access, just-in-time elevation, human approval for high-impact actions and complete attribution.

Key takeaways

• A 2026 Palo Alto Networks survey of 2,930 security and IT leaders reported an average of 109 machine identities for every human identity, with respondents expecting AI-agent populations to grow by 85% over the following twelve months. These are survey findings rather than universal industry measurements, but they illustrate the scale of the governance challenge.
• Microsoft has introduced experimental Windows agentic-security controls that use a separate standard account and contain agent workspace. These capabilities are in preview, off by default and should not be described as universally deployed production functionality.
• Microsoft also identifies cross-prompt injections as a risk through which malicious content in documents or user-interface elements can redirect an agent towards unintended actions. Privilege determines how damaging those actions can become.
• OWASP and the Cloud Security Alliance recommend controls that already resemble mature EPM, PAM and identity-governance practices: narrowly scoped credentials, minimum permissions, isolated execution, human approval for consequential actions and traceability to a responsible human.
• Existing frameworks already provide a control foundation for non-human identities. However, applying PCI DSS, DORA, NIS2, CIS, NIST, SEBI or India’s DPDP Rules to a particular AI-agent implementation requires a scope and applicability assessment; the label “AI agent” does not create automatic compliance.
  EPM cannot prevent every prompt-injection or model-level failure. It can restrict what an affected agent is authorised to execute, install, modify or elevate on an endpoint.

The new problem is not machine identity. It is machine agency.

Machine identities are not new. Enterprises have long operated:

• application accounts.
• service accounts.
• scheduled task identities.
• robotic-process-automation bots.
• CI/CD runners.
• API clients.
• workload identities.
• device identities; and
• integration accounts.

Traditional non-human identities usually execute predetermined instructions. Their behaviour may be complex, but the path is generally designed in advance: retrieve a file, move data, run a job, start a service or call a defined API.

An agentic identity is different. It may receive an outcome rather than a fixed instruction. To achieve that outcome, it may:

• interpret contextual information.
• choose among available tools.
• formulate intermediate tasks.
• retrieve additional data.
• invoke other services.
• respond to changing results.
• delegate work to another agent; or
• decide which action to perform next.

The Cloud Security Alliance describes agent identities as a distinct class of non-human identity because agents can reason, plan and execute under delegated authority. It also distinguishes the identity itself from the token, key or credential used by that identity.

That distinction is fundamental.

A credential answers: How is the agent authenticating?

An identity-and-privilege model must answer: What is the agent, who is responsible for it, what may it do, for which task, through which tools and for how long?

Three operational classes of principal

AI agents do not need to become a completely new category in every identity standard. They do, however, need a separate operational policy because their authority is exercised differently.

Principal type	Typical operating model	Distinctive privilege risk	Required governance response
Human user	Interactively makes decisions and performs actions	Credential theft, excessive privilege, social engineering and misuse	Strong authentication, role-based access, EPM, PAM, approvals and user accountability
Service or application identity	Performs a defined, repeatable workload	Standing credentials, excessive permissions, poor ownership and weak rotation	Identity inventory, named owner, scoped access, secret rotation, workload isolation and periodic review
Agentic identity	Interprets goals, selects tools and takes contextual actions	Prompt injection, excessive agency, tool-chain abuse, delegated privilege and unclear attribution	Dedicated agent identity, human sponsor, task-scoped credentials, tool-level controls, just-in-time elevation, action approval and complete traceability

 

The third row is not a marketing category. It is a practical requirement. Treating an agent exactly like a human ignores its ability to operate continuously and at machine speed. Treating it exactly like a conventional service account ignores its ability to interpret untrusted content and dynamically choose actions.

Scale is arriving before governance

The 109-to-one machine-identity ratio is striking, but the more important findings concern control maturity.

The same Palo Alto Networks research reported that only 37% of surveyed organisations could revoke an AI agent’s credentials and only 30% had immutable audit logging for agent activity. Those numbers should be read as survey results, not as an audited global benchmark, but they expose the operational gap: organisations are introducing agents faster than they are building the ability to identify, constrain, monitor and terminate them.

For a CISO, this creates four immediate questions:

• Can the organisation enumerate every agent that can act on an endpoint or enterprise system?
• Does every agent have a named business owner and technical owner?
• Can its access be revoked without disabling the human user or shared application account?
• Can every privileged action be traced to the agent, the initiating human, the approved task and the credential used?

An organisation that cannot answer those questions does not yet have agent identity governance. It has software operating with inherited trust.

Microsoft made the issue concrete—but the status must be described accurately

Microsoft’s Windows documentation describes an experimental agentic-security model in which an agent operates through a separate standard account inside a contained agent workspace.

The design is significant because it establishes three useful principles:

• The agent should have an identity separate from the human user.
• The agent should begin with limited permissions.
• The agent should receive access only to resources explicitly made available to it.

Microsoft also states that the agent should not operate with permissions higher than those of the initiating user.

However, this should not be presented as a universally deployed Windows production feature.

Microsoft’s current documentation characterizes the relevant capabilities as experimental or preview functionality. They are off by default, require an administrator to enable them and once enabled, may apply across users of the device. Some preview experiences are available through Windows Insider builds.

That qualification does not weaken the argument. It strengthens it.

The operating-system vendor is signalling the architecture that agentic endpoints require before these capabilities become routine:

• separate agent identities.
• standard-user operation by default.
• contained workspaces.
• granular resource permissions; and
• explicit administrative control over enablement.

Security teams should adopt those principles now, rather than waiting for broad operating system deployment.

The device-level decision must precede user adoption

If an administrator must enable agentic functionality and the setting then affects the device more broadly, enablement is not an individual productivity preference.

It is an endpoint-security decision.

Before allowing agentic capabilities, organizations should define:

• which device populations may run agents.
• which users may initiate them.
• which agent frameworks are approved.
• which local and remote tools may be called.
• which folders and data stores are accessible.
• whether network access is permitted.
• which credentials may be requested.
• which privileged actions are prohibited.
• which actions require approval; and
• how the agent and its account are removed.

The control should be established before a user, developer or business team independently connects an agent to corporate data and administrative tools.

Cross-prompt injection turns content into an authorization input

Microsoft describes cross-prompt injections as a risk in which hostile content embedded in documents or interface elements can override or redirect an agent’s instructions, potentially causing unintended actions such as data exfiltration or malware installation.

This is not merely another form of phishing.

A phishing message attempts to persuade a human to act.

A prompt-injection payload may attempt to influence software that already has permission to act.

Consider an agent authorised to:

• read a document.
• access a project folder.
• send email.
• execute a local script.
• retrieve a privileged credential.
• install a package; or
• modify a configuration.

If untrusted content can redirect that agent, its existing permissions become part of the attack surface.

The security problem can be expressed as:

Agent risk = reachable data × available tools × delegated privilege × permitted autonomy × time to revoke

Reducing any one factor reduces exposure. Reducing standing privilege changes the entire equation.

EPM does not determine whether a sentence inside a document is malicious. It determines whether the process acting on that sentence can elevate, execute a restricted command, launch an installer, modify a protected resource or use administrative authority.

Privilege limits blast radius; it does not solve prompt injection

It is important not to oversee endpoint privilege management.

EPM cannot, by itself:

• validate the correctness of an agent’s reasoning.
• identify every malicious instruction in a document.
• prevent every model-manipulation technique.
• determine whether a business decision is commercially appropriate.
• correct unsafe application logic; or
• guarantee that an approved tool cannot be misused.

It can:

• keep the agent out of local administrator groups.
• prevent unapproved elevation.
• restrict executable, script and process behaviour.
• limit access to protected files and configurations.
• require approval for privileged actions.
• provide temporary authority rather than standing authority.
• record the identity, action, approved and outcome; and
• revoke access after the authorised task.

That makes EPM a blast-radius and authorisation control—not a model-security substitute.

OWASP already treats agent privilege as a primary risk

OWASP’s Top 10 for Agentic Applications 2026 includes ASI03: Identity and Privilege Abuse.

The risk concerns manipulation of delegation, inherited roles, trust relationships, agent context and control flows to obtain authority beyond the intended scope. OWASP’s broader guidance on excessive agency also warns against giving an agent more functionality, permission or autonomy than its legitimate task requires.

The recommended control direction is familiar:

• short-lived credentials.
• narrowly scoped tokens.
• permission boundaries.
• minimum functionality.
• minimum autonomy.
• human confirmation for high-impact actions; and
• separation between the agent’s reasoning layer and the tools that can perform consequential operations.

These are not entirely new security concepts. They are least privilege, just-in-time access, separation of duties and transaction approval applied to agentic software.

An agent should not directly own unrestricted tools

The model or reasoning component should not be the final enforcement point.

A safer design separates:

• Intent generation: The agent proposes an action.
• Policy evaluation: A deterministic control checks identity, device, task, tool, target, risk and approval requirements.
• Credential issuance: A short-lived credential or elevation grant is issued only when policy permits.
• Execution: The approved tool performs the bounded action.
• Evidence: The action, inputs, identity, approval and result are recorded.
• Revocation: The privilege expires or is withdrawn immediately after use.

This separation is important because a probabilistic model should not be the sole decision-maker for access to deterministic administrative functions.

The model may request an action.

The control plane should decide whether the action is permitted.

MCP servers and local tools expand the endpoint privilege surface

Model Context Protocol servers and similar tool interfaces can give an agent access to local files, source-code repositories, command shells, databases, business applications and external services.

When such a server runs on a developer or administrator workstation, it should be treated as a privileged application boundary—not merely as an AI integration.

The Cloud Security Alliance recommends that MCP servers operate with the minimum permissions required for their documented tool set. Its guidance also supports isolated execution environments, per-invocation authorisation, just-in-time permission elevation and filesystem or network access that is blocked by default and enabled only where necessary.

For each local agent tool or MCP server, security teams should identify:

• the operating-system account under which it runs.
• whether the account is human, shared, service-based or agent-specific.
• its file system permissions.
• its network destinations.
• its available commands.
• the credentials it can request.
• whether it can spawn child processes.
• whether it can install software.
• whether it can modify protected settings; and
• how quickly it can be disabled.

Description of a tool is not a security boundary. The operating system permissions, credential scope and enforcement policy are the boundaries.

Do not let the agent inherit the user’s entire session

The fastest way to deploy an enterprise agent is often to let it operate inside the user’s existing session.

It is also one of the riskiest.

Session inheritance may give the agent access to:

• browser cookies.
• active SaaS sessions.
• mapped drives.
• collaboration platforms.
• local source code.
• cached credentials.
• cloud command-line sessions.
• user-accessible personal data; and
• applications that trust the logged-in user.

A better model provides the agent with a distinct identity and only the resources required for the task.

Where separate identity is not technically possible, organisations should introduce compensating controls such as:
isolated runtime environments.

• restricted folders.
• brokered tool access.
• network filtering.
• explicit user confirmation.
• short execution windows; and
• enhanced activity logging.

The objective is to avoid turning the user’s entire authenticated session into the agent’s implicit permission set.

ATTACK coverage is developing, but the underlying behaviours are already mappable

ATTACK v19 added AI-related Enterprise techniques including T1682 Query Public AI Services and T1683 Generate Content. These techniques address adversary use of AI services and generated material.

As of ATTACK v19, there is no Enterprise technique specifically named for abuse of an organisation’s AI-agent identity or delegated endpoint privileges.

That should be treated as a taxonomy observation, not as a claim that ATT&CK cannot represent the activity.

The underlying behaviours may still map to existing techniques involving:

• valid accounts.
• credential access.
• abuse of elevation-control mechanisms.
• command and scripting interpreters.
• application-layer protocols.
• account manipulation.
• process execution.
• data collection.
• exfiltration; and
• impact.

Security teams should not wait for a dedicated “agent privilege abuse” identifier before creating controls.

The threat model exists even when the taxonomy is still evolving.

Existing governance rules already provide a starting point

The claim that organisations must wait for new AI-specific regulation before governing agents is incorrect.

Existing rules already address:

• least privilege.
• access by system and application accounts.
• privileged access review.
• separation of duties.
• dedicated administrative identities.
• service-account inventories.
• restricted software execution.
• confined environments.
• logging and monitoring; and
• automated privilege management.

However, the opposite overstatement should also be avoided.

An AI agent is not automatically an “application account,” “service account” or regulated privileged identity merely because a blog labels it one. Applicability depends on how the agent is implemented, which systems and data it accesses, and which legal or regulatory scope applies to the organisation.

The correct approach is to map the agent’s actual identity, credentials, privileges and actions to the applicable control requirements.

Framework-to-agent control mapping

Framework or standard	Existing control basis	Practical implication for agentic endpoints
DORA RTS – Delegated Regulation (EU) 2024/1774, Article 21	Need-to-know, need-to-use and least-privilege access; restriction of generic and shared accounts; privileged access on a need-to-use or ad-hoc basis; periodic access review; automated privilege-access management where feasible and appropriate	Financial entities should avoid permanent agent privilege, use distinct identities where possible and broker elevated authority through controlled, reviewable workflows
NIS2 Implementing Regulation (EU) 2024/2690, Annex 11	Access-control policies must address access by people and by network and information systems; system-administration privileges must be restricted and managed	Agents and their runtime systems should be included in access-control policies rather than treated only as user productivity software
PCI DSS v4.0.1, Requirements 7.2.5 and 7.2.5.1	Governance of application and system accounts, least privilege and periodic review	Where an agent uses an application or system account within the cardholder-data environment, its privileges and review cycle should be explicitly mapped

CIS Controls v8.1, Safeguard 5.5	Inventory and review of service accounts, including owner and purpose	Agent runtime accounts that function as service or application accounts belong in the inventory; other agents should receive an equivalent registry rather than remaining invisible
NIST CSF 2.0, PR.AA-05	Permissions and entitlements are defined, managed, enforced and reviewed using least privilege and separation of duties	Agent entitlements should be documented, enforced and periodically challenged rather than inherited indefinitely from a user
NIST SP 800-53 Rev. 5, CM-7(6)	Execution of software in confined environments with limited privileges	Agent runtimes and tools should be isolated and restricted to the minimum operating-system authority required
SEBI CSCRF	Privileged-access governance, PIM/PAM controls and access-review expectations for applicable regulated entities	Agent access to in-scope systems should be brought into the applicable entity’s privileged-access and maker-checker model, with the latest SEBI clarifications considered
India’s DPDP Rules, 2025	Security safeguards, control over access to computer resources, and logging, monitoring and review obligations	Where an agent handles personal data, organisations should restrict its access and retain evidence of how the data and supporting systems were accessed

 

DORA is particularly explicit: Article 21 requires need-based access, stronger governance of privileged accounts, periodic review and, where feasible and appropriate, automated privilege-access-management solutions. It should be described as unusually direct—not as the only major instrument containing a relevant automation requirement.

The NIS2 implementing regulation expressly extends access-control policy beyond human users to access by network and information systems. CIS and NIST provide additional control foundations through service-account inventory, least-privilege entitlements and confined execution.

PCI SSC identifies PCI DSS v4.0.1 as the current standard version. SEBI’s 2024 CSCRF should be read together with subsequent clarifications, while India’s DPDP Rules were notified in November 2025 with an official implementation framework. Exact applicability should be verified against the organisation’s sector, entity classification, system scope and effective dates.

Existing controls are necessary—but not sufficient

Existing identity and privilege controls provide the foundation, but they do not answer every agent-specific design question.

For example:

• Who is accountable when an agent acts for several users?
• Does the agent retain access after the initiating user’s task ends?
• Can it delegate access to another agent or tool?
• Can a malicious document influence the agent’s next action?
• Can the agent combine individually permitted actions into a prohibited outcome?
• Does its memory retain data or credentials beyond the task?
• Can it alter its own tools, configuration or policy?
• Can investigators reconstruct the sequence from human request to agent decision to tool execution?
• Can the agent be disabled without disrupting unrelated users or workloads?

These are not reasons to discard existing frameworks. They are reasons to extend existing access-governance practices with an agent-specific operating model.

Eight controls every enterprise agent should inherit

1. A named human sponsor

Every agent should have an accountable business owner and technical owner. The business owner should approve of the purpose and acceptable actions. The technical owner should maintain its runtime, tools, permissions and decommissioning process.

An agent without an owner is an orphaned privileged identity waiting to happen.

2. A dedicated identity

Where the platform permits it, each production agent should receive a distinct identity rather than using:

• a shared user account.
• a developer’s personal token.
• a generic service account.
• a permanent administrator credential; or
• an embedded API key.

The identity should be attributable to a specific agent instance or governed agent class.

3. A standard-user baseline

An agent should begin without local administrator or root authority. Its default operating context should be a standard user or restricted workload identity. Do not create a broad “AI Admins” group as a shortcut.

4. Task-scoped, short-lived authority

Access should be issued for a defined task, target and period. Where elevated authority is required, it should be:

• just in time.
• limited to the approved executable, command or workflow.
• tied to the agent identity and initiating human.
• automatically revoked; and
• prevented from flowing to unrelated child processes.

5. A deterministic policy layer between the agent and its tools

The agent should not decide on its own effective permissions. A policy-enforcement layer should be evaluated:

• agent identity
• human sponsor
• device
• tool
• target system
• requested action
• file or command
• data classification
• business purpose
• approval status; and
• risk level

Only then should the tool receive authority to execute.

6. Human approval for consequential actions

OWASP guidance supports explicit human involvement for high-impact or irreversible actions.

Examples include:

• deleting data.
• sending information externally.
• publishing content.
• making a payment.
• changing access rights.
• retrieving privileged credentials.
• installing software.
• executing an administrator command.
• modifying endpoint-security settings.
• rotating or disabling credentials.
• wiping a device; and
• deploying a script across a fleet.

The approval screen should state the actual consequence, not merely ask whether the user wants to “continue.”

7. Isolation and deny-by-default access

Agent runtimes should be isolated from unnecessary:

• filesystem locations.
• network destinations.
• command interpreters.
• credentials.
• devices.
• APIs.
• libraries; and
• user sessions.

Access should be granted to the specific resource required—not to an entire drive, profile or environment.

8. Complete evidence and rapid revocation

The organisation should be able to produce:

• the agent’s identity.
• its owner.
• the initiating human.
• the original task.
• tools invoked.
• credentials issued.
• elevation requests.
• approvals.
• commands executed.
• systems and data accessed.
• output generated.
• policy exceptions.
• start and expiry times; and
• result.

It should also be possible to revoke the agent’s credentials, disable its tools and terminate its runtime quickly. Logging without revocation is observation. Revocation without attribution is operational containment. A mature programme requires both.

Classify agent actions by consequence

Not every action needs the same level of friction.

Action class	Examples	Recommended default
Read-only, low risk	Search an approved knowledge base, read a permitted project file, query non-sensitive inventory	Standard-user context, scoped access and complete logging
Reversible business change	Update a draft, create a ticket, change a non-critical record	Bounded permissions, policy validation and traceable rollback
Privileged technical action	Install approved software, run an administrative command, modify a protected configuration	Just-in-time elevation, strong identity verification and task-specific approval
External or irreversible action	Send sensitive information, publish content, delete records, make payment or rotate credentials	Explicit human confirmation and separation of duties where appropriate
Security-management action	Disable EDR, deploy scripts, change access policy, alter endpoint-management settings or wipe devices	Dedicated administrative workflow, multi-person approval and no autonomous execution by default

 

This model allows low-risk automation without giving an agent unrestricted authority over high-impact outcomes.

Do not confuse continuous operation with permanent privilege

Agents may need to operate continuously. Their privileged access does not need to be continuous. A long-running agent can remain active while requesting temporary authority for individual operations. The identity persists; the elevated permission does not.

This distinction is central to agent security: Availability may be continuous. Privilege should remain event based.

What to do in the next ninety days

Days 1–30: Discover and classify

Create an enterprise inventory of non-human actors operating on or through endpoints.

Include:

• service accounts.
• application accounts.
• scheduled tasks.
• RPA bots.
• CI/CD runners.
• MCP servers.
• browser and desktop agents.
• IDE coding agents.
• operating-system agents.
• support automation.
• security automation; and
• custom internal agents.

For each entry, record:

• business owner.
• technical owner.
• human sponsor.
• agent or application name.
• runtime and device.
• operating-system identity.
• authentication method.
• credentials and secrets.
• available tools.
• accessible folders.
• network destinations.
• target systems.
• data classifications.
• standing privileges.
• ability to delegate.
• approval requirements.
• review date.
• expiry date; and
• revocation mechanism.

Do not begin by asking only which “AI tools” the organization has purchased. Begin by asking which non-human processes can take actions on behalf of a person or business function.

Days 31–60: Apply controls to a representative pilot

Select a pilot that includes:

• at least one Windows, Linux or macOS engineering use case.
• an agent that reads untrusted content.
• an agent that invokes local tools.
• an agent that accesses an enterprise application.
• a remote or intermittently connected endpoint; and
• at least one action that genuinely requires elevation.

Apply the following baseline:

• dedicated agent identity.
• named human sponsor.
• no standing local administrator rights.
• isolated runtime.
• short-lived credentials.
• application and command controls.
• restricted filesystem and network access.
• human approval for high-impact actions.
• automatic privilege expiry.
• complete audit trails; and
• an operational kill switch.

Test the policy against real workflows rather than a scripted demonstration.

Days 61–90: Prove containment and scale

Red team the pilot.

Test whether:

• Malicious content can redirect the agent.
• An agent can invoke an unapproved tool.
• A permitted parent process can launch an unrestricted child process.
• credentials remain usable after the task.
• access persists after the human sponsor leaves.
• a shared token obscures attribution.
• The agent can access an unauthorized folder or service.
• high-impact actions are executed without approval.
• the kill switch terminates access; and
• investigators can reconstruct the complete chain of activity.

Use the results to refine policy before expanding the deployment.

Metrics that survive executive scrutiny

Report security and operational outcomes together.

Identity-governance measures

• Percentage of known agents with a named business owner.
• Percentage with a named technical owner.
• Percentage using a dedicated identity.
• Number of agents using shared human or service credentials.
• Number of orphaned agent identities.
• Median age of agent identities without recertification.

Privileged measures

• Percentage of agents operating without standing administrator or root access.
• Percentage of privileged agent actions broke through EPM or PAM.
• Percentage of credentials that are short-lived and task scoped.
• Number of agent privilege exceptions and their median age.
• Number of agents capable of changing their own security configuration.
• Percentage of privileged grants automatically revoked after use.

Action-governance measures

• Percentage of irreversible actions requiring human approval.
• Percentage of high-impact actions subject to separation of duties.
• Number of denied or escalated agent requests.
• Percentage of tool invocations linked to the initiating human and approved task.
• Number of actions executed outside the intended tool or target scope.

Resilience measures

• Median time to revoke an agent’s credentials.
• Median time to disable an agent runtime.
• Percentage of agent actions covered by immutable or protected audit records.
• Percentage of agents with a tested kill switch.
• Cross-platform policy coverage across Windows, Linux and macOS.

The objective is not to reduce all agent activity. The objective is to make every consequential action attributable, authorised, limited and revocable.

How ARCON fits the agent-privilege architecture

ARCON documents its Endpoint Privilege Management platform as providing centralised governance across Windows, Linux and macOS.

Its documented capabilities include:

• just-in-time privilege elevation.
• Privileged Elevation and Delegation Management.
• application allowlisting and blocklisting.
• Online and offline elevation workflows.
• File Integrity Monitoring.
• reporting and audit trails.
• behavioural analytics; and
• integration with ARCON | Privileged Access Management.

These capabilities address the endpoint-authority layer of an agentic architecture:

• whether an agent-associated process may elevate.
• which application, command or script may run.
• whether protected files or configurations may be modified.
• how long elevated authority remains available.
• who approved it; and
• what evidence is retained.

ARCON | Privileged Access Management can provide the privileged-account, credential and session-governance layer, while ARCON | Converged Identity can provide broader identity and entitlement context.

The combined architecture should be understood as three related control planes:

ARCON control plane	Role in agent governance
ARCON	Converged Identity
ARCON	Privileged Access Management
ARCON	Endpoint Privilege Management

 

The proof point is not whether a product description contains the phrase “AI agent.”

The proof point is whether the architecture can:

• recognise the identity acting through the agent.
• trace it to a responsible human and business purpose.
• prevent standing endpoint privilege.
• issue temporary authority for a defined task.
• constrain the application, process or command using that authority.
• require approval for consequential actions.
• revoke access automatically; and
• preserve defensible evidence.

Specific agent frameworks, MCP servers and operating-system agent accounts should be validated through proof of value rather than assumed to be governed automatically.

Questions for the architecture review

Before approving an enterprise agent deployment, ask:

• Does every agent have a dedicated identity or is it borrowing a user or shared service account?
• Who is the accountable human sponsor?
• What is the agent’s default operating-system privilege level?
• Can it obtain administrator or root authority?
• Is privileged access standing or issued per task?
• Which tools, scripts and commands may it invoke?
• Can approved tools spawn unrestricted child processes?
• Which folders, data stores and network destinations are accessible?
• Can it retrieve credentials directly?
• Can it delegate access to another agent or service?
• Which actions require human approval?
• Which actions require two-person approval?
• Can hostile content alter the agent’s intended behaviour?
• Can the agent modify its own runtime, policy or tools?
• How are privileges revoked after the task?
• What happens when its owner change’s role or leaves?
• Can the complete chain from human request to agent action be reconstructed?
• How quickly can the identity, credentials and runtime be disabled?

An architecture that cannot answer these questions should not grant the agent production privilege.

The executive decision

AI agents should not enter the enterprise as invisible administrators.

They should enter as governed principals with:

• a named owner.
• a distinct identity.
• a standard-user baseline.
• tightly scoped tools.
• task-specific credentials.
• just-in-time privilege.
• human approval for consequential actions.
• complete evidence; and
• immediate revocation.

The new security question is not whether an agent can complete a task.

It is whether the organisation can prove that the agent completed the right task, through the right tool, with the right authority, for the right period and under the responsibility of the right human.

That is the standard an agent-ready endpoint privilege architecture should meet.

 

Part 2 of 3 in ARCON’s Endpoint Privilege series. A practical architecture guide for security architects and endpoint engineering teams.

Key takeaways

• Removing standing local administrator rights does not stop every endpoint attack. It removes the attacker’s direct path to high-impact operations such as creating system services, loading drivers, accessing protected processes and tampering with security controls.
• Standard-user execution and administrator-level execution are not the same problem. An attacker may still run PowerShell, native utilities or malicious code as a standard user, but cannot automatically perform every privileged action.
• A LOLBAS entry marked “Privileges required: User” means that the technique can begin from a non-elevated process. It does not necessarily mean that a genuine standard account can create an administrator token.
• Windows UAC, macOS Transparency, Consent and Control, and Linux sudo, setuid, capabilities and polkit are different privilege systems. A cross-platform EPM programme must govern each one according to its native security model.
• EPM must be paired with patching, application and library control, vulnerable-driver protection, file permissions and EDR. Least privilege is a control layer, not a complete endpoint-security stack.
• Before removing administrator rights, collect real elevation data, classify legitimate use cases and test rules against a representative business cycle.

Start with the outcome, not the slogan

“Administrator rights are dangerous” is correct, but it is not specific enough to guide an endpoint architecture.
The more useful question is:

Which attacker objectives become materially easier when the compromised user already holds administrative authority?

Removing standing administrator rights does not make the endpoint invulnerable. It changes the attacker’s starting position.

Instead of immediately inheriting authority to alter protected system resources, the attacker must find another route: steal privileged credentials, exploit a local vulnerability, abuse a misconfiguration, manipulate an approved elevation rule or persuade a user or support operator to approve elevation.

That additional step matters. It creates opportunities to prevent the action, restrict its scope, require stronger identity assurance and generate evidence for investigation.

The privileged outcomes least privilege is designed to constrain

Several common adversary objectives depend on elevated operating-system authority.

Adversary objective	ATTACK reference	Why privilege matters
Create or modify a Windows service	T1543.003	Services may be created with administrator privileges and then execute as SYSTEM. Attackers use them for persistence, privilege escalation and driver loading.
Dump credentials from LSASS	T1003.001	Accessing LSASS memory requires access to a highly protected process. Administrative or SYSTEM-level access substantially expands an attacker’s ability to obtain credential material.
Manipulate access tokens	T1134	Full use of several token-manipulation techniques generally requires administrative privileges or sensitive user rights. MITRE recommends privileged account and user-account management as key mitigations.
Disable security services or modify their configuration	T1685	Stopping services, changing protected registry locations, modifying security-tool files and loading drivers usually requires elevated authority.
Disable or clear Windows event logs	T1685.001 and T1685.005	MITRE’s detection guidance associates’ event-log clearing with an adversary first obtaining elevated privileges.
Install or load a service driver	T1543.003	Registering and loading a Windows service driver is an administrative operation and may allow code to execute in kernel context.

 

MITRE states that Windows services may be created with administrator privileges and subsequently executed under SYSTEM. Its current mappings also recommend restricting user privileges so that only authorised administrators can interact with service configurations.

MITRE’s mappings for Access Token Manipulation similarly state that an adversary generally needs administrator-level access to make full use of several token-manipulation methods. The listed mitigations include Privileged Account Management and User Account Management.

The correct security claim is therefore not:

“Removing administrator rights eliminates privilege escalation.”

It is:

Removing standing administrator rights eliminates the direct use of administrator authority and forces the adversary to obtain, bypass or request elevation before performing privileged operations.

That is a narrower claim, but it is also more technically defensible.

The important distinction: user-level execution is not administrator-level execution

A standard user can still perform many actions that matter to an attacker.

Depending on endpoint configuration and application permissions, a compromised standard account may be able to:

• execute binaries and scripts.
• use PowerShell or another command interpreter.
• access files available to the compromised user.
• steal browser data or application tokens available in that user context.
• communicate with external infrastructure.
• modify user-writable registry keys and directories.
• establish user-level persistence; and
• use legitimate operating-system utilities.

Removing administrator rights does not make these capabilities disappear.

What it does is prevent the attacker from automatically converting ordinary user execution into unrestricted system administration.

That difference is especially important when discussing UAC bypasses and living-off-the-land binaries.

What “Privileges required: User” means in LOLBAS

The LOLBAS project documents legitimate Windows utilities that can be abused for execution, download, persistence, credential access, application-control bypass and other purposes.

For example, LOLBAS documents techniques involving ComputerDefaults.exe, Eventvwr.exe and odbcad32.exe that begin with a user-context process. Individual entries may therefore show “Privileges required: User.”

However, that field must be interpreted carefully.

Microsoft documents two different Windows sign-in models:

• A member of the local Administrators group receives a filtered standard-user token and a full administrator token.
• A genuine standard user does not possess that full administrator token and must provide valid administrator credentials when an administrative task is requested.

In other words, many classic UAC bypasses suppress or avoid the consent prompt for a user who already has an administrator token available. They do not magically create administrator authority for a true standard account that has no such token.

MITRE reflects this distinction directly. Its mitigation for T1548.002, Bypass User Account Control, includes:

Remove users from the local administrator group on systems.

MITRE also recommends maintaining UAC at its highest practical enforcement level and keeping Windows updated to reduce known bypass opportunities.

This changes the conclusion materially.

Removing local administrator membership does not stop living-off-the-land execution. But it can break a large class of UAC bypass paths that depend on the compromised user already possessing a full administrator token.

The resulting architecture principle is:

Use EPM to remove standing administrator authority, and use application, script and behaviour controls to govern what still runs at user level.

Privilege control and execution control solve different problems

Endpoint security programmes often treat least privilege and application control as substitutes. They are not.

Privilege control answers:

• Who may elevate?
• What may be elevated?
• Under which identity and device conditions?
• For how long?
• With whose approval?
• What happens to child processes?
• Is the elevated action automatically revoked and recorded?

Execution control answers:

• Which binaries, scripts and libraries may run?
• From which locations?
• Under which publisher, certificate, hash or version?
• Which command-line arguments are permitted?
• Can a process load an untrusted library?
• Can code execute from a user-writable location?

MITRE maps Privileged Account Management to techniques such as UAC bypass, token manipulation and certain process-injection scenarios. For T1685, Disable or Modify Tools separately lists controls including execution prevention, restricted file and directory permissions, restricted registry permissions, secure configuration and account management.

The architecture lesson is straightforward:

EPM determines when elevated authority is available. Application and library controls determine which code can use the endpoint, whether elevated or not.

Deploying one without the other leaves a predictable control gap.

Windows, macOS and Linux do not have the same privilege model

A cross-platform EPM programme cannot simply reproduce a Windows local-administrator policy on every operating system.

Windows: groups, split tokens, UAC and process elevation

On Windows, the main control points include:

• membership of local administrative groups.
• filtered and full access tokens.
• UAC policy.
• service and driver permissions.
• privileged user rights.
• executable and script elevation.
• child-process inheritance; and
• file, directory and registry permissions.

One subtle but important engineering concern is child-process handling.

Microsoft’s current Intune EPM documentation allows administrators to require a separate rule for child-process elevation, deny child processes or allow all child processes to inherit elevation. Microsoft warns that allowing all child processes to run elevated causes rule evaluation—including deny rules—to be skipped for those child processes.

That is not a minor configuration option. It is a potential elevation boundary.

Any EPM evaluation should therefore test whether an approved application can launch:

• cmd.exe.
• PowerShell.
• script interpreters.
• package managers.
• installers.
• debuggers.
• administrative consoles; or
• another general-purpose executable.

An elevation rule that appears narrow at the parent-process level can become broad if unrestricted child processes inherit the elevated context.

macOS: administrator status and TCC are separate controls

On macOS, local administrator membership is only one part of the access model.

Transparency, Consent and Control govern application access to privacy-sensitive resources such as the camera, microphone, screen recording and Full Disk Access. MITRE tracks TCC Manipulation separately as T1548.006. It also tracks setuid and setgid abuse under T1548.001.

This means a macOS programme must separately govern:

• local administrator membership.
• privileged execution.
• TCC and privacy permissions.
• MDM-delivered privacy preferences.
• sudo.
• setuid and setgid.
• launch agents and daemons.
• application signing and notarisation; and
• writable application and library paths.

Removing administrator status does not automatically revoke every privacy permission previously granted to an application. Conversely, granting an application with TCC permission does not necessarily make the user a local administrator.

The two controls must be designed and reviewed separately.

Linux: sudoers are only part of the surface

On Linux, the privilege surface includes:

• sudo and sudoers.
• password less rules.
• cached sudo authentication.
• setuid and setgid.
• Linux capabilities.
• polkit.
• service managers such as systemd.
• writable service and executable paths.
• kernel modules; and
• mandatory access controls such as SELinux or AppArmor.

MITRE’s T1548.003 guidance specifically addresses sudoers, password requirements and the timestamp_timeout setting.

The 2025 sudo vulnerability CVE-2025-32463 demonstrates why configuration control alone is insufficient. The flaw allowed a local attacker to abuse the –chroot option to execute arbitrary commands as root even when the attacker was not authorised for those commands in sudoers. The issue affected sudo from 1.9.14 through 1.9.17 and was fixed in 1.9.17p1. CISA added it to the Known Exploited Vulnerabilities Catalog on September 29, 2025.

The correct response is not to abandon sudo governance. It is to combine privilege policy with vulnerability management and operating-system hardening.

Cross-platform coverage is an architecture requirement

Microsoft currently documents Intune Endpoint Privilege Management as applying to Windows. Its elevation rules support .exe, .msi and .ps1 files, and Microsoft states that the capability requires additional EPM-specific licensing.

That does not make it an unsuitable product for every organisation. It means that organisations with material Linux or macOS estates must decide whether they will:

• operate separate endpoint-privilege tools and policy models.
• accept inconsistent privilege governance across platforms; or
• Select an EPM platform designed to manage Windows, Linux and macOS centrally.

The evaluation should not stop at a “supports macOS” or “supports Linux” checkbox. Architects should test which native control surfaces are governed on each platform.

Where least privilege alone stops helping

A credible EPM architecture must state clearly what EPM does not replace.

1. Local privilege-escalation vulnerabilities

CVE-2025-24990 affected the third-party Agere modem driver that shipped with supported Windows operating systems. The vulnerability involved an untrusted pointer deference and could allow a local attacker with low privileges to obtain elevated authority. Microsoft removed the affected ltmdm64.sys driver through October 2025 cumulative update, and CISA added the vulnerability to its KEV Catalog on October 14, 2025.
An elevation workflow cannot patch a vulnerable kernel driver.

The relevant controls include:

• applying for the vendor update.
• removing obsolete driver dependencies.
• enabling vulnerable driver protections.
• restricting driver installation.
• using application and execution control; and
• monitoring driver-load activity.

EPM remains valuable because it removes the attacker’s ordinary route to administration. But it cannot guarantee that no software vulnerability will provide an alternative route.

2. DLL and library hijacking

Under T1574.001, an attacker may place or substitute a malicious DLL so that a legitimate application loads it. If the legitimate process runs at a higher privilege level, the attacker-controlled DLL can inherit that level.

The corresponding controls include:

• restricting access to application and library paths.
• enabling safe library-loading behaviour.
• restricting remote DLL loading.
• allow listing trusted libraries.
• updating vulnerable applications.
• detecting unexpected modules loaded from non-standard locations; and
• monitoring file and registry changes.

MITRE maps T1574.001 to Restrict Library Loading and Update Software. CIS Safeguard 2.6 separately calls for allowing only authorised .dll, .ocx and .so libraries to load into system processes.
EPM may reduce the number of processes that run elevated, thereby reducing the value of the hijack. It does not replace library control.

3. User-level data access

A standard user may still have legitimate access to commercially sensitive files, browser sessions, collaboration platforms, source code or customer information.

Removing administrator rights does not revoke the user’s authorised business access.

Identity governance, data-loss prevention, information protection, browser security and behaviour analytics remain necessary.

4. Social engineering and approval abuse

A technically correct elevation workflow can still fail if:

• users routinely approve prompts without understanding them.
• support personnel approve requests under SLA pressure.
• business justifications are not reviewed.
• emergency codes are shared.
• exceptions never expire; or
• The requester and approver are effectively the same control point.

The workflow must treat elevation as a security decision, not merely a help-desk transaction.

Why least-privilege programmes fail after deployment

The most common rollout failure is not that least privilege is conceptually wrong.

It is that the organisation removes administrator rights before it understands how privileged work is performed.

Rules are often built from:

• application inventories.
• interviews with a few administrators.
• assumptions about job titles.
• known help-desk tickets; or
• a short pilot that covers only routine weekly work.

Those sources miss infrequent but legitimate activity such as:

• monthly finance reconciliation.
• quarterly reporting.
• certificate renewal.
• vendor diagnostics.
• software upgrades.
• emergency recovery.
• hardware configuration.
• developer toolchain changes; and
• annual audit or compliance utilities.

Use audit data before enforcement

A practical rollout should begin in observation mode.

A 30-day period is a reasonable minimum starting point, but it should not be treated as a universal standard. The observation window should cover the organisation’s actual business cycle. Teams with monthly, quarterly or seasonal administrative activity may need a longer period or a continuing audit population.

During observation, capture:

• user and device identity.
• operating system.
• executable or script.
• publisher and certificate.
• file hash and version.
• file path.
• command-line arguments.
• parent and child processes.
• requested privilege level.
• network connectivity state.
• request reason.
• approval path; and
• resulting action.

Do not create one rule for every observed event. Classify the events into policy patterns.

Build policy by persona and task

Useful policy personas may include:

• ordinary business users.
• developers.
• IT support.
• infrastructure administrators.
• security operations.
• finance and audit teams.
• branch or field personnel.
• remote and intermittently connected users; and
• Third-party support engineers.

Within each persona, classify activity into:

• Denied: The action should never receive elevation.
• Pre-approved: A tightly identified and low-risk application may elevate automatically or with user confirmation.
• Justified: The user must provide a business reason or reauthenticate.
• Support-approved: An authorised reviewer must approve the specific request.
• Emergency: A time-limited break-glass process applies with enhanced evidence and review.
• Unknown: The request is blocked or contained until engineering analysis is complete.

Microsoft’s own guidance recommends strong rule identifiers such as hashes, certificates and signed file properties. It warns against relying only on file names and advises using paths that standard users cannot modify. Microsoft also recommends using automatic elevation sparingly and only for trusted, business-critical files.

These are vendor-neutral rule-design principles.

Do not create a new standing-privilege problem through exceptions

The exception register can quietly become the replacement for the local Administrators group.

Every exception should therefore have:

• a named business owner.
• a technical owner.
• a defined scope.
• an approval record.
• a start date.
• an expiry date.
• a review frequency.
• a documented reason.
• compensating controls; and
• automatic revocation wherever possible.

Permanent exceptions should be rare and periodically challenged.

“Approved once” must not silently become “approved forever.”

Metrics that engineering teams and executives can both use

A successful EPM programme should report both security outcomes and operational impact.

Security measures

• Percentage of endpoints with no standing local administrator membership.
• Number of permanent administrator assignments removed.
• Percentage of privileged activity broke through EPM or PAM.
• Number and median age of active exceptions.
• Number of elevation attempts denied by policy.
• Number of elevations involving an unknown application, unsigned file or user-writable path.
• Number of rules permitting unrestricted elevated child processes.
• Percentage of privileged actions with complete requester, approver, purpose and duration evidence.

Operational measures

• Percentage of legitimate elevation requests resolved through an existing rule.
• Median time to complete an approved elevated task.
• Support tickets for 100 managed endpoints.
• Percentage of requests requiring manual approval.
• Percentage of manual requests subsequently converted into safe policy.
• User-impact incidents caused by missing or incorrect rules.
• Policy coverage across Windows, Linux and macOS.
• Number of elevation rules retired because the underlying application or workflow no longer exists.

The objective is not to drive elevation requests to zero.

The objective is to ensure that every necessary elevated action is intentional, narrowly scoped, time-bound and attributable.

The endpoint control stack architects should design

A mature endpoint-security architecture needs complementary layers.

Control layer	Primary purpose
Identity assurance	Establish who or what is requesting access.
Endpoint Privilege Management	Decide whether and how endpoint authority may be elevated.
PAM	Govern privileged credentials, accounts and administrative sessions.
Application and script control	Decide which binaries and scripts may execute.
Library control	Restrict which DLLs and shared libraries may load.
Patch and vulnerability management	Remove exploitable weaknesses.
Driver protection	Block known vulnerable or unauthorised drivers.
EDR/XDR	Detect, investigate and respond to suspicious behaviour.
FIM	Detect and, where supported, respond to unauthorised file or configuration changes.

SIEM and analytics

Correlate privilege, identity and endpoint events across the environment.

 

No single row replaces the others.

How ARCON | Endpoint Privilege Management fits this model

ARCON documents its EPM platform as providing centralised governance for Windows, Linux and macOS from one administrative console.

Its documented capabilities include:

• just-in-time privilege elevation.
• Privileged Elevation and Delegation Management.
• Temporary elevated access for defined tasks.
• application allow listing and blocklisting.
• File Integrity Monitoring with rollbacks where required.
• Online and offline elevation workflows.
• an independent workflow for users outside the organizational network.
• audit trails, reporting and alerting.
• behavioural analytics for privileged endpoint activity; and
• integration with ARCON | Privileged Access Management.

These capabilities should be validated against the organisation’s actual use cases during evaluation.

The buying decision should not be based on the longest feature list. It should be based on whether the product can enforce the required privilege model without replacing standing administrator rights with broad, unsafe elevation rules.

What to test in an ARCON EPM proof of value

Use a representative pilot rather than a controlled demonstration built around a few well-known installers.

Include:

• Windows, Linux and macOS endpoints.
• ordinary users and technical users.
• online, remote and intermittently connected devices.
• predictable and unpredictable elevation requests.
• signed and unsigned applications.
• scripts and command-line tools.
• applications that create child processes.
• software running from user-writable locations.
• emergency access.
• expired requests and exceptions; and
• integration with PAM, SIEM, service desk and identity systems.

Measure whether the pilot can:

• remove standing administrator rights.
• preserve legitimate productivity.
• identify applications and workflows that genuinely require elevation.
• prevent broad-processed child inheritance.
• govern offline elevation.
• automatically revoke temporary authority.
• provide complete audit evidence; and
• create consistent policies across operating systems.

A practical 90-day implementation sequence

Days 1–30: Observe

Deploy to a representative cohort in audit or discovery mode.

Capture elevation behaviour, identify standing administrators, classify applications and map business personas.
Do not remove administrator rights from the entire cohort immediately.

Days 31–60: Control

Create rules based on observed activity.

Start with:

• tightly defined pre-approved applications.
• denied high-risk tools.
• support-approved unknown requests.
• time-bound emergency access; and
• explicit handling of child processes and command-line arguments.

Remove standing administrator rights from a limited group and measure disruption.

Days 61–90: Expand

Correct false positives and missing workflows.

Convert repeated legitimate requests into tightly scoped policy, retire unnecessary exceptions and extend the programme to additional personas and operating systems.

Present the results using both security and operational measures.

Questions for the architecture review

Before selecting or expanding an EPM platform, ask:

• Does the product remove local administrator membership or merely add another elevation mechanism?
• Can it elevate an application or task without elevating the user’s entire session?
• How are child processes controlled?
• Can rules include hashes, certificates, versions, paths and command-line arguments?
• Can users modify the location from which an approved application runs?
• How are unknown, unsigned and user-writable-path applications handled?
• How are Windows, Linux and macOS governed differently?
• Can remote or offline users obtain controlled, time-bound elevation?
• Are requester, approver, justification, duration and outcome captured?
• Do exceptions expire automatically?
• How does the platform integrate with PAM, identity, service desk, SIEM and EDR?
• Can the organisation prove that temporary privilege was revoked?

The engineering decision

Removing standing administrator rights is not a claim that every endpoint attack will be stopped.

It is a deliberate architectural decision to ensure that compromise of an ordinary user, process or application doesnot automatically become compromised of the operating system.

The strongest EPM programme therefore does four things:

• removes unnecessary standing authority.
• provides controlled elevation for legitimate work.
• pairs elevation with application, script and library controls; and
• produces evidence that every privileged action was authorised, limited and revoked.

That is the standard an endpoint privilege platform should be evaluated against.

Why Endpoint Privilege Management Is Now Business-Critical Control

Part 1 of ARCON’s Endpoint Privilege series for CTOs, CIOs and CISOs.

EXECUTIVE TAKEAWAY

EDR remains essential, but detection starts after an activity occurs. Endpoint Privilege Management (EPM) operates earlier: it determines whether a user, process or application is authorised to elevate, execute a restricted action, modify a protected resource or use administrative authority. The strongest endpoint strategy combines both.

FORMAT Executive article	AUDIENCE CTOs, CIOs and CISOs
SERIES Part 1 of ARCON endpoint privilege series	DATE August 2026

The security gap is not visibility alone. It is authority.

Most organisations have invested heavily in endpoint visibility. They can collect telemetry, identify suspicious behaviour and investigate incidents. Yet a more fundamental question is often left unanswered:

After an account, application or endpoint is compromised, what is it allowed to do?

That question matters because modern attacks increasingly use legitimate identities, trusted tools and authorised pathways. An attacker may not need to introduce obvious malware if an existing account can install software, execute scripts, alter security settings, access credential stores or change protected files.

This is where Endpoint Privilege Management becomes a business control rather than another security product. EPM reduces standing administrative authority and provides controlled, time-bound elevation only when a legitimate task requires it.

Initial access is changing, but privilege remains the post-entry chokepoint

The Verizon 2026 Data Breach Investigations Report found that vulnerability exploitation accounted for 31% of initial access, while credential abuse accounted for 13%. However, credential abuse appeared at some point in 39% of breaches. The implication is important: organisations must continue improving patching and exposure management, but they must also control what valid credentials and processes can do after entry.

Threat operations are also accelerating. Mandiant reported that the median hand-off from an initial-access actor to a secondary threat group fell from more than eight hours in 2022 to 22 seconds in 2025. That statistic does not represent every intrusion or a universal detection deadline, but it shows how quickly a foothold can be operationalised.

CrowdStrike reported a 29-minute average eCrime breakout time in its 2026 Global Threat Report, with the fastest observed breakout of 27 seconds. It also reported that 82% of its 2025 detections were malware-free. These figures reinforce the same point: when adversaries use legitimate tools and identities, prevention cannot depend solely on recognising malicious files.

The practical conclusion is not that detection has failed. It is that detection and response should not be the first and only controls standing between an attacker and administrative authority.

MITRE ATTACK changed the map for a reason

In ATTACK v19, released in April 2026, MITRE split the former Defense Evasion tactic into two distinct areas. TA0005 was renamed Stealth, and a new tactic, TA0112 Defense Impairment, was created. The former T1562 Impair Defenses technique was revoked and replaced by T1685 Disable or Modify Tools.

The change separates two different problems:

STEALTH Hiding activity from defenders

DEFENSE IMPAIRMENT Weakening, disabling or changing security controls

MITRE’s mitigations for T1685 emphasise controls such as execution prevention, file and directory permissions, registry permissions, account management and secure configuration. MITRE also provides detection guidance, so the correct conclusion is not that detection is irrelevant. The stronger conclusion is that preventive authorisation and execution controls are an explicit part of the defence.

For security leaders, the immediate action is straightforward: update ATTACK mappings that still reference T1562, assess coverage against T1685 and determine whether controls can prevent unauthorized administrative actions, not merely alert after they occur.

What Endpoint Privilege Management changes in practice

A mature EPM programme should answer five operational questions.

1. Can standing local administrator rights be removed without stopping work?

Users should operate as standard users by default. When an approved task genuinely requires additional authority, EPM can grant temporary, task-specific or application-specific elevation and revoke it automatically after the approved period or action.

This reduces the value of a compromised user account while preserving productivity for administrators, developers, support teams and other authorised users.

2. Can the application be elevated without elevating the entire user?

Traditional approaches often grant broad administrative rights to complete a narrow task. EPM can instead elevate an approved application, installer, process or command under defined conditions while the user remains a standard user.

This is a practical expression of least privilege: provide the minimum authority necessary for the minimum time necessary.

3. Can risky execution be controlled before it begins?

Application allowlisting and blocklisting, script and command controls, process restrictions, digital-signature or hash-based policies, and risk-based rules can reduce the opportunity to run unauthorised tools or modify protected resources.

These controls complement EDR. EDR observes and responds to behaviour; EPM determines whether the behaviour is permitted to proceed with elevated authority.

4. Can legitimate exceptions be handled without creating permanent bypasses?

Remote users, offline endpoints, emergency support teams and specialised applications often cause least-privilege programmes to stall. A workable EPM design needs controlled online and offline elevation, approval workflows, time limits, identity verification and a complete record of the exception.

The objective is not to eliminate legitimate administration. It is to eliminate unmanaged administration.

5. Can the organisation prove that privilege is governed?

Boards, auditors and regulators do not need another dashboard alone. They need evidence showing who received elevation, what was approved, which application or command was used, how long access remained active, whether an exception occurred and whether the privilege was revoked.

A strong EPM programme therefore improves both security control and auditability.

The management plan must also be treated as privileged

Stryker disclosed in March 2026 that a cybersecurity incident disrupted its Microsoft environment and affected operations including order processing, manufacturing and shipping. CISA subsequently issued guidance specifically naming Stryker and urging organisations to harden endpoint-management systems.

CISA’s recommendations included least-privilege administrative roles, phishing-resistant MFA, controls over privileged endpoint-management functions and multi-administrator approval for high-impact actions.

The architectural lesson extends beyond one incident: an MDM, RMM or EPM console can exercise authority across thousands of devices. It should therefore be governed as a high-value privileged system, with strong identity assurance, separation of duties, tightly scoped roles and additional approval for destructive or high-impact changes.

EPM does not replace the rest of the security stack

A credible EPM strategy should be explicit about its boundaries.

EPM does not replace patching, vulnerability management, EDR/XDR, SIEM, identity security or Privileged Access Management. It reduces the authority available on endpoints and governs how that authority is granted, used and evidenced.

The controls work together:

CONTROL LAYER	PRIMARY ROLE
Patching and exposure management	reduce the number of exploitable weaknesses.
Identity security and MFA	strengthen assurance about who is requesting access.
PAM	governs privileged accounts, credentials and sessions across enterprise systems.
EPM	governs privilege and execution at the endpoint.
EDR/XDR	detects, investigates and responds to suspicious behaviour.

The value of EPM is that it closes the gap between a standard user session and unrestricted administrative control.

How ARCON | Endpoint Privilege Management addresses the gap

ARCON | EPM is designed to provide centralised endpoint privilege governance across Windows, Linux and macOS environments. Its capabilities include controlled privilege elevation and delegation, just-in-time and temporary administrator access, online and offline elevation workflows, application and process controls, File Integrity Monitoring, endpoint MFA, approval workflows, user behaviour analytics, reporting and audit evidence.

It can operate alongside ARCON | Privileged Access Management to extend privilege governance from enterprise accounts and systems to endpoint actions. This allows organisations to manage the complete privilege path more consistently: identity, approval, endpoint authority, elevated activity and evidence.

The important buying question is not whether an EPM platform has the longest feature list. It is whether it can enforce the organisation’s actual operating model across different endpoint types, user groups, connectivity conditions and approval requirements without creating excessive helpdesk friction.

A 90-day proof-of-value plan for security leaders

A successful EPM initiative should begin with measurable exposure, not a broad product rollout.

TIMEFRAME	FOCUS	EXECUTION
Days 1–30	Discover and baseline	Identify users and endpoints with standing local administrator rights. Catalogue applications, installers, scripts and commands that legitimately require elevation. Map remote and offline use cases, existing approval paths, emergency-access requirements and audit obligations.
Days 31–60	Apply policy to a controlled cohort	Select a representative pilot group, such as IT support, developers, finance users or branch users. Remove standing administrative rights where feasible and introduce application-specific or time-bound elevation. Define pre-approved low-risk actions and workflows for higher-risk requests.
Days 61–90	Measure, refine and scale	Evaluate security and operational outcomes before expanding coverage. Useful measures include:

 

• percentage of pilot endpoints converted to standard-user operation.
• number of standing administrator assignments removed or converted.
• percentage of elevation requests fulfilled through pre-approved policy.
• median time required to complete an approved elevated task.
• number of blocked or restricted application attempts.
• use of emergency or offline elevation.
• helpdesk-ticket trend and user disruption; and
• completeness of evidence available for audit and investigation.

These measures produce a defensible business case without relying on generic ROI claims.

Five questions for the next security steering committee

1. How many users and endpoints currently retain standing local administrator rights?
2. Which applications, processes and commands genuinely require elevation, and under what conditions?
3. Can privilege be bound to identity, device, task and time—and revoked automatically?
4. Are MDM, RMM and EPM administrative actions protected by least privilege, phishing-resistant MFA and separation of duties?
5. Can the organisation produce complete evidence for privilege grants, exceptions and elevated activity without manual reconstruction?

An organisation that cannot answer these questions has an endpoint privilege exposure problem, even if its detection coverage is strong.

The executive decision

The endpoint-security discussion should no longer be framed as EPM versus EDR. The relevant distinction is between controls that determine what is authorised and controls that identify what has already occurred.

When attackers can move in seconds and increasingly operate through legitimate pathways, reducing standing privilege is one of the clearest ways to limit blast radius before an alert becomes an incident.

RECOMMENDED NEXT STEP

begin with an Endpoint Privilege Exposure Review, not a generic product demonstration. Map standing administrator rights, critical elevation workflows, high-risk applications, offline users, management-plane controls and audit requirements. Use that baseline to define a limited 90-day pilot with agreed success measures.

PRIMARY CTA Book an Endpoint Privilege Exposure Review

SECONDARY CTA Download the CTO’s Endpoint Privilege Evaluation Checklist

Source references for the web editor

1. MITRE ATT&CK – April 2026 Updates (v19)
2. MITRE ATT&CK – TA0112 Defense Impairment
3. MITRE ATT&CK – T1685 Disable or Modify Tools
4. Google Cloud / Mandiant – M-Trends 2026
5. CrowdStrike – 2026 Global Threat Report
6. Verizon – 2026 Data Breach Investigations Report
7. BeyondTrust – Microsoft Vulnerabilities Report 2026
8. Stryker Corporation – March 2026 Form 8-K
9. Stryker Corporation – Customer update
10. CISA – Endpoint Management System Hardening Alert, March 2026
11. ARCON | Endpoint Privilege Management
12. ARCON | Privileged Access Management

Note: Product capability descriptions should be checked against the current approved ARCON product materials before publication.