How should security teams govern computer-use models that change access inside enterprise systems?

Why This Matters for Security Teams

Computer-use models are different from ordinary applications because they can take actions inside enterprise systems, not just recommend them. That means they can change roles, approve requests, move records, or trigger downstream automations with real security impact. If governance stops at prompt review or model access tokens, the organisation has left the privileged action path outside its control plane. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs frames this as a lifecycle problem, not a tooling problem.

The operational risk is that these models often inherit broad access from the workflows they assist. Once a model can edit enterprise state, traditional app security assumptions break down: static roles are too coarse, approvals can be bypassed through chained actions, and audit trails may show the final change without showing the model’s intent, context, or intermediate tool calls. The OWASP Non-Human Identity Top 10 is increasingly relevant here because the model is effectively acting as a privileged non-human operator. In practice, many security teams encounter the abuse path only after an automated change has already expanded access rather than through intentional change review.

How It Works in Practice

The safest pattern is to govern the model as a privileged workload with tightly bounded execution rights. That starts by separating the model’s identity from the human requester, then issuing short-lived, task-specific credentials only when the workflow is approved. Current guidance suggests treating every action as a policy decision at runtime, not as a standing permission inherited from a service account. The model should present a workload identity, such as a SPIFFE-based identity or an OIDC-issued token, so the platform can verify what the agent is and what task it is authorized to perform.

Runtime controls should include:

• Just-in-time credentials that expire when the task ends or the approval window closes.
• Policy-as-code checks for every privileged operation, with context such as target system, requested change, and approver state.
• Immutable logging of prompts, tool calls, approval steps, and final system changes in the same audit chain used for access provisioning.
• Segregation of duties so the model cannot both request and complete high-risk access changes without independent review.

This aligns with the direction of the NIST Cybersecurity Framework 2.0 for governance and access control, and it is consistent with the identity-first posture described in The State of Non-Human Identity Security, where weak monitoring, over-privilege, and poor rotation remain common failure points. These controls tend to break down when the model is allowed to operate across legacy admin consoles that lack granular APIs and cannot enforce request-time policy consistently.

Common Variations and Edge Cases

Tighter control often increases operational overhead, requiring organisations to balance automation speed against change assurance. That tradeoff matters most where the model is acting in a high-volume service desk, ITSM, or IAM environment, because every additional approval step can slow legitimate access changes. There is no universal standard for this yet, but best practice is evolving toward context-aware authorisation rather than coarse RBAC alone.

Some environments need stricter handling than others. If the model can manage third-party SaaS access, cloud IAM roles, or directory groups, then the blast radius is much larger and ephemeral credentials become non-negotiable. If the workflow spans human and machine approvals, the model should never be the final authority on its own request. NHI Management Group’s Top 10 NHI Issues and Ultimate Guide to NHIs — Regulatory and Audit Perspectives both reinforce the same point: if the model can modify access, its lifecycle must be reviewable, revocable, and auditable like any other privileged identity.

Teams should be especially cautious in environments with shared admin sessions, screen-scraping automation, or unstructured free-text approvals, because those conditions make it difficult to prove who authorised what and why.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern AI agents that can access enterprise systems?
• How should security teams govern API keys used for generative AI access?
• How should security teams use data classification to reduce access risk?