Unmanaged IA in the corporate environment generates internal risks and requires governance

A problem operating in many organizations is no longer in the hands of external attackers alone: they are the unmanaged IA agents that employees install or use in workstations and servers, with access to credentials and internal systems without formal supervision. According to a 2026 Bitdefender report only 51.8% of organizations say they have complete visibility of the IA tools that use their templates; and, in another study cited by security companies, IBM has noted that about 20% of the intrusions have involved "Shadow AI" as a commitment vector. These figures - while depending on how these terms are defined and measured - point to an operational gap: a lot of useful IA for work can also become an internal risk if there are no controls.

Technically, how do these risks appear in the corporate network? There are several recurring patterns: code assistants and browser extensions that ask for or store API keys, local agents that manage automated tasks and private model servers (MCP) configured by development teams. Many of these components communicate directly with cloud services using HTTPS and temporary tokens, skipping business proxies, or function as user processes that traditional network solutions do not classify as risks. The key risk is that a software piece with credentials and no defined human owner acts, from a security point of view, as an unsupervised employee.: you can access databases, call internal APIs and exfilter information.

This is for practical reasons: the IA tools promise productivity and automation, so users and equipment oppressing deadlines adopt "fast" solutions - browser extensions, third party integrations, or agents that store login - without going through purchase processes or security. In addition, the tendency to use APIs of hosted models implies that the flow of critical data can go directly from the endpoint to the IA provider, complicating the detection and control by security teams that depend mainly on network inspection or corporate application lists.

The real consequences are several and not purely theoretical. In the short term, an unmanaged IA can filter secrets (API keys, database passwords), cause intellectual property leaks to cloud model providers, or run unauthorized commands that compromise internal systems. In the medium and long term, this increases regulatory compliance and contractual exposures with customers: access controls and data-processing contracts may be violated if sensitive data are sent to external services. In addition, from an operational point of view, the presence of self-governing agents without control complicates the forensic investigation and response to incidents.

It is important to separate the confirmed from the estimated. Confirmed: security companies and some research (e.g. public reports from suppliers such as Bitdefender) document the appearance of attendees and IA agents in endpoints and report metrics on limited visibility. Estimated / Probable: the exact extension of exfiltration or the number of direct gaps attributable exclusively to IA agents may vary between reporting sectors and methodologies. Uncertain: the precise proportion of malicious agents against poorly configured benign agents is not something that can be generalized without published forensic studies in detail.

What concrete measures should be taken by security teams, especially those with limited resources? Here is a practical order of steps that can be implemented in weeks or months, with tactical and technical priority.

1) Detecting and inventing: enable telemetry in endpoints and record outgoing processes and connections. If you already have EDR / endpoint telemetry, look for unknown processes that make TLS connections to model providers or open unusual sockets. If you do not have EDR, start with software inventories using MDM or asset management tools and passive network scanning.

2) Control of credentials and secrets: prohibit key storage in local files or in unencrypted environment variables. Implement a secret manager (vault) and make sure that the integrations use temporary roles and automatic tokens rotation. Restrict the use of long-term keys and implement minimum access policies.

3) Output filter and TLS visibility: consider TLS inspection where legally and technically feasible, or display proxies that force the traffic of IA APIs by corporate gateways. For environments where inspection is not possible, record connection metadata (SNI, destination IPs, traffic volumes) to identify unusual patterns.

(4) Adoption governance: instead of blocking all IA (which usually fails by adoption of Shadow IT), define a list of approved tools, provide safe alternatives (e.g. corporate integrations with managed keys) and create agile approval processes for the equipment to incorporate new tools without breaking controls.

(5) Data policies and DLP: apply data loss prevention in endpoints and mail, with specific rules to detect exfiltered data to IA platforms (search for formats, sensitive data patterns). Combine this with data and policy classification that limit which information can be processed outside the corporate perimeter.

6) Identity and conditional access: protect critical resources with multifactor authentication, privileged identity management and conditional access policies that evaluate the context of the device and the app. Check tokens if you find abnormal use and automate rotations before detection.

7) Continuous response and monitoring: integrate alerts in SIEM / SOAR for behavior of IA agents: spikes of calls to external APIs, night access to databases from development endpoints, or executions of unauthorized processes. Establish playbooks to revoke credentials, isolate machines and collect forensic devices.

For reduced equipment, priority is given to: visibility (inventory), protection of secrets (vault and rotation), and access controls (MFA / temporary roles). These are high-impact levers with moderate investment. In the medium term, accompany with user training and a governance process that facilitates safe use rather than prescribing absolute prohibitions.

If you want sources and reference frameworks to design controls, see public guides such as the NIST AI Risk Management Framework for governance principles and practices ( https: / / www.nist.gov / itl / ai), and the resources for response to gaps and data protection of leading suppliers ( https: / / www.bitdefender.com /, https: / / www.ibm.com / security / data-break).

In short, the threat is not only that attackers use IA, but that the IA useful for the organization may be acting with the same power as an unsupervised employee. The most effective solution combines technical detection, secret management, access policies and a governance framework that will enable IA to be used without giving in to data control. For security officials, the immediate priority is to recover visibility and protect credentials: the rest is governance and operational culture.