Most security teams have started with discovery, building a list of which AI apps are installed across the fleet. That list is a useful first step, but it can’t tell you which app is acting right now, what it touched, or how to stop it.

This guide covers the risks specific to mobile, how to detect AI agents on iOS and Android, and how to build an audit trail your DPO and auditors can rely on. Later in this guide, we’re also upfront about where mobile visibility ends, so you can plan around it.

What are shadow AI agents?

Shadow AI is usually pictured as an employee pasting a document into an unapproved chatbot, and our earlier post on shadow AI on mobile looked at how much of that AI traffic is already moving across mobile fleets. Shadow AI agents go further: they read, decide, and act across company systems using the employee’s own access, with nobody reviewing each step.

The scale of the wider problem is already clear, and Gartner has predicted that by 2030 more than 40% of global organisations will suffer security and compliance incidents due to the use of unauthorised AI tools, a forecast reported by Infosecurity Magazine.

Agents are the sharpest edge of the broader AI governance challenge, because the risk sits in what the software does once it has access, rather than in whether someone typed a prompt.

Why AI agents are hardest to see on mobile

AI arrives inside ordinary apps

Keyboards, document scanners, transcription tools, and note apps increasingly call model APIs directly. None of them appear as “AI apps” on an inventory, and a silent update can add AI to an app that was harmless last week. A static scan of installed software will miss both.

Agents work at machine speed

An agent can read a mailbox, open a file, and upload it in under two seconds. A weekly usage report finds out after the data has already gone, which leaves security teams investigating incidents they had no chance to prevent.

An app that could act is different from one that is acting

Some tools flag every app with permissions that would let it behave as an agent. On Android, for example, accessibility permissions allow an app to read the screen and drive other apps, which is why apps that over-reach on permissions already carry risk. Flagging capability produces a list of suspects. Security teams need to know which app is acting at this moment, and they need a way to stop it.

Five agentic AI security risks to plan for

The risks below are where general AI agent security guidance meets the realities of a mobile fleet.

• Data leaves for unapproved AI services: An agent can pull email, files, or customer records and send them to a model or storage service your organisation has never assessed, which is the problem mobile data loss prevention is designed to address.
• Agents inherit corporate access: An agent working through an app the employee has signed in to Microsoft 365 can reach whatever mail and files that app has been granted, without IT approving anything new.
• Risk can change with an update: An approved app can start talking to a model after an update, so a one-off review of the app catalogue quickly goes out of date.
• Personal and corporate data mix: On BYOD devices, the same phone carries personal messaging, banking, and work email, which makes broad monitoring both intrusive and hard to justify to employees.
• There is no evidence trail: When an agent acts in seconds and leaves no record of what it touched, incident response, audits, and regulatory questions all start from guesswork.

Why an AI app inventory falls short

Discovery answers the first question security teams ask. Runtime control answers the questions that follow.

How to detect AI agents on iOS and Android

Agents leave a recognisable pattern in network behaviour. They loop rapidly between a model and company services, they act while the screen is off, and they work at a pace no human thumb could manage. Because detection looks at behaviour, it can catch an agent inside an app that was never labelled as AI.

Corrata Agent Shield detects and stops AI agents on mobile by reading that pattern on the device, tying each connection to the app that made it, and scoring every session Human, Assisted, or Autonomous in milliseconds.

To make this concrete, consider an illustrative session on an Android phone in a field sales team (the app and data are fictional). A note-taking app sends a short prompt to a model API, reads 48 KB of mail from Exchange, sends a larger prompt, reads a 1.8 MB file from SharePoint, and then attempts a 2.1 MB upload to unapproved storage. Those five actions take 1.4 seconds with accessibility switched on. Agent Shield scores the session Autonomous, blocks the upload, and pauses the session.

What to do when an agent is active

Blocking all AI rarely holds, because employees find workarounds on personal apps and devices. Proportionate responses keep approved AI useful while closing the routes that put data at risk.

• Copilot and your other sanctioned tools can keep working, while uploads to unapproved AI services are blocked or capped by size, app, and user group through the Corrata Advanced DLP controls that power Agent Shield’s guardrails.
• When an autonomous session reaches for email, files, or finance apps, Corrata can pause it and ask the employee on their phone whether it was them. One tap lets the session continue, and without that tap no data moves.
• A device running an unapproved agent can be marked non-compliant in Microsoft Intune, so conditional access cuts Microsoft 365 until the issue is resolved, without adding another console for your team to learn.

