AI acceptable use policy fails where endpoint control is absent

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Repello AI's blog post: Most AI acceptable use policies fail when they assume all AI use is visible SaaS traffic, leaving local models, coding agents and endpoint-resident extensions outside enforcement.

Why it matters: IAM and security teams need to treat AI policy as a control-mapping exercise, because enforcement gaps often sit on the endpoint where identity, access and data controls are weakest.

Context

An AI acceptable use policy is only enforceable where a control can observe or block the behaviour it describes. That becomes difficult once the activity moves from a browser-based SaaS session to a local model, a coding agent, or an endpoint-installed extension, because the control point shifts away from the network and into the device.

The core problem is governance drift: policy language kept pace with AI adoption, but the enforcement model often did not. That makes this a useful case for identity governance for AI agents as well as endpoint control, because the same gap appears whenever authority is granted locally and never centrally registered.

Key questions

Q: What breaks when agentic AI has no acceptable use policy?

A: Without an acceptable use policy, teams lose the baseline for deciding which actions are allowed, which data may be touched, and who approves exceptions. That makes audit evidence inconsistent and accountability ambiguous. In practice, the governance team ends up arguing about outcomes after the fact instead of controlling behaviour before it starts.

Q: Why do AI agents create a governance problem for IAM teams?

A: AI agents create a governance problem because they authenticate and act as autonomous software entities with tool access. If their actions are logged only as application activity, teams lose accountability, context, and revocation clarity. IAM must therefore extend to agent identity, delegated authority, and control-plane audit trails.

Q: What signals show that an AI policy is being enforced only on paper?

A: The clearest signal is a clause set that names approved tools, data rules, and agent permissions but cannot point to any inventory, gateway, or endpoint control that would detect violations. Another signal is reliance on broad language such as good judgement or employee responsibility where the real behaviour happens locally and leaves no central trail.

Q: Should organisations treat AI acceptable use policy as a compliance document or a control design?

A: Both, but not interchangeably. As a compliance document, it sets expectations and supports accountability. As a control design, it is only real where a corresponding system can enforce or evidence the rule. Mature programmes separate those functions so they do not mistake written policy for operational control.

Technical breakdown

Why SaaS-era policy assumptions fail for local AI use

Most AI acceptable use policies assume the system under control is a cloud service that can be identified by destination, inspected in transit, and blocked at the gateway. That works for browser-based chat tools, but not for local models or tools that run inside a developer workflow. Once the interaction happens on the endpoint, the security stack loses the easy signals it normally uses for policy enforcement: network destination, proxy logs, and central session visibility. The result is not that the clause is wrong, but that it describes behaviour outside the reach of the control model. See the AI Acceptable Use Policy Template.

Practical implication: Map every policy clause to the layer that can actually observe it, or the clause is only documentation.

Why coding agents and MCP servers create a control gap

Coding agents, extensions, and MCP servers are not just new tools. They are local trust expansions that can read files, invoke actions, and inherit whatever permissions the developer has already granted. Because the configuration often lives in per-user files or local settings, the organisation may have no central inventory, no approval trail, and no live enforcement point. That makes the governance problem different from ordinary SaaS access control. If the tool chain can be edited on the laptop, policy must be enforced where the laptop is managed, not where the internet exits. See the AI Coding Agents Security Guide.

Practical implication: Treat local agent configuration as a governed asset and bind it to endpoint policy and review.

How endpoint visibility changes acceptable use from advice into control

The practical distinction between policy and control is whether the organisation can detect or stop a violation. A clause about approved tools becomes stronger if inventory exists. A clause about data handling becomes enforceable only where DLP can inspect the channel. A clause about agent permissions or local models depends on endpoint telemetry because nothing else sees the event. In this model, endpoint management is not a secondary layer. It is the only place some AI behaviours can be governed at all.

Practical implication: Use endpoint telemetry and device policy to close the clauses that network controls cannot see.

Threat narrative

Attacker objective: The practical objective is to use ungoverned endpoint AI to bypass approved-tool restrictions, data-handling rules, and permission boundaries without detection.

1. Entry occurs when an employee installs a local model, coding agent, or extension outside normal SaaS review and begins using it on a managed endpoint.
2. Credential and permission exposure follows when the tool inherits the developer's local access, filesystem reach, or attached configuration without a central approval record.
3. Impact occurs when the organisation cannot detect policy violations because the relevant AI activity never appears in network logs or central identity controls.

Breaches seen in the wild

• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).
• PocketOS database deletion incident: An AI coding agent found an over-privileged Railway API token in the codebase and deleted PocketOS production data and backups in nine seconds.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Most AI acceptable use policies are not control documents; they are control expectations with missing enforcement points. The problem is not weak wording but a mismatch between where the policy was written to operate and where modern AI actually runs. Once the behaviour shifts to the endpoint, the organisation must prove a control exists for that layer or accept that the clause is aspirational. That is a governance failure, not a drafting one.

Endpoint-resident AI creates a policy-to-control gap that traditional IAM cannot close on its own. IAM can govern accounts, sessions, and approved services, but it does not automatically observe local model use, coding-agent permissions, or attached extensions. That makes the policy question inseparable from device control and inventory discipline, especially when the trust decision happens in a config file rather than a central portal. Practitioners should treat this as a governance boundary, not a tooling annoyance.

The real test is whether a clause can be tied to an observable system, not whether it sounds sensible. A rule that cannot be monitored, blocked, or audited at the relevant layer is documentation. That distinction matters because organisations often confuse legal or HR policy coverage with technical enforceability. Where the policy reaches beyond the network, the control model has to follow to the endpoint or the rule will quietly fail in practice.

Endpoint enforcement gap: the policy assumption that all AI use is externally visible, when in fact many of the riskiest workflows are local and therefore invisible to gateway controls. This gap is especially sharp for coding agents and extension ecosystems, where privilege is conferred by local configuration and not by centrally reviewed access grants. The practitioner conclusion is straightforward: if the endpoint is not in scope, the policy is only half a control.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: AI Coding Agents Security Guide

What this signals

Endpoint governance is now the missing layer in many AI policies. Organisations that rely on gateway blocking and DLP alone will continue to miss locally-run models, coding agents, and attached extensions, because those behaviours sit outside the channels the traditional stack inspects. The control conversation therefore needs to move from acceptable use wording to device-level enforcement and inventory discipline.

Policy drift is becoming a security architecture problem, not just a legal one. The more an organisation allows AI into developer workflows, the more its governance depends on the endpoint as the final control plane. Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.

AI acceptable use will increasingly converge with coding-agent security and workstation governance. That means the next phase of enforcement will be less about blocking public chat services and more about governing local execution, extensions, and agent permissions where work actually happens. Programmes that have not defined this boundary will keep discovering policy gaps only after the workflow is already in use.

For practitioners

• Map every AUP clause to a detection point For each policy statement, record the system that would prove a violation or block the action. If no system exists, classify the clause as documentation only and close the gap before expanding the policy.
• Extend enforcement to endpoint-resident AI Bring local models, coding agents, and extension surfaces under device policy, telemetry, and review so the organisation can see activity that never reaches the gateway.
• Inventory approved AI tools and local add-ons Track installed AI software, attached extensions, and MCP servers as governed assets so policy decisions are tied to what is actually present on endpoints.
• Separate policy language from technical control Keep behavioural rules for accountability and audit, but do not count them as prevention unless a control exists at the same layer where the behaviour occurs.

Key takeaways

• Most AI acceptable use policies fail because they assume network-visible SaaS usage, while many modern AI workflows now run locally on endpoints.
• The weakest clauses are usually the ones covering coding agents, local models, extensions and MCP servers, because those behaviours often lack a central enforcement point.
• Treat any clause without a matching control as documentation, then extend endpoint visibility before the policy surface expands further.

Related NHI Mgmt Group resources: AI Coding Agents Security Guide · Identity Governance for AI Agents Guide · Shadow AI and AI Agent Discovery Guide · Amazon Q Developer extension compromise 2025

Key terms

• Acceptable Use Policy: An acceptable use policy defines which data, tools, workflows, and actions are permitted for an identity or system. For AI governance, it becomes the boundary that turns vague intent into enforceable scope, which auditors and security teams can test against actual runtime behaviour.
• Endpoint enforcement: Endpoint enforcement is the use of device-layer controls such as MFA, encryption, policy restrictions, and remote access rules to shape how a device can connect and operate. It is a control layer, not a full identity governance model, because it does not on its own manage entitlements or revocation.
• Coding Agent: A coding agent is a software system that can plan, generate, and modify code with limited human prompting. In governance terms, it is not just a tool but an actor whose permissions, tool access, and rollback path must be managed as part of the delivery process.
• Control Point: A control point is a place in a process where a decision, check or approval can prevent error, fraud or unintended behaviour. When AI automates a workflow, control points may move from people to systems, which means the organisation must redesign how evidence and override authority are preserved.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners building durable identity controls. It helps security teams connect policy, access, and enforcement across human and non-human identities.