What should organisations do when AI agents run on unmanaged or BYOD endpoints?

Why unmanaged endpoints change the trust model for AI agents

When an AI agent runs on a device you do not govern, the device becomes part of the attack surface whether or not it is corporate-owned. The practical issue is not the endpoint itself, but the secrets, tokens, and delegated access it can reach. If the device is lost, rooted, shared, infected, or simply outside policy control, the organisation loses meaningful assurance over how that access is used.

In that situation, the safer pattern is to separate execution from authority: let the endpoint request work, but keep durable credentials, refresh capability, and higher-value privileges in a controlled backend. That preserves the ability to revoke access centrally and reduces the chance that a compromised personal device becomes a long-lived foothold.

What the backend should hold, and what the endpoint should never keep

The backend should hold the most sensitive identity material, especially anything that can mint new access over time. The endpoint should receive only the minimum short-lived access needed to complete the current action. That means avoiding storage of refresh tokens, reusable API keys, long-duration session material, and any secret that would let the endpoint reestablish access after a reset or compromise.

This design is especially important when agents are allowed to act on behalf of a user or service. If the endpoint stores the durable credential, revocation becomes slow and uncertain; if the backend brokers each access decision, the organisation can re-check policy, scope, and context before issuing a new token. AI Agent Authorisation Guide is a useful reference for task-scoped and just-in-time access decisions, and Zero Trust for AI Agents reinforces the idea of verifying each request rather than trusting the device by default.

For endpoints that may be untrusted by design, this backend-brokered approach also reduces exposure to secret leakage, overprivilege, and stale access paths. If the device can only request narrowly scoped access, a compromise is less likely to expose durable credentials or broad administrative reach. Agentic AI Identity Guide is helpful where teams need a lifecycle view of how an agent receives, uses, and loses identity.

How organisations should govern access when the endpoint is BYOD

BYOD support should be treated as a policy decision, not just an engineering convenience. Organisations need to distinguish between endpoints that are merely allowed to initiate a session and endpoints that are trusted to hold standing access material. The first category can be manageable; the second is usually the wrong place for long-lived secrets if the device is not fully enrolled, monitored, and enforceable under corporate controls.

A practical rule is simple: if you cannot confidently attest to device posture, patching, encryption, malware protection, and remote wipe capability, do not place durable agent credentials there. Instead, require the endpoint to authenticate to a controlled service that performs authorization centrally and issues only the minimal token required for a bounded task. For readers mapping this to external guidance, the NIST Cybersecurity Framework 2.0 supports the broader govern-protect-detect posture, while NIST SP 800-207 Zero Trust Architecture aligns with continuous verification and least privilege.

Where teams need a practical implementation view, the main design choice is whether the endpoint is a transient execution surface or an identity-bearing control point. If it is the latter, treat it like an enterprise-managed system and require commensurate controls. If it is only a transient surface, keep it out of the credential trust chain and make revocation fast enough that a lost device does not remain a live authority for hours or days.

Risk and Threat Considerations

Unmanaged and BYOD endpoints create the highest risk when they are allowed to hold reusable secrets or long-lived refresh capability. A stolen, malware-infected, or shared device can turn a convenience decision into persistent unauthorized access, and the problem is often hidden until a revocation or incident response event reveals that the endpoint retained authority longer than expected.

Failure mechanism: The agent caches durable credentials locally, the endpoint is compromised or leaves control, and the attacker reuses those credentials to continue calling protected services even after the user believes access has been removed.

Impact: The organisation can lose revocability, expand blast radius, and create a durable persistence path that is difficult to detect because the access still appears to come from an apparently legitimate agent or user workflow.

Practitioner Guidance

What to verify: Confirm that the endpoint never receives a reusable secret when the device is outside managed control. The decisive check is whether access can be withdrawn centrally without waiting for the device to come back online or cooperate.

Decision rule: If the endpoint is unmanaged, treat it as a request origin, not an authority holder. Use short-lived, narrowly scoped access issued from a backend that can re-evaluate policy on every meaningful action.

Common mistake: Teams often secure the login flow and then over-trust what the device keeps afterward. For this use case, post-login secret residency matters as much as the initial authentication step.

Practitioner takeaway: The goal is not to make BYOD “safe enough” to hold durable identity material, but to keep those devices outside the revocation-critical trust path so compromise, loss, or misuse does not become persistent access.

Related resources from NHI Mgmt Group

• How should organizations approach the governance of AI agents?
• What should organisations do first after discovering unmanaged AI agents?
• How should security teams govern local AI agents that run on developer endpoints?
• What breaks when organisations do not discover shadow AI agents and unmanaged Skills early?