Building an AI agent audit trail

Every autonomous session in Agent Shield produces an Agent Receipt, a timeline showing which app acted, which AI service it used, which company systems it touched, how much data moved, and what action Corrata took.

Receipts can flow to your SIEM and to Intune, so they sit alongside the rest of your security evidence. For compliance teams, that record supports conversations with auditors, your DPO, and evidence gathering for the EU AI Act.

Governing AI agents without reading employees’ messages

Agent Shield works on metadata, analysed on the device. It knows an agent moved 2 MB to an unapproved service, and it has no view of what those 2 MB contained. There are no certificates to install, no TLS interception, and no broken certificate pinning, and only verdicts and receipts reach the console.

This approach, which we describe in more detail in our page on privacy by architecture, is built for works council and DPO review. It is BYOD friendly, personal app traffic can be excluded by policy, and Corrata is ISO 27001 certified and EU native, so your AI governance data stays in the EU.

What no mobile security tool can see

No tool has total AI visibility on mobile. AI that runs entirely on the device sends no traffic, the iOS sandbox stops any third party watching one app drive another, platform assistants such as Siri and Gemini run partly on Apple and Google infrastructure, and cloud agents in a remote browser never touch the phone. The Agent Shield page sets out where its visibility ends and how to plan around each gap.

Five steps to bring AI agents on mobile under control

1. Agree which AI tools are approved, and give employees a sanctioned route to use them so they have less reason to look elsewhere.
2. Identify every app on your fleet that communicates with a model, including AI added to ordinary apps through updates.
3. Monitor sessions for agent behaviour, since an installed app tells you far less than what that app is doing.
4. Set proportionate responses that range from asking the user to blocking uploads and cutting Microsoft 365 access.
5. Keep a receipt for every autonomous session, and explain to employees what you can and can’t see, which is central to employee buy-in on BYOD devices.

See it catch a live agent

The quickest way to judge any AI agent security claim is to watch it work. Book a demo and we’ll run an AI agent on a test phone while you watch Agent Shield detect it, score the session, and produce the receipt.

The post Agentic AI security risks on employee phones appeared first on Corrata.

Most advice about spotting a scam says to look at the writing, check the spelling, watch for the odd phrasing, see whether the greeting fits, and so on. That advice worked for twenty years, and it worked for a reason that had nothing to do with detecting dishonesty. Scam messages were written at volume by people operating in a second or third language, and the errors were a by-product of cheap production.

The FBI stated the consequence in a December 2024 warning, noting that generative AI tools “correct for human errors that might otherwise serve as warning signs of fraud”.

The signal that advice depends on has been removed at the source. 

What are AI scams?

An AI scam is any fraud where generative AI produces or personalises the deception. It can be text from a language model, cloned voice, synthetic video, fabricated documents.

The crime is unchanged. What changed is the unit economics, which is the part that should interest you, because your controls were sized against the old ones.

A team at Harvard Kennedy School measured it. Generic scam mail achieved a 12% click-through rate against their participants. Emails written by human experts using established persuasion techniques reached 54%. Emails researched, written, and sent by an automated tool, with no human in the loop, also reached 54%. Cost per target, including reconnaissance: roughly four cents.

Spear phishing used to be rationed. Research time only paid off against a valuable target, so most of your inbound was generic and most of your workforce was protected by their own unimportance. That is no longer true. Every person on your org chart is now worth a tailored approach, and the org chart is public.

One implication for how you triage: A message of a quality that once indicated a well-resourced actor no longer tells you anything about attribution.

Types of AI scams your controls need to survive

Business email compromise: Still the costliest category. The FBI’s 2025 Internet Crime Report puts losses above $3 billion. No payload, no malicious link, nothing for a gateway to match on. The control is your payment approval process, not your mail filter.

Voice cloning: Used to stage urgency, or to clear telephone-based verification. The same report was the first in twenty-five years to break out AI as a category, logging around $893 million, and the Bureau notes this understates the position because victims rarely recognise AI involvement.

Deepfake video: Microsoft’s 2025 Digital Defense Report recorded a 195% global rise in AI-generated identity forgeries, now convincing enough to defeat liveness checks. If any approval in your environment rests on seeing a face, that approval is weaker than your documentation says.

