The apps your staff already built: governing low-code and AI sprawl

The inventory nobody has

Ask an Australian business of 60 people how many internal applications it runs and you will get a number between five and fifteen. Pull the actual list — from the Microsoft 365 admin centre, the Power Platform environments, the browser extensions your staff have installed and the automations running under individual accounts — and the number is routinely three to five times higher.

None of it was built maliciously. Someone in finance needed an approval flow, someone in operations needed a tracker, and both of them solved the problem in an afternoon with the tools their licence already included. That is the system working as designed. The gap is that no one recorded what data those apps touch, who can see it, or what happens when the person who built it leaves.

Why low-code changed the exposure

Traditional shadow IT was a SaaS subscription on a credit card. Low-code shadow IT is different in a way that matters: it runs inside your tenant, with your identity, against your data, under permissions the builder already holds. There is no vendor to assess and no invoice to catch it.

Copilot Studio agents extend the same pattern to AI. An agent grounded on a SharePoint site inherits that site's sharing configuration. If the site is over-shared — and in most tenancies at least one is — the agent will faithfully surface content the requester was never meant to read, at conversational speed, with no obvious trace that a control failed.

Find it before you govern it

Discovery does not require a new platform. In a Microsoft environment, start with the Power Platform admin centre for apps and flows by environment and owner, the Copilot Studio agent list, Entra ID enterprise applications and consented OAuth grants, and the list of connectors in use — especially the personal ones such as Gmail, Dropbox and personal OneDrive, which are the clearest sign that organisational data is leaving the boundary.

Add two non-technical sources that consistently outperform tooling: ask each team leader what spreadsheets or trackers their team depends on, and look at what runs on a leaver's account before it is disabled. Both surface dependencies that no admin console reports.

Triage in three buckets

Keep and govern: the app does real work, the data is understood, and the fix is administrative — reassign ownership from an individual to a role, move it into a managed environment, classify the data, turn on logging and set a review date.

Rebuild: the app does real work but the way it does it is unsafe — personal connectors, credentials in plain text, no access control, a single point of failure in one person's account. Rebuild it properly rather than patch around it. In practice these are the strongest candidates for a small, deliberately built internal app.

Retire: nobody uses it, or it duplicates something the organisation already licenses. Retirement is the cheapest security control available and it is consistently under-used.

The register is the control

One artefact does most of the work: an application register carrying, for every internal app and agent, a named business owner, the data classification it touches, the access model, whether it includes an AI step, the logging location and a review date.

That single register answers an ISO/IEC 27001 assessor asking about asset and supplier management, satisfies the AI system inventory expectation in ISO/IEC 42001, and gives the executive team an honest answer when a client due-diligence questionnaire asks which systems process their data. Most organisations we work with can build a first version in a fortnight.

Guardrails that do not stop the work

Blanket bans fail. Staff move to tools you cannot see, and the exposure gets worse while the register gets cleaner. The durable pattern is a paved road: a managed environment where building is easy and approved, default policies that block personal connectors and enforce data loss prevention, and a lightweight intake — five questions, not a project board — that routes anything touching sensitive or regulated data to a proper design.

Set the AI condition explicitly. Any workflow where a model drafts, decides, classifies or acts needs a defined human review point, a way to tell when the output is wrong, and a rollback path. That is the practical core of the ISO/IEC 42001 expectation, and it is achievable in a small business without a compliance function.

What good looks like in 90 days

By day 30 you have the inventory and a triage decision against every entry. By day 60 the keepers have named owners, sit in a managed environment with logging enabled, and the retirements are done. By day 90 the register is live, the intake path is published, and the two or three workflows that justified a rebuild are scoped as small, properly built internal apps.

The outcome is not less building. It is the same volume of building with an owner, a classification and an audit trail behind each one — which is the difference between a productivity story and a finding.