Answers

AI governance questions, answered.

21 direct answers to the questions people actually ask — about agents nobody owns, non-human identities, shadow AI, measuring exposure, and what the EU AI Act needs from you now. Short answer first. No form.

Last updated 2026-09-15 · new questions added as they come up in the field.

Finding what you have

#How do I find out which AI agents exist in my Microsoft 365 tenant?

Read them from the Microsoft management APIs rather than asking teams to declare them. Copilot Studio, Microsoft 365 Agent Builder and Power Platform each expose an inventory of what has been created, who created it, which environment it lives in and which connectors it holds. A read-only, consent-scoped application registration is enough to enumerate all of it; no agent on any device and no traffic interception is required. The number is usually far higher than the number anyone would have guessed, because most agents are created by people who never needed a security review to publish one.

On one connected estate this returned 625 agents, 327 of them built in-tenant, none of which had been centrally inventoried.

Copilot Studio governance

#How do I build an AI inventory without asking every team to fill in a form?

Make the inventory a property of the platform rather than an act of goodwill: read it from the systems agents are built in, so a system appears because it exists and not because someone volunteered it. A form-based register is stale the day it is finished, because the people most likely to skip it are the ones creating agents fastest. Platform-read inventory also gives you fields a form never will — the connectors an agent holds, the identity it runs as, whether it requires consent before acting.

How discovery works

#What is shadow AI, and how is it different from shadow IT?

Shadow AI is AI being used or built outside any approval path, and it differs from shadow IT in one decisive way: it is usually created inside tools you already bought and already trust. Shadow IT meant someone signed up for an unapproved SaaS product. Shadow AI is far more often an agent built in your own Copilot Studio, an OAuth grant to a personal AI account, or an AI feature switched on inside software you approved years ago. That means network blocking finds very little of it, and the estate grows without anything appearing to be violated.

Shadow AI discovery

#How many AI agents does a typical enterprise actually have?

Far more than its inventory says, and the gap is the finding rather than the number. Counts vary enormously with how much Copilot Studio and Power Platform have been rolled out, so any vendor quoting an industry average is guessing. What is consistent is the ratio: organisations that have never read their estate from the platform APIs typically discover several hundred where they expected dozens, because replicas, vendor templates and abandoned pilots all persist.

One connected mid-size estate returned 625 agent records, of which 327 were built in-tenant and the rest were vendor templates.

AI sprawl assessment

#If the same agent appears in three environments, is that sprawl?

No — that is a replica, and counting it as sprawl inflates your numbers and wastes review time. The same agent promoted through dev, test and production appears three times in a raw platform read, which is why a count of rows describes the manifest rather than the estate. Genuine duplication is two different agents doing the same job under different names, usually built by teams who did not know about each other. Distinguishing the two matters because one is normal software lifecycle and the other is uncontrolled spend and duplicated exposure.

The Agent Map

Ownership and accountability

#Who is accountable for an AI agent that nobody created on purpose?

Until someone is named, the accountable party is whoever signed off the platform it was built in — which is usually the CIO or CISO by default rather than by decision. This is the single most common finding in a first AI estate read: agents exist, they act, and no business owner, security owner or signed purpose is recorded anywhere. Fixing it is not a technology problem. It requires a register that proposes an accountable person from platform data and forces a human to confirm or reject it.

On one connected estate, 625 of 625 agents had no signed purpose and 80 of the 94 agents acting autonomously had nobody accountable.

Agent accountability

#What is a non-human identity, and why does an AI agent need one?

A non-human identity is a directory identity issued to software rather than a person, and an agent needs one so its actions can be attributed, scoped and revoked. An agent without its own machine identity acts as whoever created it, which means every call it makes looks like that person's activity in every downstream log. There is also nothing to rotate and nothing to revoke: switching the agent off means disabling a human account or deleting the agent entirely.

On one connected estate, 1 of 9 governed agents held a machine identity in Entra; the other 8 could not authenticate as themselves.

Non-human identity sprawl

#What should an AI risk register contain for agents?

For each agent: a named business owner, a named security owner, a declared and signed purpose, its autonomy tier, the data it can reach, the actions it can take, whether it can send data outside the tenant, and the identity it runs as. Most registers stop at name and description, which is why they cannot be used to make a decision. The test is whether someone reading a single row can say what would happen if that agent behaved badly, and who they would call.

The Purpose Register

#How do I decide which AI agents need human approval?

Draw the line at irreversibility rather than at a risk score: an agent that can only read and summarise needs a different control load from one holding a write path, a deletion permission, or a route out of the tenant. Irreversibility is a property of what an agent can reach, which means it is observable in configuration before anything goes wrong. Scoring by project importance instead produces the worst of both outcomes — heavy review on harmless assistants, which drives shadow development, and light review on agents that can actually destroy something.

The data-to-action graph

Measuring exposure

#How do you measure AI governance without inventing a number?

Measure state, not sentiment, and refuse to score anything you cannot see. The difference between a real measurement and a dashboard is what happens to an unmeasured dimension: a dashboard scores it zero or quietly averages it away, and an honest measurement excludes it and says so. Three rules keep a score defensible — a control counts as measured only when there is evidence it was applied, dimensions aggregate so that a strong one cannot hide a weak one, and the coverage fraction is published alongside the number.

The Govern360 AI Exposure Score uses a weighted geometric mean, caps the band by the weakest measured dimension, and reports unmeasured dimensions as not measured rather than as zero.

How the score is built