Service desk impersonation: In both directions, to obtain a credential or a reset.

How to prevent AI scams when the message is unreadable

Accept first that you cannot detect AI-generated text by reading it, and neither can your staff. The Harvard researchers concluded that what separates an excellent fraudulent message from an excellent legitimate one is mainly the sender’s intention.

So move the judgement off the writing and onto the request. Four questions worth embedding in process rather than training:

• Does this move money, change payment details, share a credential or grant access?
• Is it applying time pressure, and would delay actually cost anything?
• Is it routing around the normal process?
• Does it match what this person normally asks for?

And four controls that hold, because none of them depend on anyone judging a message correctly.

• Verify through a channel you established, never one supplied in the message. This is the single control that survives a cloned voice, a spoofed sender and a live deepfake at once.
• Use phishing-resistant MFA, passkeys and hardware keys. SMS codes are relayable in real time.
• Bank details, payroll, and credentials must be confirmed by a second person through a second route.
• Assume the attacker has the org chart. Familiarity is not authentication. If your training implies otherwise, that is now a liability.

None of that is new to you. What is new is that these have moved from good hygiene to load-bearing, because the perceptual layer above them has gone.

Where the residual exposure sits

IBM’s 2026 Cost of a Data Breach report has phishing as the most common initial attack vector for the fourth consecutive year. Its voice and SMS variants carried the highest average breach cost of any initial vector, at $5.29 million. The most expensive way into an organisation now arrives on a phone.

Your stack was built around email and the corporate network. A lure delivered by text message, QR code, messaging app or browser link lands on a device with no gateway in front of it deciding what is allowed through, on the endpoint most likely to be personal, checked in a queue and read quickly. You probably have MDM there. MDM manages configuration. It does not inspect what arrives.

There is a second problem, and it applies to the tooling you do have. Reputation and blocklist approaches lag a destination generated once for one recipient. Corrata’s own detection data shows the decay rate: across customer mobile fleets, 69% of the AI service domains observed had never been seen before. Those were legitimate services, not attack infrastructure, which is what makes the point cleanly. A list that cannot keep pace with software that is not hiding will not keep pace with a lure built to be new.

Corrata inspects traffic on the device itself, at the network layer where traffic from every app converges. Coverage does not depend on which channel the lure arrives through. Detection works from what a connection is doing rather than from a catalogue of what has been seen before, and it reads traffic characteristics rather than message content, so the workforce is covered without anyone reading their messages.

Conclusion

The messages improved because a cost constraint disappeared. Your perceptual defences were built on that constraint, and no amount of additional vigilance restores a signal that no longer exists.

Two things follow. Your procedural controls and AI governance have to carry more weight than they were designed to. And the surface where the most expensive of these lures now lands is the one you have the least visibility into.

Book a demo to see what is currently reaching your mobile fleet.

The post AI Wrote the Scam Text, and it is Better Than the Last One appeared first on Corrata.

Most organisations did not actively decide to adopt AI. They discovered that they already had. A marketing team starts drafting campaign copy in a consumer chatbot. A developer connects a coding assistant to a repository holding proprietary logic. A recruitment platform quietly ships a new candidate-ranking feature.

We spent six weeks measuring what this looks like in practice by inspecting AI traffic across our customers’ mobile fleets. 84% of those customers had AI traffic on the fleet, and 69% of the AI domains we detected were ones we had never seen before. Most of that activity never reaches the tools security teams already run.

This is the gap AI governance exists to close. Adoption has outpaced oversight, and the systems now shaping consequential decisions were often introduced with no risk assessment, no owner, and no record that they exist at all. This guide covers what governance is, why it matters, the frameworks in use, what a working programme needs, and where the AI you don’t know about is most likely to be hiding.

What is AI governance?

AI governance is the set of policies, processes, roles and controls an organisation uses to make sure its AI systems stay lawful, safe, transparent, accountable and aligned with business goals. Artificial intelligence governance means the same thing. It covers everything applied as AI is built, bought, deployed and monitored, from the decision to use AI at all through to the day a system is retired.

It answers four questions on a continuing basis. Which AI systems do we have? Who is accountable for each one? What could go wrong? And how would we know if it did?

