Legal teams building with Claude Code need governed paths

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Cyera's blog post: Domain experts can now build useful internal tools with AI coding assistants, but safe rollout depends on governance for sharing, testing, access and responsibility.

Why it matters: IAM, NHI and AI governance teams need to plan for shadow AI workflows that start as local experiments and become shared business systems without the controls normally applied to software.

Context

AI coding assistants are lowering the barrier to building internal tools, which shifts the security question from who can code to who can safely create, share and depend on software. AI coding agents security becomes relevant when those tools can read context, use credentials or move from an individual laptop into wider use.

That shift matters because traditional software governance assumes trained engineers own the build, test and release path. When a lawyer or other domain specialist can create a working tool, the organisation has to decide how identity, authentication, authorization, validation and support will be handled before others rely on it.

Key questions

Q: How should teams govern AI tool access without slowing adoption?

A: Use the same identity lifecycle controls you already apply to critical enterprise systems, then automate provisioning, role updates, and revocation so governed access is faster than ad hoc approvals. The goal is not to create a special AI process, but to make approved access the path of least resistance.

Q: What controls reduce risk when non-technical staff build software with AI?

A: Use code review, threat modelling, least privilege on data and APIs, and a gated review process for prompts, generated code, and dependencies. Non-technical staff should work inside approved sandboxes with secure defaults, logging, and a human owner who signs off before release. Add secret scanning and dependency checks to catch exposed credentials and unsafe packages.

Q: How do you know when a prototype has become a production dependency?

A: A prototype becomes a production dependency when other systems, users, or business processes rely on it for ongoing operations, even if it was never formally launched. Indicators include persistent integrations, real data flows, support ownership, access controls, monitoring, and change management. At that point, it needs normal production governance, including rollback and patching.

Q: What is the best way to control access for assistant-built tools?

A: Control access with a dedicated service account, short-lived credentials where possible, and explicit scopes for each tool and API. Bind permissions to what the tool authenticates as, not the person who created it, then add secret rotation, logging, and revocation paths. For higher risk actions, require human approval or step-up controls.

Technical breakdown

How AI coding assistants change the software trust model

AI coding assistants let non-technical staff produce working code without learning the full software development lifecycle. That changes the trust model: code may be useful, but provenance, review depth, dependency choice and runtime context all become less predictable. The central issue is not whether the code is clever, but whether the organisation can determine what it does, what data it touches and who can safely rely on it. See the AI-Generated Code Review Guide.

Practical implication: Treat assistant-generated code as untrusted until it passes the same review, testing and runtime controls as any other internally built tool.

Identity, authentication and authorization for citizen-built tools

When internal builders create their own applications, they still need authenticated access to data, services and distribution paths. That means the resulting tool inherits identity decisions from the surrounding environment, including who may run it, what it can call and whether it can be shared outside the original builder. In practice, the risk is not just the code itself, but the permissions wrapped around it.

Practical implication: Define how citizen-built tools authenticate, what they may access and who owns the credentials or tokens they depend on.

Why validation has to move earlier than human handoff

The article points to a real operating problem: once a useful prototype exists, teams want to share it quickly, but they often lack a lightweight way to establish correctness, safety and supportability. Validation therefore cannot wait for a traditional release cycle. It has to happen while the builder is still exploring how the tool works, what is sent to the model and what parts could be ordinary software instead.

Practical implication: Insert a lightweight validation gate before a local prototype becomes a shared dependency.

Threat narrative

Attacker objective: The relevant objective in this pattern is not external intrusion but uncontrolled spread of internally built AI software that bypasses normal governance.

1. Entry begins when a domain expert builds a tool with Claude Code and starts using it on a local machine for real work.
2. Escalation occurs when that prototype is shared more broadly without a defined review, ownership or deployment path.
3. Impact follows when others depend on the tool and the organisation has to govern its behaviour, data handling and failure modes at production weight.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.

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

