Yes, because both can create unmanaged capability on endpoints and both may operate outside normal software approval paths. The practical difference is in how they are discovered and governed, not in the need for inventory, authorisation, and removal workflows. AI discovery should feed the same lifecycle controls that govern other non-human software assets.
Why local models and AI agents land in the same control conversation
Local models and AI agents can both show up as software that creates capability before governance catches up. The key control question is not whether the workload is “a model” or “an agent”, but whether it can run, persist, or act on endpoints without being inventoried, approved, reviewed, and removed like any other software asset. Shadow AI and AI Agent Discovery Guide is a useful reference point for that discovery problem, because unmanaged AI often first appears through endpoint, cloud, or grant signals rather than through a central catalogue.
That shared control problem matters because local inference tools and agentic runtimes can each expand the attack surface in different ways. A local model may introduce a new executable, plugin, or data path, while an agent may add tool access, delegated authority, or automated action. In both cases, the organisation needs to know what is installed, who approved it, what it can reach, and how it is removed when the use case ends.
The practical implication is that discovery should feed standard lifecycle control, not a separate “AI-only” exception path. If teams treat local models as harmless because they are offline, or treat agents as exceptional because they are autonomous, they usually miss the same failure pattern, unmanaged capability that survives beyond its intended scope.
What changes between a local model and an AI agent
The control objective is similar, but the governance shape is not identical. A local model is often controlled like endpoint software or a packaged capability, so the main questions are install source, execution rights, update path, and data exposure. An AI agent adds a second layer, because it may act on behalf of a user or system, invoke tools, and take decisions that require explicit authorisation before action.
That difference matters when you design review and inventory workflows. Local models are usually discovered through device management, application inventories, or software allowlisting. Agents may also require oversight of credentials, delegated access, policy enforcement, and action logging, especially when they can reach email, ticketing, code, or business systems. AI Agent Authorisation Guide is directly relevant here because it frames the decision point around task-scoped access and per-action approval, which is the right mental model when an agent can do more than compute.
That is why the distinction is operational rather than conceptual. Both belong in the same control family of inventory, approval, removal, and review. The agent then requires extra controls for delegated authority, while the local model may require extra controls for endpoint governance, software provenance, and data handling.
How to govern them without creating a separate exception path
The most reliable pattern is to use one lifecycle process for all unmanaged AI software, then branch only where the capability differs. Discovery should identify the asset, ownership should determine who can approve it, policy should define what it may access, and decommissioning should ensure the software, configuration, and any related tokens or integrations are removed together. Shadow AI and AI Agent Discovery Guide and AI Agent Observability, Audit and Incident Response Guide fit naturally here because discovery is only useful when it is tied to attribution, logging, and revocation.
For local models, the operational question is whether the software is sanctioned, patched, and confined to an approved environment. For agents, the question expands to whether each action is bounded by policy and whether the agent can be stopped, audited, or have its access revoked quickly. Zero Trust for AI Agents supports that approach by emphasizing verification, least privilege, and no standing access, which is the right control pattern when the tool can act independently.
Practically, that means teams should not build one workflow for “software” and another for “AI”. They should build one workflow for capability on endpoints, then add agent-specific gates where the system can act, not just answer.
Risk and Threat Considerations
Unmanaged local models and AI agents create similar exposure because both can become durable capability on endpoints before security teams understand the blast radius. The risk increases when the software can access credentials, data, or internal tools, since removal then becomes more than uninstalling code, it becomes revoking downstream reach and proving nothing else still trusts it.
Failure mechanism: The control failure is usually inventory drift, excessive local trust, or delegated access that outlives the approved use case. For agents, that can also include overbroad tool permissions or hidden reuse of human credentials; for local models, it often shows up as untracked execution or unmanaged plugins.
Impact: The result can be unauthorized data access, hidden persistence, uncontrolled endpoint capability, or actions that continue after the business owner believes the AI has been retired. In the worst case, the AI becomes a shadow control plane that security cannot reliably see, approve, or revoke.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Unmanaged AI software must be retired and access removed cleanly. |
| NHI-05 — Overprivileged NHI | Agents and local AI tools fail when they retain more access than needed. | |
| NHI-10 — Human Use of NHI | Using human credentials or approvals for AI capability changes the control boundary. | |
| Recommendation — Tie AI decommissioning to asset and access removal so retired tools cannot still act. Constrain AI software to the smallest permissions needed for its approved task. Separate human access from AI execution paths and avoid shared credentials. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | AI agents can misuse delegated authority or inherit excess privilege. |
| ASI02 — Tool Misuse | Agents become risky when tool access is not tightly governed. | |
| Recommendation — Enforce per-action authorization and remove standing privilege from agents. Restrict which tools an agent can call and require policy checks before use. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | The question is fundamentally about discovering and tracking AI software assets. |
| AC-6 — Least Privilege | Both local AI and agents should be limited to approved access paths. | |
| IA-5 — Authenticator Management | Agents often depend on tokens, keys, or other credentials that must be governed. | |
| Recommendation — Inventory local AI software and agents the same way you inventory other endpoint components. Limit AI execution and access to the minimum privileges needed for the task. Track and rotate AI-related credentials so hidden access does not persist. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The answer depends on verifying capability and access continuously, not trusting AI by label. |
| Recommendation — Require continuous verification and deny standing trust for AI workloads. | ||
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Local models and agents belong in enterprise asset inventory and control. |
| Recommendation — Add AI software to enterprise asset inventory before allowing use. | ||
Practitioner Guidance
What to prioritise: Put AI discovery into the same asset governance process you already use for endpoint software, then add an approval branch only when the system can take actions or use credentials. That keeps local models and agents in one lifecycle view instead of fragmenting oversight.
What to verify: Confirm three things before trusting the asset, who owns it, what it can reach, and whether removal actually revokes its practical ability to act. If any of those are unclear, treat the AI as unmanaged until proven otherwise.
Common mistake: Teams often approve the model or agent but forget the surrounding capability, plugins, tokens, browser access, or API connections. Those are usually where the real control failure sits.
Practitioner takeaway: Local models and AI agents should be governed as one control problem at the lifecycle level, but agents deserve additional authorisation and observability because they can turn installed software into delegated action.
Related resources from NHI Mgmt Group
- Should organisations treat sandbox AI, internal AI apps, and production AI as the same control problem?
- Should organisations treat Copilot as part of IAM or as a separate AI control problem?
- What makes GenAI usage part of the same secrets problem?
- What should organisations do when AI agents become part of the fraud problem?