A policy that says AI must be used ethically creates no capability. Governance is the machinery that turns that intent into evidence. It means an inventory that is up to date, and a review step a system cannot skip on its way to production. It means monitoring that catches drift, and an escalation path that works at 4 PM on a Friday.

How AI governance relates to adjacent disciplines

These terms get used interchangeably in vendor material, which causes real confusion in procurement conversations. They are distinct.

• AI ethics: What an organisation should and should not build or use. It supplies the values that governance turns into rules.
• Responsible AI: The practice of building and running AI to meet those values. Governance is what makes it repeatable rather than dependent on individuals.
• AI risk management: Finding, judging, treating and tracking AI-specific risks. It is a core function inside governance, not a substitute for it.
• AI security: Protecting AI systems and their data from attack and accident. It covers prompt injection, model theft, data exfiltration and supply chain risk.
• Data governance: Where data came from, how good it is, and what it may be used for. Without it, AI governance cannot be enforced.

The practical implication is that AI governance should extend existing structures rather than replace them. Build a parallel stack alongside security, privacy and model risk, and you get duplicated evidence, clashing approvals, and a programme nobody outside the governance team can navigate.

Why is AI governance important?

Managing risk before it becomes an incident

AI risk is not hypothetical. Recruitment tools have learned gender preferences from past hiring data. Chatbots have committed organisations to refund terms they never meant to offer. Legal filings have reached court citing cases that a generative tool simply invented.

Each of those was a governance failure, not a technical one. The system worked as designed. What was missing was a human check sized to the stakes of the output.

Protecting sensitive data at the point of use

Data leakage into AI tools is now one of the most common ways confidential information leaves an organisation. Cisco’s 2026 Data Privacy Benchmark Study found that more than half of employees admitted typing non-public company information into generative AI tools. Close to a third had entered details about customers or colleagues.

Most consumer AI services carry no data processing agreement, no retention commitment and no data residency guarantee. Consider an employee subject to GDPR who pastes customer records into a personal chatbot account. They have just sent personal data to a third party, possibly across a border, with no lawful basis and no record of it.

Governance works at three levels here. First, a sanctioned toolset with contractual protections in place. Second, technical controls that show security teams which AI services are actually in use. Third, classification rules that set out what may be sent where.

Preventing bias and unfair outcomes

Bias in AI is rarely deliberate. It is usually inherited from training data that reflects historical patterns. It can also enter through proxy variables that track protected characteristics.

Governance turns fairness from an intention into a measurement. That means agreed fairness metrics for the context, testing before deployment, monitoring for unequal outcomes afterwards, and a documented route to fix problems.

The same logic applies to explainability, and the requirement scales with consequence. Where a decision materially affects someone, you need to be able to say in plain language what drove that outcome. Build that in from the start. It cannot be bolted on after a complaint arrives.

Creating accountability for AI decisions

The most damaging gap is diffuse ownership. A model gets built by data science, deployed by platform engineering, embedded in a product owned by a business line, and bought through a vendor. Accountability can dissolve at every handover. Governance names one accountable owner per system, and that person answers for how it behaves regardless of who built it.

Enabling AI to scale

The strongest argument for governance is commercial rather than defensive. During experimentation, exposure is small and governance feels like friction. The calculation changes when AI is used in revenue, hiring, credit, clinical or safety-related workflows. In these cases, the system becomes load-bearing.

At that point, organisations without governance hit a wall. Legal, security or the board blocks further deployment, because nobody can state the risk position. Governance clears that blockage. Give teams a clear approval route, a defined risk tier and known controls, and they ship AI faster, because they are not renegotiating the rules every time.

How much AI is really in use? What our fleet data shows

Every governance framework starts with an inventory, and every inventory starts with an assumption about how much AI is in use. To test that assumption, Corrata inspected AI-related network traffic across customer mobile fleets between April and June 2026. Detection is based on on-device inspection of connections to known and newly identified AI service domains, and the percentages below show the share of customer accounts in which traffic to each service was observed.

Measuring the AI surge: the scale of AI adoption on mobile fleets

Three findings matter for anyone building an inventory.

The first is scale. AI traffic was present in 84% of customer accounts and growing at 40% month on month, so any register compiled today is already out of date by the time it is circulated.

The second is what the AI actually is. OpenAI appeared in around a third of accounts, which is the part most people would have guessed. The rest was made up of services most security teams would not recognise as AI at all: Bloomreach, Emarsys, Sprig, Sendbird and Gorgias, alongside AI features that arrived as routine updates to software the business already trusted. Nobody procured those, nobody reviewed them, and the people using them mostly do not know they are using AI.