Citizen-built software creates a governance gap before it creates a technical one: organisations are now accepting software from people whose primary job is not engineering. That means the control question shifts from can they build it to can the business safely rely on it. The first failure mode is not malicious code, but unmanaged adoption of tools that were never designed for enterprise lifecycle control.

Shadow AI is increasingly a workflow problem, not just an inventory problem: once a local assistant-built tool becomes useful, it can spread informally through a team before security, IT or IAM have seen it. That is why AI IDE and coding agent security matters here: the governance issue is who can move from personal experimentation to shared operational dependency.

Identity controls must extend to the tool itself, not just the person using it: assistant-built applications can carry their own access paths, tokens and data flows, so the question becomes how the tool authenticates and what it is allowed to do. Treating the tool as a first-class identity surface is the only way to keep domain experts productive without creating blind spots in access governance.

The named failure mode is reliance without lifecycle ownership: the article describes the point where a useful prototype becomes something the organisation depends on, but no one has yet accepted responsibility for its QA, hosting, support or retirement. That is the precise governance gap enterprises must close before these tools scale.

AI adoption policies need to distinguish experimentation from operational use: the article shows that early success can mask later control debt. Practitioners should define the moment a local build becomes a managed service, because that handoff is where approval, testing and accountability have to become formal.

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 IDE and Coding Agent Security Guide

What this signals

Shadow AI governance debt: the real exposure appears when a local experiment becomes a shared service before anyone has assigned an owner, a review path or a retirement plan. That is where enterprise controls usually lag behind adoption, and it is the point at which policy has to become operational rather than advisory.

Practitioners should expect more employee-built tools to surface from non-engineering teams, especially where the work is repetitive, domain-specific and hard to justify as a formal software project. The governance response is to make the safe path easier than the shadow path, with clear access, testing and publishing rules.

For practitioners

• Define a shared-to-managed handoff rule Set the threshold at which an assistant-built prototype becomes a governed internal service, including required review, ownership and support commitments.
• Classify assistant-built tools as governed software assets Inventory local AI-built tools that have moved beyond personal use and assign an owner, support path and approval status before wider distribution. See the AI Governance Platform Buyer's Guide.
• Require identity and access review for every shared tool Check what the tool can authenticate to, which credentials it depends on and whether those permissions exceed the builder’s intended use.
• Insert lightweight validation before team rollout Test what data is sent to the model, which steps are deterministic and what failure conditions need human review before others rely on the output.
• Create support and retirement ownership Assign responsibility for hosting, QA, patching and decommissioning so a useful prototype does not become an orphaned dependency.

Key takeaways

• The article shows that AI-assisted building is expanding software creation beyond engineering, which creates a governance gap around how internal tools are validated, shared and owned.
• The biggest risk is not the first prototype but the moment other people start depending on it without lifecycle control, support or access review.
• Enterprises need a clear handoff from experimentation to managed service if they want domain experts to build productively without creating shadow AI dependencies.

Related NHI Mgmt Group resources: AI Coding Agents Security Guide · AI IDE and Coding Agent Security Guide · AI-Generated Code Review Guide · Vibe Coding Policy Template

Key terms

• Claude Code Routine: A Claude Code Routine is a saved configuration that packages a prompt, repositories, and connectors so Claude Code can run automatically in Anthropic-managed cloud infrastructure. It is designed for unattended execution through schedules, APIs, or GitHub events, which makes governance, permissions, and auditability central concerns rather than optional extras.
• Citizen Development: Citizen development is the practice of allowing non-traditional developers to build applications, automations, or workflows using accessible tools. It can improve speed and productivity, but it also introduces governance, access, and data protection risks unless security teams define clear boundaries and review points.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Assistant-generated Code: Code produced by an AI assistant rather than written directly by a developer. It can accelerate delivery, but it still requires normal engineering controls such as review, testing, and ownership. The output should be treated as untrusted until it has been validated against the application’s security and functional requirements.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity and secrets management. It helps security, IAM and platform teams build the controls needed when AI-assisted tools start to behave like business systems.