How should security teams govern AI-driven customisation without losing control?

Why This Matters for Security Teams

AI-driven customisation changes more than the interface layer. It can generate code, modify workflows, create service accounts, and introduce new access paths faster than review processes can keep up. That creates an identity and logging problem, not just a development problem. NHIMG research on the State of Non-Human Identity Security shows that only 1.5 out of 10 organisations are highly confident in securing NHIs, which is a warning sign for any environment where software can spin up new identities on demand.

The main mistake is assuming customisation is safe if the underlying platform is approved. In practice, AI can produce bespoke paths that bypass standard change control, inherit excessive permissions, or leave behind unmanaged secrets. Security teams should treat every generated asset as part of the control surface, with ownership, review, and revocation requirements from the start. Guidance from the NIST Cybersecurity Framework 2.0 reinforces that governance must be continuous, not limited to initial approval. In practice, many security teams encounter AI-driven drift only after an over-privileged workflow or leaked secret has already been used in production.

How It Works in Practice

Governance works best when AI-generated code and workflows are treated as managed non-human identities with explicit lifecycle controls. That means each generated asset needs an owner, a purpose, a policy boundary, and a revocation path. The operating model should also distinguish between the tool that generated the change and the identities that the change creates or touches. NHIMG’s Top 10 NHI Issues is useful here because it frames the common failure pattern: unmanaged sprawl, weak visibility, and over-privilege.

A practical workflow usually includes:

• Pre-deployment policy checks for code, infrastructure, and access changes before merge or release.
• Asset registration so generated workflows and service identities are visible in inventory and review queues.
• JIT credential issuance for AI-created access paths, with short TTLs and automatic revocation after task completion.
• Secrets scanning and rotation for tokens, API keys, and certificates introduced by generated output.
• Logging that binds actions to both the human approver and the machine identity that executed the change.

For control design, current guidance suggests using policy-as-code and continuous verification rather than relying on static approvals. The NIST SP 800-53 Rev 5 Security and Privacy Controls supports this approach through access control, audit, and configuration management expectations. Security teams should also align generated assets with the lifecycle thinking in NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, because creation without retirement is where customisation becomes exposure. These controls tend to break down when AI is allowed to create production-facing identities outside the same review and revocation pipeline used for standard deployments.

Common Variations and Edge Cases

Tighter governance often increases delivery friction, requiring organisations to balance speed against assurance. That tradeoff is real, especially when product teams rely on AI to prototype quickly or customise customer-specific workflows. Best practice is evolving, but there is no universal standard for when a generated workflow becomes a separately governed asset versus a normal code change. Security teams should document that threshold explicitly and apply it consistently.

Edge cases usually appear in three places. First, low-code and no-code platforms can hide identity creation behind benign-looking automation. Second, agentic assistants may chain actions across tools, creating access paths that were never approved as a single request. Third, inherited secrets and service permissions can persist long after the original customisation is retired. In these cases, the main control question is not whether the AI output is useful, but whether the organisation can still explain who owns it, what it can touch, and how it is revoked. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives is especially relevant when audit teams need evidence that generated assets are not escaping oversight. The cleanest programmes use the same policy gates for AI-generated customisation as for any other privileged change, while allowing faster paths only where the risk has been explicitly accepted.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• How should security teams use AI in IaC workflows without losing control?
• How should security teams govern BYOD without losing control of access?
• How should security teams govern Zoom automation without losing control of access?