The third is novelty. Seven in ten detected AI domains were new to us at the point of detection. A blocklist or an allowlist written last quarter is governing a minority of what is actually in use.

AI tools detected, by share of customer accounts

Accounts commonly use more than one service, so these shares do not sum to 100%.

Methodology: Corrata inspected AI-related network traffic across customer mobile fleets between April and June 2026. Detection is based on on-device inspection of connections to known and newly identified AI service domains. Percentages show the share of customer accounts in which traffic to each service was observed.

The practical conclusion runs through the rest of this guide. An inventory built from a survey captures the systems people remember to declare. An inventory built from what is happening on the network and on the devices captures the rest.

What is an AI governance framework?

An AI governance framework is a structured model for how governance actually gets done. It sets out the processes that apply at each stage of the AI lifecycle, the roles that hold decision rights, the controls that reduce known risks, and the records that show all of it happened.

Almost every large organisation has published AI principles. Very few have made them operational, and the gap between the two is where frameworks do their work.

A framework answers those questions once, in a way that holds across the organisation, so individual teams are not improvising.

Proportionality is what makes a framework usable

One design decision determines whether a framework survives contact with the business, and that is proportionality. Put a tool that summarises public articles through the same review as a model that shapes credit decisions, and teams will route around governance entirely. The organisation then loses the visibility it was trying to gain. Make every control light, and serious risks go unexamined.

Risk-tiering at intake solves this. A short triage step sets a tier based on what happens if the system is wrong. The tier then drives how deep the assessment goes, who has to approve it, and how closely it is monitored. Low-tier systems clear in days against a standard control set. High-tier systems get the scrutiny they warrant.

Governance across the AI lifecycle

Frameworks organise controls around lifecycle stages, so the right question gets asked while it can still change the outcome.

1. Ideation: Is AI the right tool here? This question gets skipped more than any other. A rules-based workflow, a better-designed form or a dashboard is often more accurate, cheaper to run and easier to govern than a model. Choosing not to use AI is a legitimate governance outcome.

2. Data sourcing: Where the data came from, whether its use is permitted, and which population it actually represents. Get this wrong and you cannot fix it later without retraining.

3. Build or procure: For work built in-house, what gets tested and documented. For bought-in systems, what the vendor must prove and what the contract must require.

4. Validation: Testing for performance, robustness, fairness and security. Agree the pass criteria before the work starts, not after you see the result.

5. Deployment: Sign-off by the accountable owner, disclosure to the people affected, and human oversight in place before the system reaches live users.

6. Operation and monitoring: Drift detection, sampling of outputs, open incident channels, and periodic review against the original criteria.

7. Retirement: A model whose business purpose has quietly disappeared stays a liability while it stays connected. Retiring it means removing access and integrations, deciding what happens to the data and to past decisions, and keeping records for as long as the rules require.

AI governance framework examples

Four reference points dominate practice, and they complement each other rather than compete. That is the most common misunderstanding in governance procurement.

• NIST AI RMF 1.0 is a voluntary US framework built on four functions: Govern, Map, Measure and Manage. It suits organisations that want a practical risk method without the overhead of certification. Its Generative AI Profile (NIST AI 600-1) covers GenAI-specific risks.

• ISO/IEC 42001:2023 is a certifiable management system standard. It suits organisations that need assurance an outside auditor can sign off, and AI vendors selling into regulated buyers.

• OECD AI Principles are intergovernmental principles. They are useful for setting values, and for understanding the thinking most national regimes were built on.

• EU AI Act is binding, risk-tiered law. It applies to anyone placing AI systems on the EU market, or whose AI output is used there.

The combination that works: ISO/IEC 42001 for the management system, the NIST AI RMF for the risk method inside it, and both mapped to whatever regulation applies. One control library, several assurance outputs.

Where regulation currently stands

The EU AI Act is the most comprehensive regime in force. It sets obligations by the risk a system poses, not the technology it uses. Its reach extends past the EU. A provider based anywhere is in scope if its system reaches the EU market, and so is one whose output is used there. What you owe depends heavily on whether you are a provider or a deployer. Penalties reach €35 million or 7% of global turnover at the top tier.

