AI use and AI security
45 questions on AI use and AI security, in plain language: what to check, what NetSenX shows and what a sensor cannot see.
Shadow AI is the use of AI tools at work without the knowledge or approval of the people responsible for IT, security or data protection. It covers employees using personal chatbot accounts for work tasks, browser extensions with built-in AI, AI features switched on inside existing software, developers running local models or coding assistants, and AI agents connected to company systems. It is usually well-meant: people want to work faster. The risks are concrete. Company or customer data goes to providers you have no contract with, under terms that may allow them to keep or train on it. Personal data may be processed without a legal basis. Outputs enter documents and code without review. And nobody can answer a client or an auditor who asks which AI services touched their data. The answer is not a ban but visibility, an approved alternative and a clear policy. From the Pro plan, NetSenX shows which hosts connect to which AI services and how much data goes there, not what was typed.
Yes, from the Pro plan. NetSenX flags traffic to external AI services and to locally run language-model runtimes, so unapproved AI use becomes visible before it turns into a data-protection issue.
Look at outbound connections to AI services: the destination and the server name in the TLS handshake identify the service without decrypting anything. NetSenX flags this traffic, and traffic to locally run language-model runtimes, from the Pro plan.
Usually more than anyone has listed, and the gap is the point of finding out. A realistic list has four layers: the services you pay for on company accounts; AI features switched on inside software you already use, such as office suites, CRM, helpdesk and design tools; services staff reach with personal accounts in the browser or on desktop apps; and models running locally on laptops, build servers or GPU workstations. Start with what you know, from contracts, card statements and admin consoles, then add what the network shows. Group the results by business function, because finance, sales and development tend to use different tools for different data, and give each service a status: approved, tolerated for non-sensitive data, or to be replaced. The list is the basis for your AI policy, your AI Act literacy training and answers to customers. From the Pro plan, NetSenX shows which hosts reach which external AI services and local model runtimes, when, and how much data goes to each; it does not show what was typed.
You can measure it at the network level, per service and per host, and that number is more useful than it sounds. Volume does not tell you what the data was, but it separates light use, such as short questions and answers, from heavy use, such as whole documents, spreadsheets, code repositories or audio being uploaded. A sudden jump from one host, or a steady stream from a server that should not talk to AI services at all, is a reason to ask. Track it monthly, per business function, next to your list of approved services: rising use of an approved tool is good news; rising use of an unapproved one is a policy gap. Your AI provider's admin console can add per-user detail for business accounts. From the Pro plan, NetSenX shows which hosts reach which AI services, including local model runtimes, and how much data goes to each over time. It never reads the content, so it cannot tell you whether the data was confidential; that judgement comes from the people who own it.
Partly. DNS logs show which hosts look up the domains of known AI services, which is a good start and costs nothing if your resolver already logs queries: export a week of lookups and match them against a list of AI service domains. They miss encrypted DNS that bypasses your resolver, services reached through other domains or content-delivery networks, AI features built into tools you already use, and how much data actually moved. They also show the host, not the person, and a single lookup may come from a browser preloading a page. Treat DNS as the cheap first view and confirm with connection data before you act. NetSenX combines destinations with connection volume and timing, from the Pro plan, so you see which hosts use which AI services, including local model runtimes, and how heavily; it does not see the content of prompts. Pair it with your AI provider's admin logs for the content side.
Yes for the connections, no for the content. A desktop chatbot app, an AI assistant inside a code editor and a command-line tool calling an AI API all have to reach the provider over the network, so the destination, timing and volume are visible just as they are for a browser. That matters because these tools often escape browser-based controls: an extension policy or a web proxy does not see them, and developers' AI assistants can send large parts of a codebase as context. Limits: when the tool talks to a generic cloud endpoint or a company proxy, the AI provider may be hidden behind it; Encrypted Client Hello can hide the server name; and laptops used outside the office are only visible when the agent runs on them. NetSenX shows from the Pro plan which hosts connect to which external AI services and to locally run language-model runtimes, and how much data goes to each, whatever application made the connection; it does not see which file or prompt was sent.
No. The content of the session is encrypted, and NetSenX never decrypts it. It shows that a host used an AI service, when, and how much data it sent; for the content you need the service's own enterprise logs or a data-loss-prevention tool.
No. It is part of the Pro plan and above. The Free plan covers behavioural detection, such as beaconing, scanning and lateral movement, with no time limit.
It depends on where the tool sits, and the answer is worth asking every vendor in writing, because the same label covers very different things. A tool on the endpoint can see which AI applications and browser extensions are installed and sometimes which sites are visited; a DNS-based tool sees lookups of AI domains through the resolver it controls; a browser extension can see pages and, with the right permissions, what is typed into them; a network sensor sees connections to AI services with their volume and timing; and the admin consoles of AI providers show usage on business accounts. None of them alone sees everything. Ask concretely: which source the visibility comes from, whether it sees content or only destinations, whether it covers desktop apps and local models, how it handles encrypted DNS, what it does on unmanaged devices, and what personal data about employees it collects. NetSenX belongs to the network category: from the Pro plan it shows which hosts reach which external AI services and local model runtimes and how much data moves, never what was typed.
It depends less on the service than on the account and the data. The connection is encrypted and large providers run mature security programmes, so the main risks are elsewhere. A personal account is governed by consumer terms: depending on the provider and the settings, conversations may be kept and used to improve models, and the company has no admin view, no data-processing agreement and no way to delete what was shared. A business or enterprise account usually changes that, with contractual limits on training, retention settings, single sign-on, admin controls and audit logs. The other risks are human: confidential or personal data pasted without thought, answers that are confidently wrong, and generated code or text used without review. Practical rules: approved tool on a company account, a short list of data that never goes in, multi-factor authentication (MFA) on the account, and review of outputs before they reach customers. NetSenX shows from the Pro plan which AI services are actually used and how much data goes to them.
Treat an AI service like any other supplier that processes your data, and set it up deliberately. Choose one or two approved services and use business accounts, with single sign-on and multi-factor authentication, so that leavers lose access and admins can see usage. Check the contract: whether your data is used for training, how long it is kept, where it is processed, and whether a data-processing agreement under GDPR is in place. Write a one-page policy with examples of what may and may not go in, and who to ask. Turn on the provider's admin controls, such as retention limits and restrictions on plugins or connectors. Decide how outputs are reviewed before they reach customers or production code. Train people on the policy and on the AI Act's literacy duty. Then check reality: from the Pro plan NetSenX shows which AI services hosts actually use, including unapproved ones and local models, and how much data goes to each, without reading the content.
Start with a policy people can follow: which AI tools are approved, for which data, and through which company account. Then make the approved tool easy to use, because people go around rules that block their work, and a business account with an AI provider usually gives you contractual terms on data use, admin controls and logs that a personal account does not. Explain the reason with concrete examples: customer lists, contracts, source code, salary data and anything under a non-disclosure agreement stay out of unapproved tools. Technical controls follow: data-loss prevention on endpoints or in the browser, a web proxy, and the AI provider's own admin settings. Check the result every month rather than once. NetSenX gives visibility, not blocking: from the Pro plan it shows which hosts talk to which AI services and how much data goes there, so you can see whether the policy works. It does not see what was typed or uploaded.
Blocking alone rarely works: people switch to phones, home networks or other AI tools, and you lose sight of the use, which is the opposite of what you want. Blocklists also lag behind, because new AI services appear every month and many are built into apps you already allow. A clearer path has three parts: a policy on which AI tools are approved and what data may go into them; an approved tool with a business account where there is real demand, so that people have a good alternative; and visibility of what is actually used, reviewed regularly. Blocking still has a place for specific high-risk services, for unmanaged devices on the guest network, or during an incident. NetSenX shows from the Pro plan which AI services hosts on the network connect to, including locally run models, and how much data goes to each; it sees the destination and the volume, not what was typed, and it does not block anything itself.
Start by finding out what is used and why, before writing rules. In most companies the first wave of AI use comes from people solving real problems: drafting e-mails, summarising documents, writing code or translating. A ban drives that use out of sight; an approved tool with clear guidance keeps it visible. Then explain the risks in the terms of people's work: a customer contract pasted into a personal chatbot may break the confidentiality clause; an AI summary can miss the one sentence that matters; generated code can carry vulnerabilities or licence problems. Give a short list of data that never goes into unapproved tools, show how to use the approved one, and name someone to ask. Short, repeated training works better than one long session, and since February 2025 the AI Act requires organisations that use AI to take measures that support their staff's AI literacy. Check progress with facts: from the Pro plan, NetSenX shows which AI services are actually used and how much data goes there.
Compare what the policy allows with what the company actually uses, from three sources. First, the admin consoles of the approved AI services: who has an account, how active it is, which features and connectors are switched on. Second, identity and expense data: sign-ins with company e-mail addresses to services nobody approved, and AI subscriptions on company cards. Third, the network: which devices connect to which AI services, including local model runtimes, and how much data goes to each. A good monthly report shows the approved services and their use, the unapproved ones still in use, and any unusually large transfers, so that the conversation is about facts, not rumours. Keep it about tools and devices rather than individuals unless there is a specific concern, and involve HR or the works council where your country requires it. From the Pro plan, NetSenX gives the network view: hosts, AI services and volumes over time. It does not read what was typed and does not block anything.
Only on an approved business account, and only after checking what the spreadsheet contains. Financial exports often carry more than the analysis needs: customer names and payment terms, salaries, margins, bank details and unpublished results. On a personal account that data sits with a provider you have no contract with, under terms that may allow it to be kept or used for training. On a business account with a data-processing agreement, retention settings and no training on your data, the risk is comparable to other cloud services you already use. Practical rules for a finance team: strip columns the question does not need, aggregate or pseudonymise personal data, never upload unpublished results of a listed company or files under a non-disclosure agreement, and check the AI's figures against the source before they go into a report, because models can compute or copy numbers wrongly. NetSenX shows from the Pro plan which finance hosts reach which AI services and how much data goes there; it does not see the file.
Not from the network alone, and it helps to be honest about that before choosing a tool. Content sent to an AI service is encrypted, so only a control at one of the ends can see it: the admin and audit logs of a business AI account, data-loss prevention in the browser or on the endpoint that recognises customer data patterns, or an interception proxy. Each needs a clear policy, information to staff and, in many countries, involvement of the works council. What the network shows reliably is the context: which devices use which AI services, how often and how much data they send. A sales laptop that sends several megabytes to an unapproved chatbot every day is a reason for a conversation about tools and data, not proof of a breach. Often the best answer is a sanctioned alternative that does the same job on a business account. From the Pro plan, NetSenX shows hosts, AI services and volumes; it never sees the pasted text.
It can be, depending on the data, the account and the terms. Under the GDPR, Regulation (EU) 2016/679, sending personal data to an AI provider is processing that needs a legal basis, transparency towards the people concerned and, where the provider acts on your behalf, a data-processing agreement. Transfers outside the EU need their own safeguards. On a business account with such an agreement and settings that prevent training on your data, use for a defined purpose can be lawful. Pasting customer e-mails into a personal account with consumer terms is harder to justify and may amount to an unauthorised disclosure, which the GDPR treats as a personal data breach; if it is likely to result in a risk to people, the controller must notify the supervisory authority within 72 hours under Article 33. Involve your data protection officer, record what was shared and with which service, and fix the cause with an approved tool. NetSenX shows from the Pro plan which hosts sent data to which AI services, not what the data was.
Rarely as a first step, and never on network data alone. Most unapproved AI use comes from people trying to do their job faster, often because no approved tool exists or the policy was never explained. Dismissal for a first, well-meant breach can be disproportionate under employment law in many EU countries, and it teaches the rest of the staff to hide their use rather than ask. A sounder sequence is: make sure the policy was clear, communicated and reasonable; offer an approved alternative; treat a first breach as a conversation and a recorded warning; and reserve disciplinary steps for deliberate or repeated breaches, or for serious harm such as disclosure of confidential client data. Decide with HR and legal advice, and involve the works council where your country requires it. A network sensor cannot establish who did what: NetSenX shows which device connected to which AI service and how much data moved, which is a starting point for questions, not evidence of a person's intent.
Mainly that company data leaves under terms nobody agreed to, and that nobody can account for it later. Bring-your-own AI covers personal chatbot subscriptions, AI apps on private phones, browser extensions, AI meeting recorders and models run on personal hardware. The data risk: documents, customer details or recordings go to providers with consumer terms, possibly outside the EU, without a data-processing agreement, and stay in personal accounts after the employee leaves. The quality risk: work products built on outputs nobody checked. The compliance risk: you cannot answer a client, an auditor or a data subject who asks where their data went. AI meeting recorders deserve special attention, because they capture other people's voices and words, often without everyone's consent. The practical answer is to offer a good approved tool, say clearly which personal tools may be used for what, and require that meeting recording is announced. From the Pro plan, NetSenX shows which AI services company devices reach; personal phones on mobile data stay outside any network view.
Often more than the chatbots themselves, because of the permissions they ask for. To summarise pages, rewrite e-mails or fill in forms, an AI extension usually needs to read and change everything on every website you visit, which includes webmail, CRM, banking and internal applications. It then sends page content to its own servers or to an AI provider. Some extensions are well run; others are small projects that change hands, get sold or are updated with tracking or malicious code, and the browser installs the update silently. Practical steps: allow extensions only from a managed list through browser policies, review the permissions and the publisher of each, prefer the AI features of your approved tools over extensions, and remove extensions nobody can justify. A network sensor sees an extension's connections to its servers like any other traffic, but cannot tell which extension made them; the inventory belongs in your browser or endpoint management. From the Pro plan, NetSenX shows which hosts reach which AI services and how much data goes there.
If your organisation uses AI systems in its work, Article 4 of the AI Act requires it to take measures to support the AI literacy of its staff, and that duty has applied since 2 February 2025; since July 2026 the amended text states that no specific level has to be guaranteed for each person. Knowing which AI services are actually in use is a practical first step; your legal counsel can tell you what else applies to you.
Partly, yes. Regulation (EU) 2024/1689 gives duties to deployers, meaning organisations that use AI systems in their work, not only to the providers who build them. Since 2 February 2025, Article 4 requires providers and deployers to take measures on the AI literacy of the staff who deal with AI systems; as amended in July 2026 by Regulation (EU) 2026/1744, it asks them to support that literacy without guaranteeing a specific level for each person. The practices banned under Article 5 have also applied since 2 February 2025. Further duties depend on the system's risk category and apply on later dates: a deployer of a high-risk system, for example in recruitment or credit decisions, has obligations on human oversight, monitoring and logs, and some uses carry transparency duties towards the people affected. Using a general chatbot for drafting text is at the light end. A practical start is an inventory of the AI systems you actually use and what you use them for, then training matched to that list. Check the details with legal counsel, because guidance is still being published.
It means the company must take measures that support the AI literacy of the staff who deal with AI systems, and HR is usually the function that organises it. Article 4 of Regulation (EU) 2024/1689 has applied since 2 February 2025 to providers and deployers alike, so it covers ordinary companies that use AI tools; as amended in July 2026 by Regulation (EU) 2026/1744, it states that the company does not have to guarantee a specific level of AI literacy for each person. Good measures still take into account people's technical knowledge, experience, education and training, and the context in which the AI systems are used. Article 4 does not prescribe a certificate, a fixed number of hours or a single course. Practical steps: list the AI systems actually in use and who uses them; define what each group needs to know, from basic risks and the company's policy for everyone to deeper training for those who configure or rely on AI in decisions; keep simple records of who was trained on what and when; and repeat as tools change. NetSenX can help with the first step: from the Pro plan it shows which AI services the company's devices really use.
The ones your people actually use, which is rarely the list in the policy. Start with an inventory: approved services on company accounts, AI features inside software you already pay for, services staff use with personal accounts, and local models on developer or engineering machines. Then match training to use. Everyone needs the basics: what the approved tools are, what data never goes into any AI tool, why answers can be wrong, and how to report a problem. People who use AI on customer or personal data, in finance, HR or sales, need the data protection and confidentiality rules that apply to them. Developers need secure use of coding assistants and agents, including what those tools can access. Managers who rely on AI output in decisions need to understand its limits. Training on tools nobody uses wastes time; skipping the tools in daily use leaves the real risk untouched. From the Pro plan, NetSenX shows which external AI services and local model runtimes the company's devices reach, so the training list matches reality.
In general, no. Article 5 of the AI Act, Regulation (EU) 2024/1689, prohibits placing on the market, putting into service or using AI systems to infer the emotions of a natural person in the workplace and in education institutions, except where the system is intended for medical or safety reasons. The ban has applied since 2 February 2025. It covers tools that read emotions or intentions from faces, voices, typing or other biometric signals, for example in call-centre software, video-meeting add-ons or productivity monitoring, and fines for prohibited practices are the highest in the Act. Employment and data protection law add their own limits on monitoring staff. Before buying any tool that claims to measure engagement, stress or sentiment of employees, ask the vendor in writing which data it uses and how it fits Article 5, and involve your legal adviser and data protection officer. NetSenX does not do this: it monitors devices and network connections, never people, and makes no assessment of individuals.
With a specific, checkable answer rather than a reassurance. Clients and their procurement teams increasingly ask which AI services touch their data, under which terms, and with which controls. A good answer names the approved AI services and how they are contracted, for example business accounts with no training on your inputs, a data-processing agreement and stated processing locations; says which client data may and may not go into them; describes the controls, such as the AI policy, staff training, access restrictions and review of outputs; and explains how you check that practice matches the policy. If the honest answer today is that you do not know, say what you are doing to find out and by when, rather than promising something you cannot show. Keep the answer consistent with your contracts and your records of processing. From the Pro plan, NetSenX shows which AI services your company's devices actually reach and how much data goes to each, so the answer to the client is backed by your own traffic rather than by assumptions; it does not show which client's data was involved.
Often yes, at least as a commitment the client can rely on, but keep the contract shorter than the policy. Clients increasingly add clauses on AI: no use of their data to train models, no processing by AI services outside agreed sub-processors or regions, disclosure when deliverables are AI-assisted, and notification if their data was exposed through an AI tool. Rather than attaching your whole internal policy, which changes often, commit to a few stable principles in the contract or the data-processing agreement, list the AI services that process client data as sub-processors where they do, and refer to the policy as maintained by you. Make sure you can keep every promise in practice: a clause saying no client data ever goes into AI tools is worthless if staff use personal chatbot accounts and you cannot see it. Agree on what counts as AI-assisted work, because most office software now has AI features. Have the wording reviewed by legal counsel. From the Pro plan, NetSenX shows which AI services your devices actually reach, a useful check before you sign such a clause.
Look for the services that local model runtimes expose and for the traffic around them. Tools that run language models locally usually start an HTTP API on a known default port, offer a web interface, and download large model files from public model hubs when first set up. So three checks help: an authorised scan of internal ranges for the default ports of common runtimes and for unexpected web interfaces; a look at which machines downloaded multi-gigabyte files from model repositories; and a list of hosts with powerful GPUs, which IT often already knows. Then ask the owners what each server is for, who can reach it and what data goes into it. Many are harmless experiments; some are left open to the whole network without authentication. NetSenX shows from the Pro plan traffic to locally run language-model runtimes: which host runs or calls one and how much data moves, alongside external AI services. It does not see the prompts or the model's answers.
It can be, mostly through ordinary misconfiguration rather than anything exotic. Keeping data on your own hardware avoids sending it to an outside provider, which is a real advantage. The risks are the usual ones for a new server nobody planned: the API or web interface often listens on all interfaces without authentication, so anyone on the network can use the model, read conversation history or upload files; the server runs unpatched software that changes quickly; model files downloaded from public hubs can contain malicious code if they use unsafe formats; and documents fed into it for retrieval may be readable by everyone who can reach it. Treat it like any internal service: a named owner, authentication, binding to localhost or a restricted segment, updates, safe model formats from trusted sources, and a decision on which data may go in. From the Pro plan, NetSenX shows which hosts run or call local language-model runtimes and how much data moves, and its core detections flag scanning or lateral movement from that host on every plan.
It is the risk that a model, dataset or AI library you download or buy is compromised, misrepresented or simply not what you think. Public model hubs host hundreds of thousands of models uploaded by anyone. Some model file formats can execute code when loaded, so a malicious model can compromise the machine that opens it; safer formats exist and should be preferred. A model can be fine-tuned to behave normally except on a hidden trigger, or trained on poisoned data. Names can be copied to look like a well-known publisher's model. And the libraries and plugins around models, such as runtimes, connectors and agent frameworks, change fast and carry ordinary software vulnerabilities. Practical steps: take models only from publishers you can verify, check signatures or hashes where they are published, use safe file formats, run new models in an isolated environment first, keep an inventory of models and versions in use, and patch the surrounding software like any other. A network sensor sees large model downloads and which hosts run model runtimes; it cannot inspect a model's weights.
It can be, in the same ways as code copied from the internet, only faster and in larger amounts. Coding assistants produce code that looks plausible and usually works, but may contain known vulnerability patterns such as injection flaws, weak cryptography or missing input checks; may call packages that do not exist, which attackers then register under that name with malicious content; may reproduce code under a licence your product cannot accept; and may embed secrets from examples. The tools themselves also send source code to the provider as context, so the choice of service and account matters for confidentiality. Treat AI output like a junior colleague's pull request: the same code review, automated security tests, dependency and licence scanning, and secret detection in the pipeline, with the developer remaining responsible. Decide which repositories may be shared with which assistant. From the Pro plan, NetSenX shows which developer machines and build servers send data to which AI services and how much; it cannot judge the quality of the code.
Prompt injection is an attack in which text that an AI system reads is written to make it ignore its instructions and do something else. Direct injection comes from the user typing it. Indirect injection is the more serious kind for companies: the instruction hides in content the AI processes on someone's behalf, such as a web page, an e-mail, a shared document or a support ticket, and the model follows it as if it came from its operator. If the AI can only answer in a chat window, the damage is limited to a wrong or embarrassing answer. If it can read a mailbox, call tools, query a database or browse, an injected instruction can make it leak data or take actions. There is no complete fix today, because models do not reliably separate instructions from data. What helps: give AI tools the fewest permissions possible, require human approval for actions with consequences, keep sensitive systems out of reach of agents that read untrusted content, and log what the AI did. OWASP lists prompt injection first among risks for LLM applications.
It is a list of the most important security risks for applications built on large language models (LLMs), published by the Open Worldwide Application Security Project (OWASP), the community behind the well-known web application Top 10. The 2025 edition names prompt injection, sensitive information disclosure, supply-chain risks, data and model poisoning, improper output handling, excessive agency, system prompt leakage, weaknesses in vector databases and embeddings, misinformation, and unbounded consumption of resources. For a company that only uses AI tools, three items matter most: sensitive information disclosure, which is the shadow-AI problem; excessive agency, meaning AI agents with more permissions than they need; and prompt injection, which turns any document or web page an agent reads into a possible attack. For a company that builds AI features into its own product, the whole list is a sensible checklist for design reviews and tests, and a common vocabulary for customers' security questionnaires. It is guidance, not a standard or a certification.
Design so that the model only sees what the task needs, and assume that anything it sees can come back out. Concretely: choose a deployment with contractual terms that fit your data, such as an enterprise API with no training on inputs, a defined retention period and processing in the EU where required, or a model you host yourself; minimise and pseudonymise what goes into prompts; in retrieval systems, enforce the user's own access rights on the documents the model may retrieve, so it cannot summarise files the user is not allowed to open; keep secrets, keys and system credentials out of prompts and context; filter outputs for personal data and secrets before they reach users or logs; limit what tools the model can call and require approval for actions; and log prompts and responses in a protected way for investigation, with retention set to match. Test against prompt injection and data-extraction attempts before launch and after each change. From the Pro plan, NetSenX shows which servers send data to which external AI services and how much, which helps confirm that production traffic goes only where the design says.
The Model Context Protocol (MCP) is an open protocol, introduced by Anthropic in November 2024 and since adopted widely, that lets AI assistants and agents connect to tools and data sources in a standard way. An MCP server exposes capabilities, such as reading files, querying a database, searching a ticket system or sending messages, and an AI client calls them when a task needs them. That makes AI far more useful, and it also turns each MCP server into a gateway: whatever it can reach, the AI can reach, with the permissions of the account behind it. Security questions follow directly. Who installed the server and from where? Which credentials does it hold, and how broad are they? Does it run locally on a laptop or as a remote service? Does it require approval before acting? Is it logged? Treat MCP servers as software with privileged access: approve them, scope their tokens narrowly, keep them updated, and prefer servers from verified publishers. A network sensor sees remote MCP servers as connections to their hosts; local ones on a laptop stay out of its view.
A shadow MCP server is a Model Context Protocol server that someone connected to an AI assistant without IT knowing, usually to save time: a connector to the company mailbox, a file share, a code repository, a database or a ticketing tool, installed from a public listing or written in an afternoon. The risk is that it quietly creates a new access path. It often holds a personal access token or API key with broad rights, stored in a configuration file on a laptop; it may come from an unknown author and update itself; it lets the AI act on company systems with that person's permissions; and anything the AI reads, including a malicious instruction hidden in a document or web page, can steer what it does through that connector. Nobody reviews or logs it, and it survives the employee's departure if the token is not revoked. Practical steps: publish an approved list of MCP servers, scope tokens narrowly and rotate them, check identity-provider logs for new OAuth grants to AI clients, and include connectors in offboarding. A network sensor sees connections from a laptop to remote services, not the MCP configuration on it.
Look where agents get their power: identities, connectors and automation platforms, then confirm with network traffic. An AI agent is software that uses a language model to decide on and carry out steps, such as reading tickets, querying systems, writing code or sending e-mails, usually through API keys, service accounts or OAuth grants. So the best first sources are your identity provider and SaaS admin consoles: new OAuth applications with broad scopes, service accounts or personal tokens created recently, and AI features with connectors switched on. Then check automation and low-code platforms, CI pipelines and developer machines for agent frameworks and MCP servers, and ask teams directly, because many agents are pilots nobody has registered. The network adds the behavioural view: which servers or workstations call AI APIs regularly, at night or in bursts, and which also reach internal systems. From the Pro plan, NetSenX shows which hosts talk to which external AI services and local model runtimes and how much data moves. It does not identify an agent by name, and the agent-specific behaviour signals described elsewhere are not yet alerts.
Yes, and usually with tighter controls than a human with the same rights. An agent acts at machine speed, does not get tired or suspicious, can be steered by text it reads, and often runs with a token that never expires. So give each agent its own identity rather than a person's account, grant only the permissions the task needs, prefer read-only access, separate environments so a test agent cannot touch production, require human approval for payments, deletions, external messages and permission changes, set expiry and rotation on its credentials, and log every action it takes in a place it cannot alter. Review agents in the same access reviews as service accounts and include them in offboarding. The cost of skipping this is concrete: IBM's Cost of a Data Breach Report 2025 found that 13% of organisations reported breaches of AI models or applications, and 97% of those reported lacking proper AI access controls. On the network side, NetSenX detects on every plan the behaviour that a misused identity shows, such as lateral movement and unusual uploads, from whichever host the agent runs on.
Yes, and without anyone intending it. An agent with access to a CRM, a mailbox or a shared drive can be asked, or tricked through an instruction hidden in a document, an e-mail or a web page it reads, to summarise, forward or upload data far beyond what its task needs. Common routes are an agent that answers external messages and includes internal data in the reply, an agent that can send e-mail or post to external services, a coding agent that pushes code with embedded secrets to a public repository, and an agent whose logs or memory keep customer data where nobody expects it. The fix is scope: only the data the task needs, no outbound channels unless required, human approval before anything leaves the company, and separation between agents that read untrusted content and those that hold sensitive access. Test these paths before go-live. On every plan, NetSenX detects unusual outbound data volume from a host, whatever process caused it, and from the Pro plan it shows which AI services the host talks to; it does not see what the agent sent.
Partly today, and NetSenX is explicit about which part. What is live: from the Pro plan, traffic from a host to external AI services and to locally run language-model runtimes, with timing and volume; and on every plan, the behaviours a misused agent would share with any compromised host, such as reaching many internal systems it never used before, scanning, regular check-ins to an unknown server, and unusual outbound data volume. What is not live: signals aimed specifically at agents, such as actions at machine tempo right after a language-model call, or a first connection to a new destination that follows a model response. NetSenX measures those in shadow mode, without raising alerts, until they are reliable enough to be useful; they should not be presented or relied on as detections. The stronger controls sit elsewhere: narrow permissions, human approval for consequential actions, and the agent's own action logs. A network sensor also never sees which instruction made the agent act.
Mostly to do familiar attacks faster, cheaper and in better language, not to invent new ones. Phishing e-mails no longer give themselves away with clumsy grammar, and they can be tailored to your company from public information in a few minutes. Voice cloning and deepfake video make fake calls from a manager or supplier more convincing. Attackers use AI to write and vary scripts, to research targets and to sort stolen data quickly. That changes the defence in two ways. Controls that relied on spotting bad writing or an odd tone lose value, so processes must not depend on recognising a fake: confirm payment changes through a known channel, use phishing-resistant multi-factor authentication, and limit what one stolen account can reach. And the steps after the first foothold still look the same on the network, whoever or whatever wrote the tools: a device checking in with an unknown server, scanning, lateral movement and data leaving. NetSenX detects those behaviours on every plan, Free included, without needing to recognise the malware or the message that started it.
Yes, and the defence is a process, not a technology. With a few minutes of public audio or video, an attacker can imitate a manager's or supplier's voice and face well enough to pass on a phone or video call, especially under time pressure. In early 2024, police in Hong Kong described a case in which an employee of a multinational company transferred large sums after a video conference in which the other participants, including a senior manager, were deepfakes. Protection: a rule that no payment, change of bank details or urgent transfer is approved on a call or message alone; confirmation through a separate channel you already know, such as a call back to the number on file, never the one given in the request; two people to approve payments above a threshold; a code word for genuine urgent requests if you want one; and staff who know they will be backed for slowing a payment down. No network sensor can tell a real voice from a fake one. NetSenX is not the answer here: it does not analyse calls or video, and it does not see payment instructions.