#Is there an industry-standard score for AI exposure?

No. There is no equivalent of a credit score or a CVSS for AI exposure, and any vendor implying otherwise is describing its own model. What does exist is a set of frameworks that tell you which controls to have — NIST AI RMF, ISO/IEC 42001, the EU AI Act, OWASP's agentic top ten — and a score is only useful if it maps to one of those and publishes its method. Ask two questions of any score: what does it do with a dimension it cannot measure, and can you trace a single point back to a configuration.

AI Exposure Management

#What is the lethal trifecta for AI agents?

It is the combination of three capabilities in one agent: access to untrusted input, access to private data, and the ability to send data outside the organisation. Any one of them alone is ordinary. Together they mean content an attacker controls can reach a system holding your data, which then has a route out — the shape behind most practical prompt-injection exfiltration. The harder version is when the three legs are spread across two agents that each pass an individual review, because a per-agent check cannot see a path that completes between them.

OWASP agentic risks

#How often should AI governance be reviewed?

Continuously, because the thing you are governing changes between reviews and can act irreversibly in seconds. A quarterly review cycle was designed for work that moves at human pace; an agent can be created, granted a connector and published in an afternoon. The practical replacement is a measurement that runs on a schedule and a register that shows what changed since the last time anyone looked, so the question "has anything moved" has an answer on any given day rather than once a quarter.

Continuous evidence

Architecture and enforcement

#Do I need an AI gateway or a proxy to govern AI?

Not to discover, measure or attribute — only to block traffic in real time. A gateway sits in the request path and can stop a prompt mid-flight, which is genuinely useful and genuinely invasive: it becomes a dependency, a latency budget and a change-control conversation. Discovery, ownership, identity posture, exposure paths and spend attribution are all readable from management APIs without touching the path. The sensible sequence is to read first, decide what is actually happening, and add an inline control only where evidence says you need one.

How Govern360 connects

#Does Microsoft Purview cover agents built in Copilot Studio?

Purview governs the data, not the agent. It can label, classify and apply DLP to content that moves through Microsoft 365, and that coverage extends to Copilot interactions — but it does not tell you that an agent exists, who owns it, which connectors it holds, what autonomy tier it runs at, or whether it can reach a system outside the tenant. Those are properties of the agent, and they live in the Power Platform and Copilot Studio inventories rather than in the data plane. The two are complementary: Purview enforces, the agent inventory tells you what needs enforcing.

Microsoft 365 Copilot governance

#How do I prove to an auditor that an AI control is actually applied?

Read the applied state back from the platform that enforces it, and be explicit where you cannot. There are three honest outcomes for any control: it was compiled into the enforcement platform, it was marked applied by a person, or it was verified by reading the live configuration back. Only the third is evidence. A governance tool that shows a green tick without saying which of the three it means is asserting something it has not checked, and an auditor who asks one follow-up question will find that out.

Govern360 reports every control as Compiled, Marked applied or Verified, and claims Verified only where a platform exposes a read-back path.

Audit-ready evidence

#What is the difference between an AI policy and an AI control?

A policy is a statement of intent; a control is a configuration that makes the intent true whether or not anyone is paying attention. "Do not paste source code into consumer AI tools" is a policy. A DLP rule in the tool people actually use, which blocks the paste and logs the attempt, is a control. The distinction matters because most organisations grade themselves on policy coverage, which is the easy half — the useful measurement is what fraction of policies have a corresponding control that has been verified as applied.

From policy to control

#How is AI-SPM different from AI governance?

AI security posture management inspects models, pipelines and the infrastructure AI runs on; AI governance asks what each AI system is allowed to do and who is answerable for it. AI-SPM grew out of cloud security posture management and inherits its shape — find misconfigurations in the stack. That is necessary and it does not answer the agent question: an agent can sit on a perfectly configured platform, hold a connector to a finance system, run as its creator and have no owner. Posture is about the platform; governance is about the actor.

AI-SPM for agent estates

Cost, compliance and the board

#How do I find out how much we are spending on AI, broken down by team?

Attribute consumption to the workload that caused it, not to the subscription that paid for it. Cloud and vendor bills arrive at the account level, which tells a CFO the total and nothing about which team, agent or use case produced it. Useful attribution needs a rule chain that maps each usage record to an owner and leaves a per-record trace you can replay for any past period — otherwise the allocation is an opinion and the first person to dispute it wins.

AI cost attribution

#What does the EU AI Act actually require me to have right now?

In practice: an inventory of your AI systems, a risk classification for each, transparency where people interact with AI or AI-generated content, and records you could show a regulator. Transparency obligations applied from August 2026, and parts of the wider timetable remain subject to ongoing legislative discussion, so the safest reading is that the inventory and the classification are the work that is due now and unlikely to be relaxed. If you cannot list your AI systems, none of the later obligations are reachable — the inventory is the dependency for everything else.

EU AI Act readiness

#What should a board be asking about AI right now?

Two questions: are we moving fast enough, and is there exposure nobody owns? Most board reporting answers the first with adoption metrics and the second with an assurance, which is why it tends not to survive a follow-up. A better pack shows one measured number with its trend, what moved it, how much of the estate that number actually covers, and a short list of decisions waiting on a person. Whether the result sits inside the board's risk appetite is a judgement for the board — a product that asserts the threshold is inventing governance rather than reporting it.

The board-ready view

Ask us one we have not answered

Send the question you think we will get wrong. You get a written answer, usually the same day.

Challenge Govern360