Elsewhere the picture is less settled. The United States has no comprehensive federal AI statute, so binding duties on private firms sit mostly in state law. That makes US exposure a moving patchwork rather than one standard to build against. The UK has told existing regulators to apply AI oversight inside their own remits instead of passing a single statute.

Sectoral rules matter as much as AI-specific ones everywhere. Financial services model risk expectations, medical device regulation, employment law and data protection law all bite on AI systems, whatever any AI Act says.

Key components of an effective AI governance framework

Who should oversee AI governance?

AI governance owned by IT alone fails predictably. IT can see the systems. It cannot judge whether a hiring model is lawful, whether a clinical decision aid is clinically sound, or whether a pricing model is fair. AI risk is technical, legal, ethical and commercial at the same time. Oversight has to be cross-functional, with decision rights that are clear rather than vaguely shared.

Most organisations settle on three layers. A governance committee sets policy and rules on high-risk cases. A working group handles assessment and technical review. Accountable owners inside business lines run individual systems. The committee should be small enough to decide and senior enough that its decisions hold. Smaller organisations do not need a committee, but they still need someone named.

AI governance where employees actually use AI: phones and tablets

Most AI governance material assumes AI is something the organisation builds or procures. In practice, the largest share of AI use starts with an individual employee and a consumer app, and increasingly that happens on a phone.

Phones are where the governance gap is widest for four reasons:

• Consumer AI apps are installed in minutes from the app store, usually under a personal account with no data processing agreement, no retention commitment and no data residency guarantee.
• AI features now arrive inside the messaging, productivity and camera apps people already use, so nobody experiences a moment of “adopting AI” that a policy could attach to.
• Traffic from a phone leaves over the mobile network or home Wi-Fi rather than through the corporate gateway, so the proxy, the email filter and the web gateway never see it.
• A large share of the phones reaching company data are personally owned, which limits what the organisation can reasonably inspect.

The result is that the components a framework depends on, the inventory, the data governance controls and the security controls, are all weakest at exactly the point of use where confidential information is most likely to leave. An employee who pastes a customer record into a personal chatbot on their phone has sent personal data to a third party, possibly across a border, with no lawful basis and no record of it, and the governance programme will typically find out only if the employee mentions it.

Closing that gap needs three things that a policy document cannot provide on its own:

• Visibility has to come from the device. A survey asks people what AI they use; discovery on the device shows which AI services the fleet is actually reaching, including the ones that arrived as features inside trusted software. That is how the figures above were produced, and it is the only method we have found that keeps the inventory current.
• Policy has to be enforceable at the point of connection. A governance policy that distinguishes sanctioned AI tools from unsanctioned ones is only a policy until something acts on it. Corrata’s Shadow AI and mobile data loss prevention capability monitors policy breaches on connections to consumer AI services, unsanctioned SaaS and ad tracking from phones and tablets, and intervenes automatically, so the control applies at the moment data would otherwise leave rather than in a quarterly review.
• Enforcement has to respect the employee. Governance that depends on reading message content or tracking browsing will be rejected by staff and, on personal devices, will not be permitted at all. Corrata’s approach inspects traffic on the device without accessing message content, browsing history or location, which is what makes it deployable on a personally owned phone.

Questions to answer before deploying an AI system

If a team cannot answer these, the system is not ready for production, however well it performed in testing.

• Is AI the right tool for this purpose, and who is the named accountable owner?
• What data does it use, is that use permitted, and does the data represent the people it will be applied to?
• Who could be harmed if it is wrong, how badly, and how would we spot unequal outcomes between groups?
• What human oversight applies, and does the reviewer have the information and the authority to disagree?
• What gets monitored after launch, at what thresholds, who acts on it, and what is the rollback plan?

Common failure patterns

Five patterns recur across governance programmes that stall.

