How should organisations govern AI-assisted work in engineering and operations?

Treat AI-assisted work as an identity and accountability problem, not just a productivity upgrade. Define which actions the AI may influence, which outputs require human verification, and which systems or data sources sit behind the workflow. Then align review, logging, and approval rules to the actual runtime path rather than the job title alone.

Why This Matters for Security Teams

AI-assisted engineering and operations work creates a governance gap because the real risk is not the model output alone, but the path it takes to produce that output. When an assistant can open tickets, change code, query observability data, or trigger infrastructure actions, it behaves like a workload with identity, reach, and side effects. That means governance has to cover permissions, data exposure, and approval logic together. NHI Management Group’s guidance on the Top 10 NHI Issues is a useful starting point because the same control failures that affect service accounts also affect AI-enabled workflows. NIST’s NIST Cybersecurity Framework 2.0 reinforces the need to tie governance to actual assets, access paths, and response obligations rather than abstract role labels.

Practically, the question is how to decide what the AI may influence, what a human must verify, and where logging must capture the full context for audit and incident response. If those decisions are left informal, teams end up with hidden privilege, silent changes, and brittle approvals that do not reflect runtime reality. In practice, many security teams discover the problem only after an AI-assisted change has already reached production, rather than through intentional workflow design.

How It Works in Practice

Governance should start by mapping each AI-assisted workflow into discrete actions and control points. For example, an assistant may draft a pull request, but only a human can merge it; it may summarize incident data, but not query regulated records unless the request is explicitly authorised; it may suggest infrastructure changes, but not execute them without a separate approval step. This is consistent with current NIST thinking on risk-driven oversight, and the operating model should be aligned to NIST Cybersecurity Framework 2.0 and the governance emphasis in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

A workable pattern is to treat the AI as an identity-bearing workload, then layer intent-based authorisation on top of that identity. In other words, access should be granted at request time based on what the system is trying to do, which data it is trying to touch, and which environment it is operating in. That is stronger than static RBAC alone, because the same assistant may be safe to summarise logs but not safe to change a firewall rule. Use short-lived credentials, scoped tokens, and explicit approval gates for high-impact actions. Where possible, bind the AI to workload identity controls such as SPIFFE or OIDC-backed service identities, then combine them with policy-as-code checks and immutable logging. NHI Management Group’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is relevant here because auditability depends on proving who or what acted, when, and under which policy.

• Define which actions are advisory, which require human review, and which are prohibited.
• Issue just-in-time credentials per task, not standing access for broad operational use.
• Log prompts, tool calls, policy decisions, and downstream effects as one evidence chain.
• Re-validate access when context changes, such as environment, severity, or data sensitivity.

These controls tend to break down when the AI is wired directly into production tooling with broad secrets access and no request-level policy enforcement.

Common Variations and Edge Cases

Tighter controls often increase operational friction, so organisations have to balance speed against blast radius. That tradeoff is especially visible in incident response, where teams want automation to move fast but still need reliable human accountability. Best practice is evolving, but there is no universal standard for this yet, which is why frameworks such as DeepSeek breach reporting and the Top 10 NHI Issues matter: they show how quickly exposed secrets, weak lifecycle controls, and overbroad access can turn AI capability into an attack path.

There are two common edge cases. First, read-only assistants can still leak sensitive data if they have access to the wrong sources, so “no write access” is not enough. Second, multi-step agents that chain tools may cross trust boundaries even when each individual step looks harmless. For that reason, current guidance suggests reviewing the full workflow graph, not just the first permission check. NIST AI Risk Management guidance and agent-focused frameworks such as OWASP-AGENTIC and CSA-MAESTRO both support this broader view of accountability, but implementations vary by platform maturity and toolchain. Organisations with legacy ticketing, shared credentials, or manually approved break-glass access usually need a staged rollout rather than a big-bang policy change.

Related resources from NHI Mgmt Group

• How should teams govern AI-assisted internal app building without slowing delivery?
• How should healthcare organisations govern AI chatbots that can access PHI?
• How should healthcare organisations govern AI tools that handle PHI?
• How should security teams govern AI native engineering environments with mixed human and machine identities?