TL;DR: AI coding tools are enabling non-developers to run shells, call SaaS APIs, install tooling, and deploy public endpoints in minutes, while KonaSense shows that 2020-era DLP and monitoring stacks often miss the composite workflow entirely. The governance gap is now action-based, not tool-based: teams must control what agents and employees can do, not just what they paste.
At a glance
What this is: KonaSense shows that AI coding tools can turn ordinary users into shadow production operators, creating public endpoints and local data exposure paths that legacy DLP does not see.
Why it matters: This matters to IAM and security teams because the control problem shifts from user intent to delegated action, where credentials, local tools, and ephemeral infrastructure are being used in ways traditional governance never modelled.
Context
AI coding assistants now collapse the boundary between user intent and live infrastructure. A person can prompt a local tool to run commands, read files, call services, and publish a public URL without knowing the underlying deployment mechanics, which makes the security problem one of delegated execution rather than simple data transfer.
This is where AI coding assistants and the broader identity governance model intersect: the risky event is not only what data leaves the device, but what the tool is empowered to do with the user’s credentials and local execution context. That is a materially different control problem from classic shadow IT.
Key questions
Q: What is the first control to put in place when AI coding tools can create public endpoints?
A: Start by inventorying the tools and extensions that can execute code or open tunnels on endpoints, then classify which actions they can perform with user credentials. That gives you a practical exposure map before you write new policy or deploy monitoring. Without that baseline, teams usually protect the wrong layer and miss the runtime path entirely.
Q: Why do AI coding workflows create risk even when DLP is active?
A: Because DLP usually watches data leaving known channels, while AI coding workflows can read local files, call APIs, write artifacts, and open tunnels before any obvious exfiltration event occurs. The risk is delegated execution under the user’s authority, which means the sensitive action may happen entirely inside sanctioned tooling and never look like a classic leak.
Q: What breaks when employees can tunnel a local app to the internet with one prompt?
A: The assumption that exposure requires an intentional deployment or an admin-approved hosting workflow breaks down. A local service can become internet-facing in seconds, often with default settings and no authentication. That means directory listings, debug pages, or working files can be reachable long before security teams know a public surface exists.
Q: How should security teams govern shadow AI without blocking productivity?
A: Use visibility-based controls instead of blanket bans. Identify which tools are in use, who is using them, and what data they can access, then apply targeted policies by role and data sensitivity. That approach preserves legitimate AI adoption while reducing exposure from unsanctioned tools and unreviewed data paths.
Technical breakdown
How quick tunnels turn local tools into public services
A quick tunnel such as cloudflared creates an outbound connection from a local process to a public edge service, then maps a random internet-reachable hostname back to localhost. From a network perspective, it looks like an outbound session from an approved device. From a governance perspective, it is a live production surface with no account, no review, and no obvious owner beyond the user who prompted it. The key security issue is that the tunnel inherits whatever the local service exposes, including directory listings, debug routes, sample files, and any sensitive content sitting in the working directory.
Practical implication: Treat one-command tunneling as a production exposure control problem, not as a benign developer convenience.
Why prompt-driven automation breaks old DLP assumptions
Traditional DLP was designed to inspect data moving through known channels, such as email, SaaS uploads, and sanctioned cloud services. AI coding workflows add a hidden layer: the tool can read local files, invoke shell commands, query APIs, and create artifacts before any obvious exfiltration occurs. That means nothing may trip a classic loss-prevention rule even though sensitive data has been processed, transformed, or exposed. The control failure is not only in transport inspection. It is in the fact that the agent is acting with the user’s authority across multiple systems at once. See the AI Coding Agents Security Guide.
Practical implication: Extend monitoring to the agent execution path, not just outbound content and file transfer events.
Why shadow production is different from shadow IT
Shadow IT usually meant uncontrolled use of a third-party app or storage service. Shadow production is more serious because the employee is creating and operating live services, often with corporate data, using sanctioned credentials and local tooling. The output is not merely stored somewhere else. It may be an internet-facing app, a public API, or a background process that persists beyond the session. That changes ownership, blast radius, and incident response. The organization no longer has only an unmanaged destination. It has unmanaged runtime behavior initiated by a legitimate account. See the Shadow AI and AI Agent Discovery Guide.
Practical implication: Add discovery and shutdown controls for user-created runtime assets, not just unauthorised SaaS use.
Threat narrative
Attacker objective: The objective is to create an externally reachable path to local or corporate data and services without triggering the organization’s existing monitoring and approval controls.
- Entry occurs when an employee prompts an AI coding tool to expose a local app, read files, or create a public endpoint from the laptop.
- Credential and execution abuse follow when the tool uses the user’s shell, local tokens, and installed integrations to perform those actions without separate approval.
- Impact occurs when the resulting tunnel, script, or deployed artifact exposes corporate data or operational systems to the internet under an unmanaged surface.
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.
- Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).
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
Shadow production is now a governance category, not a metaphor: AI coding tools let ordinary employees create live services, tunnels, and scripts with corporate credentials and local execution context. That is a different risk class from shadow IT because the user is not just choosing an unsanctioned app, they are operating production-like infrastructure through sanctioned tooling. The control question becomes who can create runtime exposure, not just who can install software.
The blind spot is delegated execution, not data movement: DLP and SaaS monitoring were built to catch content leaving known boundaries, but these workflows can expose data without a classic exfiltration event. The agent reads, transforms, and publishes material on behalf of the user, so the governance problem sits inside the action chain itself. AI coding assistants therefore need the same scrutiny that identity teams apply to high-risk delegated access.
Action-based policy is the only enforceable policy here: organisations cannot govern this category by naming products or broad intent statements. The durable control line is specific actions such as reading credential files, deploying public endpoints, or installing unvetted connectors. That is where policy, detection, and approval must converge for practitioners.
Directory exposure and public tunnelling are the clearest named failure modes: the article shows that the risky state is not a malicious actor but a permissive workflow that turns localhost into internet-facing infrastructure by default. That is a governance failure in exposure management, and it should be treated as such by identity, endpoint, and cloud teams.
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: Secrets Management Guide
What this signals
Action-based governance is the only workable model here: security programs need to stop thinking in terms of approved tools and start thinking in terms of approved actions. When a single prompt can read sensitive files, call SaaS APIs, and publish a service to the public internet, the control boundary has to move to the action itself rather than the application name.
Shadow production will outgrow classic shadow IT detection: the next control gap is unmanaged runtime behavior initiated by legitimate identities. That means discovery must cover local agents, one-command tunnels, and browser-based AI surfaces together, because an endpoint can now become a production asset without ever touching a formal deployment pipeline. The ratio of 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.
Runtime exposure will become an identity governance problem: once AI assistants can operate as delegated executors, entitlement reviews alone will not tell you who can create public reachability or process sensitive data. Teams will need policy that binds specific actions to identity, device state, and execution context before the session creates a lasting external surface.
For practitioners
- Inventory AI coding tools and extensions Identify what is actually running on endpoints, including desktop assistants, IDE plugins, browser extensions, and terminal-based agents. Compare that against formal software inventory because sanctioned rollout lists usually undercount the real footprint.
- Scan for shadow production surfaces Search for externally reachable hosts created through one-command deploy services and tunnels, then cross-reference them with employee identities, internal projects, and business units. Prioritise any surface that returns directory listings or unauthenticated content.
- Instrument the agent execution layer Collect telemetry from the CLI, IDE, and browser surfaces where AI tools act on local files, shell commands, and SaaS integrations. Do not rely on model-endpoint proxies alone because they miss the local execution path.
- Rewrite policy around sensitive actions Replace vague acceptable-use language with specific action controls for reading credential files, invoking production APIs, writing to shared storage, installing unvetted MCP servers, and exposing apps to the public internet.
Key takeaways
- AI coding assistants are creating a new class of shadow production where live services, tunnels, and scripts are spawned from ordinary user prompts.
- The main control failure is not exfiltration detection but delegated execution, because local tools can act on files, credentials, and SaaS integrations before any obvious data loss event.
- Security teams need action-based policy, agent telemetry, and discovery of externally reachable surfaces to govern this risk without blocking legitimate productivity.
Related NHI Mgmt Group resources: AI Coding Agents Security Guide · Secrets Management Guide · Shadow AI and AI Agent Discovery Guide
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, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | Employees using AI coding tools to act with their credentials creates human-driven NHI-style delegation risk. |
| Recommendation — Limit human-directed use of automated tools that can perform sensitive actions under a user’s authority. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centers on tools acting through the user's privileges and local context. |
| Recommendation — Constrain agent privilege inheritance and separate prompt intent from execution authority. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Public tunnels and agent actions depend on over-broad permissions and unmanaged entitlements. |
| Recommendation — Review and restrict entitlements that let local tools deploy services or access sensitive data. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The workflow can expose credentials and create operational impact through uncontrolled public services. |
| Recommendation — Map AI-assisted exposure paths to credential-access and impact techniques in detection engineering. | ||
Key terms
- Shadow Production: Shadow production is the creation or operation of live services, scripts, or infrastructure outside formal change, review, or deployment controls. It differs from shadow IT because the activity produces real runtime assets with operational impact, often using sanctioned credentials and ordinary employee workflows.
- Delegated Execution: Delegated execution is when software is allowed to perform actions on behalf of a user, process, or business function. In NHI governance, the risk is that the delegated actor may chain actions beyond the original intent, so controls must focus on scope, approval, and revocation.
- Public Tunnel: A public tunnel is a network path that makes a local or internal service reachable from outside its original network boundary. It is useful for development and testing, but without policy controls it can expand access far beyond the intended audience.
- Action-Based Policy: Action-based policy defines control requirements by what a user or tool is doing, not by which product they are using. It is more enforceable for AI workflows because the security decision can attach to sensitive actions such as reading credentials, deploying services, or modifying shared data.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps security and identity practitioners turn delegated access into measurable controls across modern environments.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org