1. The inventory that was accurate once: Built from a one-off survey, it captures the known systems and misses the rest: anything bought on an expense claim, switched on as a feature inside existing software, or used through a personal account. Our fleet measurement shows how large that gap is, with seven in ten detected AI domains previously unknown to us. Inventories need continuous discovery rather than annual attestation.
2. Human oversight in name only: Picture a reviewer approving hundreds of model recommendations a day, seeing nothing beyond the recommendation itself, with no real authority to disagree. That is documentation rather than a control. Measure override rates, because a rate near zero means the control is not working.
3. Governance as a gate rather than a service: If the only contact teams have with governance is a slow approval queue, they will route around it. The programmes that hold up offer pre-approved tooling, reusable assessment templates and fast triage for low-risk cases.
4. Vendor opacity accepted by default: Plenty of suppliers will not disclose their training data practices, test results or model limits. The usual response is to proceed anyway, because the tool is already in the budget. The workable position is to accept opacity for low-consequence uses and refuse it for high-consequence ones.
5. Framework compliance without risk reduction: You can assemble a complete ISO/IEC 42001 evidence pack while the riskiest system in the organisation runs unassessed on a business line’s own budget. Certification shows a management system exists. It does not show that the system covers everything.

Where to start

Maturity varies, but the sequence that fails least often is the same. Build an inventory of the AI already in use, including tools nobody approved. Publish a policy on permitted use, data handling and approval thresholds. Add risk triage at intake, so the depth of review matches what happens if you get it wrong. Then apply controls to the top tier first.

The order matters. Organisations that start with controls end up applying them to a fraction of their AI estate, and never find out which fraction.

It also matters where the inventory comes from. On the evidence of our own fleet data, a policy written against a list of declared AI tools is governing a minority of the AI actually in use. The list has to be built from what is happening on the network and on the devices, which is what governance looks like on the phones and tablets where most of that use now happens.

Governance is only as good as the inventory beneath it

Every component in this guide rests on knowing what AI is actually in use. The policies, the risk tiers, the vendor terms, and the human oversight all assume a register that reflects reality. On the evidence of our own detection data, most registers do not. The organisations that handle this well can answer, on any given day, which AI services their people are reaching and from which devices, and they build that answer from what the devices are doing rather than from what staff remember to declare.

That is the part a policy document cannot supply on its own, and it is where most governance programmes quietly come apart.

Find out what your fleet is already reaching

Corrata’s on-device inspection shows which AI services your phones and tablets are connecting to, including the ones that arrived as features inside software you already trust. If you would like to see it against your own estate, you can book a demo.

The post AI Governance Explained: What It Is, Why It Matters and How to Begin appeared first on Corrata.

For security teams, cutting through the AI noise to a durable assessment of what actually changes requires discipline. For Corrata, the answer involves three dimensions:

• AI is creating new risks through the way employees use LLMs: Shadow AI, data leakage, governance gaps;
• AI is being weaponised by attackers, producing threats that are faster, more sophisticated, and more personalised; and
• AI embedded within our product gives defenders capabilities that can match and exceed what attackers are deploying.

This framework has allowed us to re-imagine mobile device security for the AI era.

How AI Is Reshaping the Mobile Threat Landscape

Mobile devices sit at the epicentre of all three dimensions: a primary vector through which employees interact with AI, the endpoint most frequently outside traditional security controls, and an increasingly favoured attack surface for AI-augmented adversaries. Four threat categories define the new environment.

Hyper-Personalised Social Engineering. AI has transformed phishing from a numbers game into targeted precision. Attackers use LLMs to construct lures from publicly available data, LinkedIn profiles, company announcements, recent news, producing messages indistinguishable from genuine communications. M-Trends 2026 puts the click-through rate on AI-generated phishing at 54%, against 12% for traditional campaigns. On mobile, where 85% of phishing attacks already occur outside email, across SMS, WhatsApp, Teams and other messaging channels, the impact is acute. Victims aren’t catching clumsy, misspelled emails. They’re responding to messages that feel entirely legitimate.

AI-Accelerated Exploits and Insecure Code. GTIG’s confirmed zero-day is the sharpest illustration of a broader shift: finding and weaponising vulnerabilities no longer requires deep expertise or months of effort. The median time from disclosure to active exploitation had already fallen from 771 days in 2018 to single-digit hours by 2024: before frontier models like Mythos entered the picture. Compounding this, the rise of “vibe coding”, AI-generated code shipped without full developer comprehension, is producing a steady supply of insecure enterprise applications. Mobile is particularly exposed, where apps are deployed quickly and outside the review processes that govern traditional software.

Shadow AI and Data Loss. When employees find that an AI tool makes them more productive, they use it: approved or not. Research suggests 43% share corporate data with LLMs without authorisation. On mobile, where personal and professional boundaries are already blurred, the exposure is acute: sensitive documents uploaded to consumer AI services, client details pasted into chatbots, proprietary code submitted for debugging. Institutional knowledge is leaving organisations at an unprecedented rate, with no visibility and no controls in place.

Agentic Overreach. AI agents, autonomous systems acting on a user’s behalf, are being granted broad access to mobile capabilities: microphones, cameras, contacts, location, messaging. Developer intentions are often benign, but the permissions requested routinely exceed what the use case requires. A typical social networking app already requests ten unnecessary permissions. As agents proliferate, this attack surface will expand rapidly.

How Corrata Is Reimagining Mobile Security for the AI Era

Corrata has always been built on a simple premise: mobile devices deserve the same depth of security monitoring as laptops and servers. Our on-device architecture inspects 100% of network traffic without routing it through a cloud relay: a visibility advantage no competitor has matched. In the AI era, that foundation becomes more important, not less. But architecture alone is not enough. The threat landscape has changed, and Corrata has changed with it.

Elevated Capabilities for a New Threat Environment. Several existing Corrata capabilities take on heightened significance in this environment. Automatic device quarantine, isolating devices that fall below a defined security threshold, is the first line of defence against AI-accelerated exploits targeting unpatched vulnerabilities. Continuous monitoring of all device traffic, across DNS queries, IP connections, Server Name Indicators, TLS configurations and port activity, gives security teams the visibility to detect C2 communications on compromised devices. The ability to block or report access to specific AI services and SDKs allows organisations to act immediately, even before a formal governance framework is in place.

Domain-Specific SLM for Enhanced Traffic Analysis. The vast majority of mobile traffic is now encrypted, and current detection, based on device scanning, app analysis and network metadata, will struggle against the more sophisticated social engineering and exploit techniques that AI is enabling.

Corrata is addressing this with anon-device domain-specific SLM purpose-built for the mobile environment. The instinct might be to reach for a large language model, but an LLM cannot do this job on a phone.

LLMs carry billions of parameters that have to be held in memory and powered through every inference. They demand too much memory to sit resident on a mobile device, they drain the battery, and they depend on dedicated AI hardware that most enterprise phones do not have. They are also too slow: threat detection has to return a verdict in real time, on every connection, continuously, and an LLM cannot keep pace with that on-device. For continuous on-device threat detection, an LLM is the wrong tool.

A domain-specific SLM bridges that gap. By narrowing the model to a single task, detecting threats in mobile network traffic, it needs a fraction of the parameters, which is what makes it small enough to run directly on the device, fast enough to respond in real time, and light enough that it does not drain the battery or consume excessive memory. Because it runs on the device, no data leaves the phone, so detection and privacy are no longer a trade-off. The narrower scope is not a compromise; for this one job it is exactly what delivers the performance the use case demands.

AI Governance for the Mobile Workspace. Corrata’s AI Governance capability lets organisations define which AI services and SDKs are sanctioned in the mobile workspace and enforces those policies automatically. Approved tools are unaffected; access to unsanctioned services, consumer chatbots, AI coding assistants, embedded LLM SDKs in third-party apps, is flagged or blocked. As AI governance frameworks including ISO 42001 and the EU AI Act mature, mobile is the enforcement gap most organisations have yet to close. Corrata closes it.

Precision Mobile DLP for the AI Age. Data leakage via mobile is no longer confined to lost devices or unencrypted email: AI tools are now a primary exfiltration channel. Corrata’s enhanced DLP uses fine-grained traffic analysis to detect sensitive corporate data being transmitted to external services, whether deliberately or inadvertently. Rather than simple URL categorisation, Corrata analyses the nature and destination of data flows, enabling security teams to act on genuine data loss events rather than chase false positives.

A New Standard for Mobile Security

The device in your employee’s pocket is simultaneously connected to AI tools, targeted by AI-powered attackers, and operating in an environment where the threat landscape is being rewritten in real time. The controls deployed two or three years ago were not built for this world.

Corrata brings together the deepest visibility into mobile traffic of any solution on the market with a new generation of AI-native capabilities built for the threats that matter most right now. The organisations that get ahead of this moment will be those that treat mobile security as a genuine strategic priority: not a compliance checkbox.

Request a demo today to see how Corrata’s reimagined approach works in practice.

Read the full press release

The post Mobile Device Security Reimagined for the AI Era appeared first on Corrata.