AI security and AI governance, 100 questions answered.

#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.

Govern360 reads those management APIs through a read-only, consent-scoped application registration. On one connected estate that returned 625 agents, 327 of them built in-tenant, none of which had been centrally inventoried.

#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.

Govern360 builds the inventory from platform APIs rather than from a form, so a system appears because it exists. Each record arrives with the connectors it holds, the identity it runs as and its creator already attached - fields a declaration would never have captured.

#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.

Govern360 looks for both kinds across five layers - browser, endpoint, network, identity and the connected platforms - because the agent built inside a tool you already approved is invisible to domain blocking and is usually the larger half.

#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 mid-size estate connected to Govern360 returned 625 agent records, of which 327 were built in-tenant and the rest were vendor templates - which is why Govern360 reports those two separately instead of publishing one headline count.

#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.

Govern360 separates replicas from genuine duplication in the count rather than reporting raw rows, and sizes each group by distinct name - so a promotion through dev, test and production does not read as three findings.

#Can I inventory AI without installing anything on endpoints?

Yes, for the part that matters most. Agents, Copilots, connectors and machine identities live in platform control planes, so they can be enumerated through read-only management APIs with nothing installed anywhere. Endpoint tooling only becomes necessary for the narrower question of which desktop applications and browser extensions individuals are running. Treating the endpoint as the starting point is the common mistake: it finds staff using ChatGPT and misses the agent estate entirely.

Govern360’s core discovery is API-only and read-only. The optional endpoint collector is a PowerShell script run from your RMM that installs nothing and needs no admin rights, and the managed browser extension is separate again - neither is required for a score.

#How long does it take to get a first AI inventory?

Connection takes minutes per supported source and a first inventory typically appears within hours, because nothing is being scanned - the platforms already hold the records. What takes longer is coverage: each additional source you connect widens what the inventory can see, and the honest version of the number moves as that happens.

Govern360 publishes the coverage fraction beside every figure rather than hiding it, so an early inventory reads as partial rather than complete. Sources that have not been connected are reported as not measured, not as clean.

#How do I find AI features that vendors switched on inside software we already bought?

Look at OAuth grants, app registrations and connector definitions rather than at vendor announcements. An AI feature added to an approved SaaS product rarely appears as a new purchase; it appears as a new scope on an existing integration, a new connector in an automation platform, or a new consent grant against your directory. That is why the arrival of AI inside your estate is usually invisible to procurement and visible to identity.

Govern360 correlates OAuth grants, app registrations, connector manifests and platform inventories into one view, so an AI capability that appeared inside an existing tool surfaces as a finding rather than as a silent change.

#What happens to AI agents built by people who have left?

They usually keep running. An agent published in a platform does not stop when its creator leaves; if it has its own machine identity it continues authenticating, and if it does not, it runs as an account that may itself be disabled - which produces silent failures rather than a clean stop. Either way nobody is left who can explain what the agent is for, which makes it both a security question and an accountability one.

Orphaned agents are a named finding: Govern360 checks each agent’s creator against the directory and surfaces the ones whose creator is no longer there, so they can be reassigned or retired by decision rather than discovered during an incident.

#What actually counts as an AI system for inventory purposes?

Anything that can invoke a model and act on the result. That covers the obvious assistants, but the entries that matter are the ones people do not think of as AI systems: an automation flow with a single model step, a vendor template published into your tenant, a scheduled job that summarises documents, a connector that routes prompts to a hosted model. Scoping the inventory to products with AI in the name is what leaves most of the estate out.

Govern360 inventories applications and models, agents and automations, shadow AI, connectors and tool access, machine and human identities, ownership, permissions and data access, and the exposure paths between them - eight categories rather than a list of tool names.

#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.

That is what the Govern360 Purpose Register does: it proposes an accountable owner from platform data and requires a person to confirm or reject it. On one connected estate it found 625 of 625 agents with no signed purpose, and 80 of the 94 agents acting autonomously with nobody accountable.

#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.

Govern360 inventories the machine identities behind AI systems alongside the agents themselves. On one connected estate, 1 of 9 governed agents held a machine identity in Entra; the other 8 could not authenticate as themselves.

#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 Govern360 Purpose Register holds exactly those fields per agent - business owner, security owner, signed purpose, autonomy tier, data reach, actions, egress and identity - and proposes the owner from platform data so the register starts populated rather than empty.

#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.

Govern360 records what each agent can actually reach and which tier of autonomy it holds, so the approval line can be drawn on irreversibility. Where the tier could not be read it is reported as not assessed rather than defaulted to the safest value.

#Who should own AI governance - the CISO, the CIO, or a Chief AI Officer?

Accountability for an individual system has to sit with the business owner who benefits from it; the central function’s job is to make that ownership visible and to hold the standard. Where AI governance is assigned wholesale to security, it becomes a queue and teams route around it. Where it is assigned wholesale to a new AI office with no platform reach, it becomes a policy document. The workable split is central standard, local ownership, one shared inventory.

The same Govern360 inventory answers different questions for the CISO, CIO, CAIO, risk, compliance and application owners, which is why each record carries owner, purpose and cost alongside the security attributes rather than security attributes alone.

#Why does an AI agent need a signed purpose?

Because without one there is no standard against which its behaviour can be judged. A named purpose turns ’is this agent behaving badly’ from an argument into a comparison: here is what it was approved to do, here is what it can reach, here is the gap. It also gives review a stopping condition - an agent whose purpose no longer exists can be retired rather than maintained indefinitely.

Govern360’s Purpose Register proposes an accountable owner and a purpose from platform data, then requires a person to confirm or reject it. An unsigned purpose is reported as an accountability gap with a point value, not quietly defaulted.

#How should we classify how autonomous an AI agent is?

By what it can do without a person in the loop, in tiers you can act on: answers only, assists, suggests, acts but asks first, and acts alone. The tier matters more than the model behind it, because the control load follows the irreversibility of the action rather than the sophistication of the reasoning. An agent that can only answer needs a light touch however capable its model; an agent that can send mail outside the organisation needs review whatever model it runs.

Govern360 records the tier each agent holds today and treats an unread tier as not assessed rather than as the safest option, so an agent that could not be classified does not appear as low autonomy by default.

#Do we need an AI governance committee, and what should it actually decide?

A committee helps only if it is deciding rather than reviewing. Useful decisions are narrow and repeatable: which autonomy tiers require a named security owner, what happens to an agent whose owner leaves, which data classes are never allowed to reach a consumer AI tool, and how long an approval lasts before it must be renewed. Committees that instead review individual agents one by one become the bottleneck that drives shadow development.

Govern360 surfaces the decisions that are waiting rather than the systems that exist, so a committee sees a short list of items needing a human judgement instead of an inventory to read.

#Who is accountable for an AI agent a vendor published into our tenant?

You are, for its behaviour in your environment, whatever the contract says about the software. A vendor template running in your tenant authenticates against your directory, reads your data and acts under your name. Vendor-supplied agents are also the ones most likely to be counted as inventory noise and skipped, which is precisely why they accumulate.

Govern360 separates agents built in-tenant from vendor templates in the count, so both are visible but neither inflates the other. On one connected estate that split was 327 built in-tenant out of 625 records.

#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.

#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.

Govern360 publishes its own methodology instead of asserting a standard - five dimensions, fixed weights within a model version, and a derivation map from every domain through to the number, exportable so a reviewer can check the arithmetic.

#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.

Govern360 counts the agents holding all three legs as a headline figure, and because it evaluates the composition across agents as well as within them, it reports the case where the path completes between two systems that each pass review alone.

#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.

In Govern360 a review that lapses is not carried forward silently - the affected dimension takes a named stale-evidence deduction, so a cycle that has stopped operating shows up in the number rather than in nobody noticing.

#Why use a geometric mean for an AI risk score instead of an average?

Because risk compounds at the weakest layer rather than averaging out across layers. With an arithmetic mean a strong dimension offsets a weak one, so an organisation with excellent discovery and no ownership can present a comfortable number. A weighted geometric mean does not allow that: a low dimension pulls harder than a high one lifts, and the resulting band stays capped by the weakest measured dimension. That is a closer model of how exposure actually behaves.

The Govern360 AI Exposure Score is a weighted geometric mean of five dimensions - Discovery 25%, Protection 25%, Governance 20%, Control 15%, Compliance 15% - with the weights published and fixed within a model version, so a score change reflects your environment rather than a change in the maths.

#What should a risk score do about things it cannot measure?

Exclude them and say so. The two common alternatives are both wrong: counting an unmeasured control as zero publishes a worse number than the evidence supports and trains people to distrust the score, while quietly dropping it publishes a better one and hides the gap. The honest treatment is to leave it out of the calculation, state that it was left out, and show what connecting a source would change.

Unmeasured domains in Govern360 read ’not measured - earns nothing’ and are excluded from the dimension rather than scored zero. Connecting the missing source changes what the score is made of rather than simply adding points, and the score is always published with the share of the estate it actually rests on.

#Should an AI governance score decay if nothing changes?

Yes, where the underlying evidence has an age. A control that was verified eight months ago and has not been checked since is not in the same state as one verified this morning, and a score that treats them identically rewards standing still. The requirement is that the decay is explainable: a named deduction with a cause and a fix, not a number that drifts downward for reasons nobody can reconstruct.

Stale evidence appears in Govern360 as a labelled penalty on the affected dimension - visible on the derivation map as a small badge on the edge - so the deduction is attributable rather than absorbed into the total.

#Can I benchmark our AI exposure against other companies?

Not meaningfully, yet, and treat confident peer benchmarks with suspicion. Counts vary enormously with how far Copilot Studio and similar platforms have been rolled out, and almost nobody has read their estate from the platform APIs, so any published average is built on self-reported data from organisations that did not measure. Your own trend line over quarters is a far better instrument than a comparison against a number whose provenance you cannot check.

Govern360 reports the change over time - the Exposure Delta - alongside the absolute figure, because momentum is the part that survives scrutiny.

#What stops an AI governance score from being gamed?

Two things: computing it from measurable facts rather than self-assessment, and making every point traceable to a specific finding. If a dimension is a rollup of counts, ratios and coverage read from platform APIs, the only way to move it is to change the environment. If each deduction names the configuration it came from, an inflated number is checkable by anyone who opens the derivation.

Every Govern360 deduction drills from score to dimension to module to finding to task, and the map showing which domain fed which dimension at what weight is exportable, so a reviewer can reconstruct the arithmetic rather than take the number on trust.

#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.

Govern360 requires no proxy for discovery or scoring: it reads configuration rather than traffic, so it never becomes a hop in your network or a latency budget. Where in-line prevention is wanted, the decision is compiled into a plane already sitting in that path.

#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.

Govern360 adds the agent-centric layer over Purview rather than duplicating it - which agents exist, what each holds, who owns them - and compiles decisions back into Purview where Purview is the right plane to carry them.

#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.

#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.

Govern360 turns a policy into a control by compiling it into the plane that enforces it, then marking the result honestly: verified only where a read-back API confirms the live state, compiled where the rule was emitted but no read path exists, planned where support is not built yet.

#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.

Govern360 covers posture as one part of a governance control plane, which is why every record carries owner, purpose and cost beside the security attributes - the fields a board or a regulator asks for, which a posture tool alone does not hold.

#Does Govern360 block anything itself?

No. It decides and compiles; the enforcement planes you already own do the enforcing. That is a deliberate architectural choice rather than a limitation: a governance product that sits in the traffic path becomes a hop in your network, a latency budget and a single point of failure, and the first serious outage ends the programme. Compiling into Purview, Intune and the rest keeps enforcement where it already has an operational owner.

Govern360 compiles policy into the planes that enforce it and marks each plane’s state honestly - verified only where a read-back API confirms the live configuration, compiled where the rule has been emitted but no read path exists, and planned where support is not built yet.

#Do I have to put a proxy in front of every AI tool to govern it?

No, and for the agent estate a proxy would not help much anyway. Proxies see prompts in transit from browsers and applications; they do not see an agent built inside a platform that calls a model over an internal service boundary, and they do not see what connectors that agent holds. Configuration-level governance reads what a system is capable of before anything happens, which covers cases a traffic-path control never reaches.

Govern360 observes and correlates rather than intercepting, so no proxy is required for discovery or scoring. Where in-line prevention is wanted, the policy is compiled into a plane that already sits in that path.

#What is the difference between a policy that is applied and one that is verified?

Applied means the instruction was sent. Verified means the destination was read back and confirmed to hold that state. The gap between the two is where most compliance evidence quietly fails: a rule emitted into a platform that never accepted it looks identical, in a dashboard, to a rule that is live. Any product that shows both as green is asserting something it has not checked.

Govern360 uses a fixed vocabulary - configured, declared, observed, verified, compiled, marked applied, and not measured - and reserves verified for a platform read-back of live state. There are no false greens.

#How do you govern MCP servers and the tools an agent can call?

Start from the tool manifest rather than from traffic. An MCP server declares the operations it exposes, and an agent’s configuration declares which servers it can reach, so the capability is readable before a single call is made. The composition is what matters: a tool that can read private data plus a tool that can send outside the organisation is a path, even if neither is alarming alone.

Govern360 reads tool manifests and connector definitions to show which tools an agent can call and what they compose into, and reports tool calls themselves as not observable - it is not in the call path and does not claim to be.

#Can two AI agents create a risk that neither has on its own?

Yes, and per-agent review is structurally blind to it. If one agent takes untrusted input and writes to a shared store, and a different agent reads that store and can send data outside the organisation, the exfiltration path is complete - but reviewed individually both agents pass, because the untrusted input and the egress never sit in the same record. The path exists only in the join.

Govern360 evaluates paths across agents rather than agent by agent, and states how each link is known - configured, declared or observed - so a join that was read from configuration is not presented as observed behaviour.

#Do we have to replace our existing security tools to govern AI?

No, and a product that requires it is asking you to rebuild controls you already run. The identity, endpoint, network, SaaS, cloud and data-security tools in place already hold most of the signal; what is missing is an AI-centric layer that correlates them into one view and knows what an agent is. The value is in the join, not in another enforcement point.

Govern360 is vendor-neutral and additive: it reads from the platforms you operate and compiles decisions back into them, rather than becoming the place where enforcement lives.

#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.

Govern360 carries cost on the same record as owner and purpose, so a platform invoice becomes attributable without a separate finops exercise. Budgets alert; they do not block.

#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.

Govern360 keeps the inventory current from platform APIs and records purpose and owner per system - the fields classification actually runs on - and maps the resulting evidence across the EU AI Act alongside NIST AI RMF, ISO 42001, the OWASP Agentic Top 10, MITRE ATLAS and SOC 2 control criteria.

#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.

Govern360 produces that pack directly: one measured number with its trend, what moved it, the share of the estate it rests on, and the decisions waiting on a person. It reports the figure and leaves the risk-appetite judgement to the board.

#How do I attribute AI token spend to teams and use cases?

Attribute at the identity that made the call, then roll up through ownership. Most AI bills arrive as a single platform line with no business dimension, which makes them impossible to challenge and easy to renew. The join that makes them legible is the one between the calling identity, the agent it belongs to, and the owner recorded against that agent - which is the same join governance needs anyway.

Govern360 carries cost on the same record as owner and purpose, so spend is attributable without a separate finops exercise. Budgets alert; they do not block.

#Where does AI spend usually get wasted?

Four places, in rough order of size: licences assigned in a rollout and never used, duplicate agents built by teams unaware of each other, oversized models used for tasks a smaller one handles, and pilots that were never retired. None of these is visible on an invoice, because the invoice aggregates them - which is why cost control for AI starts with an inventory rather than with a negotiation.

Govern360 reports unused assignment, duplicate agents and token waste as findings with owners, so reclamation has a named person rather than a line item.

#How often should AI exposure be reported to the board?

Quarterly for the number and its trend, immediately for anything that changes the risk picture materially. The quarterly rhythm matters more than the frequency: a figure that appears once is a status update, whereas the same figure across four quarters is a trajectory a board can hold someone to. What ruins it is changing the methodology between quarters, which makes movement unreadable.

Govern360 fixes the weights within a model version and publishes the version alongside the score, so a change between quarters reflects the environment rather than the arithmetic.

#How do I build a business case for AI governance?

On three lines that a CFO recognises: recoverable spend you can name, a regulatory obligation with a date, and a concentration of unowned capability that would be difficult to explain after an incident. The weakest case is the abstract risk argument, because it competes with every other abstract risk. The strongest is usually the first - unused licences and duplicate agents are recoverable in the current year.

Govern360 reports recoverable spend and accountability gaps as counts with owners, which is the form a business case needs.

#What do I show a regulator or auditor who asks about AI?

An inventory that is current, a classification with a rationale, named owners, evidence that review happens on a cycle, and an honest account of what you cannot yet see. The last item helps rather than hurts: a submission with no gaps invites the question of how you know, whereas a stated limit with a plan reads as a functioning programme.

Govern360 labels every evidence item with how it is known - verified, compiled, declared, observed or not measured - so the submission distinguishes what was confirmed from what was asserted.

#How is agentic AI risk different from LLM risk?

An LLM produces text; an agent takes actions. That single difference moves the question from ’was the output wrong’ to ’what did it do, as whom, and can it be undone’. A hallucinating chatbot is an accuracy problem. An agent with a write path, a connector out of the organisation and no named owner is an operational one, and the controls that address the first do very little about the second.

Govern360 scores agents on what they can reach and what they can do - permissions, connectors, autonomy tier, identity and egress - rather than on model behaviour, because those are the properties that are readable before something goes wrong.

#How do you defend against prompt injection in an enterprise?

Assume the model can be persuaded and constrain what persuasion can reach. Input filtering helps and will never be complete, because the instruction and the data arrive on the same channel by design. The durable control is architectural: an agent that ingests untrusted content should not also hold a path to private data and a route out of the organisation. Remove one leg and a successful injection has nowhere to go.

Govern360 evaluates the three legs - untrusted content in, private data read, a way out - per agent and across agents, and reports how each leg is known rather than asserting it was observed.

#What is the OWASP Agentic Top 10 and how do I use it?

It is a catalogue of the failure modes specific to agents - identity and privilege abuse, tool misuse, unexpected code execution, memory poisoning and the rest - and its practical use is as a checklist against configuration rather than as a threat model to discuss. Most entries correspond to something readable: which identity the agent holds, which tools it can call, whether it can execute, what persists between runs.

Govern360 maps agent configuration to the ASI codes and reports how many agents raise each one, so the catalogue becomes a count you can work through rather than a document.

#What is excessive agency, and how do I find it?

An agent holding more capability than its job requires - a read-only summariser with write permissions, an internal assistant with an external send path. It is the most common finding in an agent estate and the easiest to fix, because it is visible in configuration and does not require anything to have gone wrong first. The reason it accumulates is that permissions are granted at build time by people optimising for the thing working.

Govern360 compares each agent’s granted capability against its signed purpose, so the gap between what an agent may do and what it was approved to do is a finding with an owner rather than an observation.

#Is agent memory a governance problem?

Yes, on two counts. Anything persisted between runs is a place where untrusted content can be stored now and acted on later, which breaks the assumption that a single conversation is the unit of risk. It is also data retention: memory holds whatever the agent was exposed to, usually outside whatever retention schedule governs the source system.

Govern360 records knowledge sources and persistence as exposure factors on the agent record, so an agent that accumulates state is scored differently from one that does not.

#Where should a human stay in the loop with AI agents?

At irreversibility, not at importance. Approval gates placed on high-profile projects produce heavy review of harmless assistants and light review of agents that can delete, pay, or send outside the organisation. The better rule is mechanical: if the action cannot be undone by the person who would notice it, a human confirms it. That is a property of the permission, so it can be applied consistently rather than negotiated per project.

Govern360 records which agents act alone versus which ask first, and treats an unread autonomy tier as not assessed rather than defaulting it to the safest value.

#How do I govern multi-agent systems where agents call each other?

Govern the graph, not the nodes. Once agents invoke one another, capability composes: the effective reach of the first agent is the union of everything downstream of it, and no single record shows that. The practical requirement is an inventory that holds the edges as well as the entities, and that is explicit about which edges were read from configuration and which were inferred.

Govern360 draws the estate as a graph with the legend doing real work - colour for risk, line style for how the relationship is known - and leaves out edges it cannot evidence rather than drawing a more complete-looking picture than the data supports.

#How do I stop staff pasting sensitive data into AI tools?

Decide what must never leave, then enforce it in a plane that is already in the path - endpoint, browser or network - rather than relying on policy text. The part most programmes get wrong is scope: blocking public AI websites addresses the smallest share of the problem while the agent estate, which moves far more data with no human pasting anything, is untouched.

Govern360 decides what is allowed, redacted or blocked and compiles that into the planes that enforce it. It does not sit in the traffic path itself, and it marks each plane verified only where a read-back confirms the rule is live.

#Is AI DLP different from ordinary DLP?

The detection is similar; the topology is not. Classic DLP watches files and messages moving between known endpoints. AI introduces a channel where the sensitive content is typed or assembled at the moment of use, and a second channel where an agent moves data with no user present at all. A DLP programme that has not been extended to the point of use and to the agent estate is covering the traffic it was designed for and not the traffic that grew.

Govern360 covers both: what people send to AI tools, and what agents can reach by configuration - including the agents that operate with no active user session.

#How do I find out what data an AI agent can actually reach?

Read its connectors and its identity’s permissions, not its description. What an agent can reach is the intersection of the connectors attached to it and the scopes held by the identity it runs as, and both are readable without observing a single request. Descriptions are written at build time and go stale immediately; permissions do not.

Govern360 resolves each agent to its connectors, its identity and that identity’s scopes, and reports read, write, delete and egress separately, because they carry very different consequences.

#Can you tell me which specific document an AI tool opened?

Usually not, and a product that claims otherwise is worth questioning. Most platforms expose that an application holds access to a location, not which object within it was read at a given moment. Classification results and alerts are observable; object-level reads by an AI tool generally are not. The useful answer is to be precise about which of those you have.

Govern360 draws that node dashed and labels it not observable rather than omitting it, so the limit of the evidence is visible on the picture instead of being implied by its absence.

#How do I know an AI vendor is not training on our data?

From the contract and the tenant configuration, in that order, and then by checking that the configuration matches the contract. Enterprise agreements usually exclude training; the risk is that a consumer tier of the same product, reached through a personal OAuth grant, does not - and that is the path that tends to be in use. Vendor assurance covers the account you negotiated, not the account someone signed up for.

Govern360 records the vendor assessment state per tool and flags tools seen in use that have never been assessed, rather than treating an unassessed vendor as acceptable.

#Should we redact sensitive data before it reaches an AI tool, or block the request?

Redact where the work is legitimate and the identifier is incidental, block where the data class should never reach that destination at all. Blocking everything drives people to unmanaged tools, which converts a visible control into an invisible gap. The decision belongs to the data class and the destination together, which is why a single global setting rarely survives contact with real use.

Govern360 decides per data type and per destination - allowed, redacted or blocked - and shows which tools each rule applies to, so a rule that applies to nothing is visible as a finding rather than counted as coverage.

#What is non-human identity sprawl and why does AI accelerate it?

It is the accumulation of directory identities belonging to software rather than people, and AI accelerates it because every agent, connector and integration wants one - while almost nothing retires them. Machine identities also tend to outlive their purpose silently: there is no leaver process for a service principal, and no one notices an unused credential the way they notice an unused mailbox.

Govern360 inventories the machine identities behind AI systems alongside the agents themselves, and surfaces the ones with no owner, no rotation and no recent use.

#What happens when an AI agent has no machine identity of its own?

It runs as the person who created it, which breaks attribution everywhere downstream. Every call it makes appears in logs as that individual’s activity, so an investigation cannot separate what the human did from what the software did. There is also nothing to rotate and nothing to revoke: stopping the agent means disabling a person’s account or deleting the agent outright.

Govern360 reports agents holding no machine identity as a distinct finding, because the fix - issuing one - is different from the fix for an over-permissioned identity.

#How should credentials for AI agents be rotated?

On a schedule short enough that an undetected compromise expires, and tracked centrally so expiry is a planned event rather than an outage. The practical obstacle is that nobody knows which agent depends on which secret, so rotation breaks things and then stops happening. That dependency map is the prerequisite, not the rotation policy.

Govern360 tracks credential expiry against the agents that depend on them, so a rotation has a visible blast radius before it is performed.

#How do I apply least privilege to AI agents?

Grant against the signed purpose and re-check on a cycle, because agent permissions only ever accumulate otherwise. The common failure is granting broad scopes during development to get the thing working and never narrowing them, which is invisible until someone compares granted capability against stated purpose - a comparison nobody performs without a register that holds both.

Govern360 holds the purpose and the granted capability on the same record, which makes the comparison a report rather than a project.

#What does ISO 42001 require, and do we need it?

It specifies a management system for AI - defined roles, a risk process, an inventory of AI systems, impact assessment, and evidence that the whole thing operates rather than exists. Whether you need certification depends on whether customers are asking; whether you need the underlying inventory and ownership records is not really optional, because every other framework asks for the same things in different words.

Govern360 maintains the inventory, ownership and review records continuously and maps evidence across NIST AI RMF, OWASP Agentic Top 10, MITRE ATLAS, the EU AI Act, ISO 42001 and SOC 2 control criteria, so one set of facts answers several frameworks.

#How do I make the NIST AI RMF operational rather than a document?

Attach each function to a record that changes on its own. Govern, Map, Measure and Manage are useful as a structure and useless as a slide: Map needs a live inventory, Measure needs figures computed from the environment, Manage needs decisions with owners and dates. If the artefacts behind them are static documents, the framework describes intent rather than practice.

Govern360 produces those artefacts as continuous output - a platform-read inventory, a computed score with per-finding traceability, and a decision queue with named owners.

#Does the EU AI Act require an AI inventory?

In practice yes, whatever your obligations turn out to be. Every route through the Act - risk classification, transparency duties, documentation, post-market monitoring - begins with knowing which AI systems you operate and what they do. Organisations that cannot enumerate their systems cannot classify them, and classification is the gate on everything else.

Govern360 keeps the inventory current from platform APIs rather than from a form, and records purpose and owner per system, which are the fields classification actually needs.

#How does AI governance fit into SOC 2?

AI systems are in scope wherever they touch a system covered by your controls, which for agents with connectors is most of them. The awkward part is evidence: SOC 2 wants controls that operate continuously, and AI estates change faster than a quarterly review cycle, so point-in-time screenshots age badly between audit and report.

Govern360 compiles evidence continuously and marks each item with how it is known, so an auditor sees verified state where a read-back exists and an honest label where it does not. Govern360 itself is built to SOC 2 controls with its audit in progress.

#What is MITRE ATLAS used for in AI security?

It catalogues adversary behaviour against AI systems, in the same shape as ATT&CK, and its practical value is as a shared vocabulary between security teams and the people building AI. Where it is less useful is as a coverage checklist, because much of it describes behaviour rather than configuration, and behaviour needs telemetry that most agent platforms do not yet emit.

Govern360 references ATLAS alongside NIST AI RMF and the OWASP Agentic Top 10, and is explicit that configuration-derived findings are not the same as observed behaviour.

#Do I need a separate inventory for each AI framework?

No, and maintaining several is how they all go stale. The frameworks ask overlapping questions of the same underlying facts - what systems exist, who owns them, what they can reach, what was decided and when. One inventory with those fields answers all of them; separate spreadsheets per framework diverge within a quarter and then nobody trusts any of them.

Govern360 keeps one record per system and maps it across six frameworks, so evidence is compiled from a single set of facts rather than maintained per audit.

#Is Microsoft 365 Copilot governed by our existing Microsoft controls?

Partly, and the gap is agents rather than Copilot itself. Purview, Entra and Intune cover a great deal of what Copilot does with documents and identity. What they were not built to answer is the agent question: which agents exist across Copilot Studio, Agent Builder and Power Platform, which connectors each holds, which identity each runs as, and who is accountable. Those records exist in the platform APIs but not in one place.

Govern360 reads those APIs and correlates them into one agent view, adding an AI-centric layer over the Microsoft controls you already operate rather than replacing them. AIVONS is a Microsoft AI Cloud Partner, Partner ID 7144707.

#Why does Copilot surface documents people were not supposed to see?

Because it makes existing permissions legible. Copilot generally respects the permissions it is given; the problem is that those permissions were set years ago on the assumption that nobody would find the file. Search made over-permissive sharing theoretically discoverable, and Copilot makes it practically discoverable, so a latent access problem becomes a visible one overnight.

Govern360 treats that as an access governance finding with a point value in the score, rather than as a Copilot setting to change.

#How do I govern agents built in Copilot Studio?

Enumerate them from the platform, resolve each to its environment, creator, connectors and identity, then decide which need an owner and an approval before anything else. The reason this is urgent rather than routine is that Copilot Studio was designed so that publishing does not require a security review, which is excellent for adoption and means the estate grows without a gate.

Govern360 enumerates Copilot Studio, Microsoft 365 Agent Builder and Power Platform through a read-only, consent-scoped application registration - no agent installed on any device, no traffic interception.

#How do I tell which Copilot licences are actually being used?

Read usage per assigned licence rather than per department, and look at the distribution rather than the average. Copilot spend tends to fail in a specific way: a block of licences assigned during a rollout, a minority using them daily, and no process that reclaims the rest because nobody owns the reclamation.

Govern360 reports consumption against assignment and surfaces unused licences as recoverable cost. Budgets in Govern360 alert; they do not block.

#Does Microsoft Purview see what agents are doing?

It sees data activity in the systems it covers, which is substantial, but it does not present an agent-centric view: which agents exist, what each can reach, who owns them, and which combinations form a path. Those are questions about configuration across several platforms rather than about data events in one.

Govern360 correlates Purview signals with agent inventory, identity and connector data, and compiles decisions back into Purview where Purview is the right plane to enforce them.

#Why should I take a newer AI governance vendor seriously?

Judge the claims rather than the company age, because in a category this young everyone’s track record is short and the vendors with the longest histories are the ones that added AI to an existing product. The useful tests are whether the methodology is published, whether the product distinguishes what it verified from what it assumed, and whether it will tell you what it cannot see. A vendor that shows you its limits is describing a real system.

Govern360 publishes its scoring weights and derivation, marks state as verified only where a platform read-back confirms it, labels unmeasured domains as earning nothing rather than scoring them zero, and holds four provisional patents, all pending. AIVONS is a Microsoft AI Cloud Partner, Partner ID 7144707, and Govern360 is built to SOC 2 controls with its audit in progress.

#What should I ask an AI governance vendor in an evaluation?

Four questions that are hard to answer with a demo. Where does each number come from, and can you show me the derivation. What happens to a control you cannot read back - does it show green. How do you handle a dimension you cannot measure. And what in my estate would you expect to miss. The last one is the most diagnostic: a vendor with no answer has not thought about its own coverage.

Govern360’s answer to the fourth is published - tool calls are not observable because it is not in the call path, and object-level reads by an AI tool are generally beyond what platform APIs expose. Both are drawn as such rather than omitted.

#What does it take to start with Govern360?

A read-only, consent-scoped connection to the platforms you want covered, and a person who can approve it. No agent is installed on any device, nothing sits in the network path, and discovery does not require replacing anything. The first inventory typically appears within hours of the first source being connected, and coverage grows as more are added.

Govern360’s optional endpoint collector is a PowerShell script run from your RMM that installs nothing and needs no admin rights; the managed browser extension is separate and also optional. Neither is required to produce a Govern360 score.

#What will Govern360 not do?

It is never a hop in your traffic path and it does not remediate on its own. It decides and compiles; the planes you already own enforce — including, on Enterprise Claude surfaces, the platform’s own inference checkpoint, which asks Govern360 for a verdict before an action runs and acts on the answer. It also will not show a control as verified unless a platform read-back confirms the live state, and it will not count something it could not measure as a zero.

Those are architectural commitments in Govern360 rather than a roadmap gap: a governance layer that becomes a network hop is a latency budget and a single point of failure, and the first serious outage ends the programme.

#Can I test an AI governance product against my own estate before buying?

You should, and the useful version is not a scripted demo. Bring the case you think the product will miss - the agent nobody owns, the connector that should not exist, the path that only completes between two systems - and watch whether the product finds it or tells you honestly that it cannot see it.

That is the standing Govern360 offer: bring the problem you think will be missed rather than asking for a demo.

#We have no AI governance at all. Where do we start?

Inventory first, ownership second, everything else after. Policy written before the inventory exists is written against an imagined estate and does not survive contact with the real one; controls deployed before ownership exists have nobody to route exceptions to. The first ninety days are best spent answering what exists, who is accountable, and which systems can take irreversible actions.

That sequence is the Govern360 order - Discover, Govern, Protect, Control, Prove - and the score weights it accordingly, because every other dimension depends on a complete inventory.

#What does good AI governance actually look like in practice?

Boring and current. Every AI system has a named owner and a signed purpose, capability matches purpose, irreversible actions have a human gate, the inventory updates itself, and the report to the board says what is not covered as clearly as what is. The absence of drama is the signal: programmes that look exciting are usually responding to something.

Govern360 measures those properties directly - ownership rate, signed purpose, autonomy tier, coverage - rather than asking whether a policy exists.

#What do I need in place before an AI incident, not after?

Three things that are very hard to assemble under pressure: which agents exist and what each can reach, which identity each runs as, and who is accountable for each. Without them the first hours go on reconstructing the estate rather than containing anything. Notably, all three are configuration facts available today, not telemetry you have to have been collecting.

Govern360 keeps those three current from platform APIs, so the map exists before it is needed rather than being built during the incident.

#How often should individual AI agents be reviewed?

On a cycle tied to what the agent can do, not a single interval for everything. An agent that can act alone or send data outside the organisation warrants a short cycle; a read-only summariser does not, and forcing one on it wastes the review capacity the first group needs. The cycle also has to have teeth - a review that lapses should change the record rather than being quietly carried forward.

Lapsed reviews cost points in Govern360 as stale evidence, named on the finding, so a review cycle that has stopped operating is visible rather than assumed.

#How do I reduce shadow AI without banning AI?

Make the sanctioned path faster than the unsanctioned one, and make the unsanctioned one visible. Bans move usage to personal accounts and personal devices, where you lose both the data and the signal. The combination that works is a short approval route for low-risk use, a clear list of what is never permitted, and continuous discovery so the gap between the two is measured rather than assumed to be zero.

Govern360 surfaces discovered tools for a decision rather than labelling them automatically - nothing is shadow AI until a person says so - because an inventory that auto-labels is making governance decisions no one asked it to make.

#Can a small security team run AI governance without more headcount?

Yes, if the inventory maintains itself and the work arrives as decisions rather than as data. What consumes a small team is manual collection - chasing teams for declarations, reconciling spreadsheets, rebuilding the picture each quarter. Remove that and what is left is a queue of judgements, which is work a small team can actually do.

Govern360 is built around that split: the platform reads and correlates, and a person decides. The console leads with what is waiting on a decision rather than with the full inventory.

#What is AI governance?

The practice of knowing which AI systems you operate, who is accountable for each, what they are allowed to do, and being able to show that this is true. It is distinct from AI ethics, which is about what you should build, and from AI safety, which is about model behaviour. Governance is the operational layer: inventory, ownership, permission, review and evidence.

Govern360 is an AI governance control plane covering five dimensions - Discover, Govern, Protect, Control, Prove - and rolls them into one explainable 0-100 AI Exposure Score where every point traces to a specific finding.

#What is AI security posture management (AI-SPM)?

The security-configuration view of an AI estate: which systems exist, how they are configured, where the misconfigurations are. It answers questions in the shape of CSPM, applied to AI. Governance is the larger frame around it, adding ownership, purpose, approval, cost and evidence - the questions a regulator or a board asks, which a posture tool alone does not hold.

Govern360 covers posture as one part of a governance control plane, which is why its records carry owner, purpose and cost beside the security attributes.

#What is an AI exposure score?

A single measure of how governed and how exposed an AI estate is, decomposed into dimensions so the number is actionable rather than decorative. The quality of any such score rests on two properties: whether it is computed from measured facts rather than self-assessment, and whether every point can be traced back to the finding that produced it. Without both it is a grade, not an instrument.

The Govern360 AI Exposure Score is a weighted geometric mean of AI Discovery, Governance, Protection, Control and Compliance, published with the share of the estate it rests on and traceable from score to dimension to module to finding to task.

#What is an AI agent, as opposed to a chatbot?

An agent can take actions in systems; a chatbot returns text. The practical boundary is whether it holds a connector, a tool or a permission that changes something outside the conversation. That boundary matters because it decides which controls apply: a chatbot is an accuracy and data-handling question, while an agent is additionally an identity, permission and accountability question.

Govern360 records the autonomy tier each system holds - from answers only through to acts alone - and treats a tier it could not read as not assessed rather than as the safest option.

#What is an AI bill of materials, and do I need one?

A record of what an AI system is made of - models, data sources, tools, connectors and the identities involved. It is useful for the same reason an SBOM is: when a component turns out to be a problem, the question becomes which systems are affected, and that is unanswerable without the mapping. For agents it matters more than for models, because the connectors are where the reach lives.

Govern360 holds model, platform, connectors, identity, data reach and owner on one record per system, which is the mapping an AI BOM is asking for.

#Why is untrusted input plus private data plus egress considered the dangerous combination?

Because each is harmless alone and together they form a complete path. Untrusted content can carry an instruction, private data gives that instruction something worth taking, and an egress route gives it somewhere to go. Any one leg removed and the path does not complete, which is why the combination - rather than any single permission - is the thing worth searching an estate for.

Govern360 evaluates the three legs per agent and across agents, because the path frequently completes between two systems that each look acceptable on their own.

#Is AI governance the same as model risk management?

No, though they overlap and financial services teams often start from MRM. Model risk management asks whether a model is fit for its purpose - validation, performance, drift. AI governance asks which AI systems exist at all, who owns them, what they can reach and what they may do. An estate can have excellent validation of the models it knows about and no idea how many agents are running.

Govern360 addresses the second question and produces records the first can consume - inventory, ownership, purpose and capability per system.

#What is an AI governance control plane?

A layer that decides policy centrally and pushes it into the systems that enforce it, rather than enforcing it itself. The distinction matters operationally: a control plane can be added to an estate without becoming a dependency in the data path, so an outage degrades governance rather than stopping work. It is the same separation as policy versus enforcement in networking.

Govern360 is a control plane in exactly that sense - it decides and compiles into Purview, Intune and the rest, and marks each plane verified, compiled or planned according to what has actually been confirmed.

#Is AI governance just CASB or DSPM with a new label?

No, though both contribute signal. A CASB sees applications reached over the network and a DSPM sees where data sits and how it is exposed; neither knows what an agent is, which identity it runs as, what it was approved to do, or who is accountable for it. The AI question is about capability and accountability at the system level, and it is answered in platform control planes rather than in traffic or storage.

Govern360 reads the platform control planes and correlates them with the identity, endpoint, network, SaaS, cloud and data-security tools already in place, so those signals become one AI view instead of staying in a dozen consoles.

#Could we just build AI governance ourselves from the platform APIs?

You can build the inventory, and plenty of teams have. What is harder to sustain is everything after it: keeping connectors current as platforms change, resolving agents to identities and permissions across products, holding decisions and review cycles, and producing evidence that distinguishes what was verified from what was assumed. Most internal builds stall at a script that answers how many agents exist, which is the easy part.

Govern360 publishes its scoring methodology and weights, so an internal build can borrow the model even if it does not buy the product.

#Does AI governance only work if we are a Microsoft estate?

No, though Microsoft estates tend to be where the agent problem is largest today, because Copilot Studio and Power Platform let people publish agents without a security review. The same questions apply wherever agents are built, and the same records are needed - inventory, identity, connectors, owner, purpose.

Govern360 is vendor-neutral, covering AI platforms including OpenAI, Anthropic, Microsoft Copilot, GitHub Copilot, AWS Bedrock and Google Vertex, with enforcement compiled into planes such as Purview, Intune, Zscaler and the major clouds - each marked verified, compiled or planned according to what has been confirmed.

#Will AI agents outnumber employees, and does that change governance?

In estates that have rolled out agent-building platforms they frequently already do, and it changes governance in one specific way: processes that assume a human at the other end stop working. Joiner-mover-leaver has no equivalent for agents, access review assumes someone can explain why they need access, and attestation assumes a person to attest. Those gaps are procedural rather than technical, and they are what an agent inventory exposes first.

Govern360 treats the agent as the unit of governance - with an owner, a purpose, an identity and a review cycle - rather than attaching agents to the human processes that were not designed for them.

#How quickly can we show measurable progress on AI governance?

Inventory within days, a defensible baseline number within the first weeks, and visible movement within a quarter - provided the early work goes on ownership rather than on policy. Ownership moves the number fastest because it is the most common gap and the fix is a decision rather than a deployment. Programmes that start with a policy document typically have nothing measurable to show at the first quarterly review.

Govern360 reports the change over time alongside the absolute figure, and each finding carries the points it is worth, so the sequence of fixes that moves the score most is visible before the work starts.

#What actually goes wrong if we do nothing about AI governance for a year?

Nothing visible, which is the difficulty. The estate grows, ownership thins out as people move roles, permissions accumulate, and the first moment anyone needs the inventory is during an incident or an audit - when it has to be built under time pressure and without the people who created the systems. The cost is not a breach that was certain to happen; it is that every subsequent option becomes more expensive.

Govern360 exists to make that accumulation visible while it is still cheap to reverse, which is why the first output is an inventory and an accountability count rather than a policy.

#Does Govern360 sit inline in the request path?

No. Runtime evidence reaches Govern360 because the customer’s own OpenTelemetry collector exports traces to it. Govern360 receives those traces; it is not a hop the request passes through and adds no latency, so telemetry on its own never stops a call. Where a decision is wanted before an action runs, the arrangement is the same one used everywhere else — Govern360 decides and the plane enforces. On Enterprise Claude surfaces that plane is the platform’s own inference checkpoint, which asks Govern360 for a verdict and acts on the answer. Every product that sees runtime by sitting in the path is a proxy you have to defend a latency budget for. This one is still not.

#What does Govern360 mean by real-time?

Seconds to minutes after the source exports, and it never means Govern360 became a hop in the path. The figure depends on the customer’s collector export interval, not on anything Govern360 controls, so the honest description is that telemetry evidence lands shortly after the span is exported rather than at the moment of the call. A runtime verdict is a different mechanism and should not be read off this number: there the platform’s checkpoint asks Govern360 before the action runs.

#What is the difference between what an agent is configured to do and what it actually did?

Configured means a source configuration permits or requires it — read from the agent’s setup, which it may never have exercised. Observed means a source event proves the call completed. Govern360 reports both, and never merges them: a policy decision such as a DENY is a permission or a refusal, not an observed action, and is never drawn as one.

#How does runtime telemetry reach Govern360?

Traces arrive in standard OpenTelemetry format from the collector the customer already runs. Each connector holds its own token with an expiry, rotation with overlap and a quota, and at most two live tokens at a time. Test connectors are kept separate from production so trial traffic never lands in production evidence.

#How is a trace matched to a known agent?

Only by an exact identifier. A name that merely looks like a match is not accepted — it goes to a review queue for a person to confirm. Guessing here would attach real runtime behaviour to the wrong agent, which is worse than leaving it unattributed.

#What is Release Certification?

A tiered, signed approval for a production agent, tied to its model, purpose, tools and autonomy tier. If any of those pinned parts change, the approval is marked changed rather than silently remaining valid, and it expires on a schedule. An approval is a statement about a moment; agents change weekly, so the certificate has to know when it has been outrun.

#What do runtime findings actually catch?

Agents that were retired but are still running, agents in production with no current certificate, model drift away from what was approved, tools being called that are not on the approved list, and data going to destinations outside the allow list. They are checked hourly and raised into the existing alert feed rather than a second parallel pipeline.

#Does a runtime finding block or stop an agent?

No. A finding is evidence, not enforcement. It never blocks, never stops an agent and never changes a certificate. Where an enabled policy blocks a tool and the source reports the call completed anyway, the finding says the block did not hold — and it says that only when the source actually reported completion, never on suspicion.

#Can we test a policy without enforcing it?

Yes. A dry run asks the live decision engine what it would decide, with nothing enforced. A dry run is never a decision: it reads not enforced, never enters the decision log, and never opens an approval request. You can also replay the last 30 days of observed tool calls against today’s rules to see what a proposed change would have done.

#How does runtime evidence change what we are billed?

By itself, not at all. Each model call is marked as confirmed by both sources, seen only at runtime, or seen only in spend records. The interesting column is the middle one — it ran, and it is in nobody’s bill. Counting runtime-only usage is opt-in per organisation and counts from the moment it is switched on, so no closed month ever moves.

#What is provider posture?

A single read, per AI provider, putting the connection, keys, projects, admin log, spend and runtime activity side by side. It writes nothing, calls no provider and reads no credential. Gaps are named in words: a provider with no connection reads not visible, never no keys; an admin log that could not be read says so with the reason.

#Can runtime findings go to our SIEM?

Yes, outbound only and off by default, through the existing SIEM forwarding rather than a new channel. For auditors there is a runtime assurance evidence pack with a SHA-256 checksum list, so what you hand over can be shown not to have changed since it was generated.

#Does runtime telemetry mean you now store our prompts?

No. The capture mode permits metadata only and nothing else is accepted. Prompt text and model responses are never stored. What arrives is span metadata — which model, which tool, which destination, how many tokens — not what anyone typed.

#Can you see which employee triggered an agent?

Not by name on default screens. The initiator is stored as an HMAC under a per-organisation key held inside the database, together with the type of initiator. Runtime findings are about agents, not scores of people.

#What do the runtime screens show before we connect telemetry?

They say no runtime telemetry is connected. They never show zero runs, because zero is a measurement and this is an absence of one. If a connector exists but nothing arrived in the window, it says no events were observed in connected telemetry during the selected period — which is a different statement, and the difference matters.

#What does Govern360 see at runtime?

What the agent actually did — from traces exported by the customer’s own telemetry collector, without sitting in the request path. That covers runtime intake, agent identity resolution, release certification, runtime findings, policy dry runs and replay, runtime spend reconciliation, provider posture, SIEM forwarding with an evidence pack, and linkage maps on every runtime surface.

#How many integrations does Govern360 have?

Thirty-four you can turn on today: 21 are connected in a working estate and 13 more are built and ready to connect. A further 16 are named on the roadmap and are not built yet. The roadmap items are listed by name rather than left out, so the gaps are visible before you buy instead of after.

#Which sources are connected today?

Microsoft 365, Entra ID, Power Platform agents and consumption, SharePoint and OneDrive, Azure OpenAI, Azure DevOps, AWS, Amazon Bedrock, OpenAI, Anthropic, Hatz AI, Ramp, SAP Concur, CrowdStrike Falcon, SentinelOne, Tanium, Zero Networks, Horizon3.ai NodeZero, SASE network logs and Slack.

#Which integrations are not built yet?

Okta, Google Workspace Admin, Workday, SAP, NetSuite, SCIM and HRIS mapping, cost-centre mapping by CSV, Snowflake, Databricks, Confluence, Notion, Jira, Zoom, DocuSign, Adobe and HubSpot. Sixteen in total. If one of them is the source that matters to you, saying so moves it up the order, but today the honest answer is that it is not available.

#What can Govern360 actually act on?

Six actions, each opt-in per connector: Contain on CrowdStrike Falcon, Disconnect from network on SentinelOne, Quarantine on Tanium and on Power Platform agents, Isolate on Zero Networks, block lists pushed to Palo Alto, and service requests raised in Jira Service Management. Every one is started by a person, written to the audit chain with who did it and when, and runs on a credential you issue and can revoke. Discovery and scoring remain read-only, and Govern360 is never in the traffic path.

#Does Govern360 hold write credentials into our systems?

It holds no blanket write access and never remediates on its own. Where you switch on one of the six named actions, the connector holds a credential you issued, scoped to that platform, revocable at any time, and used only when a person starts the action. Everything else is read-only.

#What is the difference between inspected in browser and network rules only?

Inspected in browser means the managed extension reads prompt text before it is sent and can block or redact it. Network rules only means the tool is in your inventory and the SASE runbook can block or coach it, but nothing reads what was typed. Of the 33 AI tools watched, 30 are inspected in the browser and 3 by network rules only.

#Can the browser extension see inside a desktop application?

No. A native desktop application is network-only whatever the browser column says, because an extension cannot see inside one. That limit is published beside the tool list rather than left for a customer to discover.

#Do we need every source connected to get a score?

No. Coverage is published as a fraction from the first read. A source you have not connected reduces coverage and says so; it is never scored as if it were clean, and never as if it were failing.

#Can you connect a source that is not on the list?

Custom integrations are included wherever the platform exposes a read path. Where no read path exists, that is said plainly rather than worked around with an agent or a proxy.

#Are the AI tools you watch the same thing as integrations?

No, they are two separate lists. Integrations are sources Govern360 authenticates to and reads — management APIs, billing APIs, security platforms. AI surfaces are the tools it watches; nothing there authenticates to a vendor API.

#What is an AI governance OS?

An operating model rather than a product category. One record per AI asset carried from discovery to retirement, a control plane that decides and compiles, the enforcement planes the organisation already owns doing the enforcing, and a closed loop that reads the applied state back and seals the evidence. Govern360 is in the decision path, never the request path.

#Does Govern360 replace Entra, Purview or Defender?

No. It does not sit in the request path and it replaces no enforcement plane. It decides, compiles governance intent into the planes the customer controls, and verifies by reading the applied state back. Those planes keep their existing operational owner, which is the point — a governance layer that becomes a network hop is a latency budget and a single point of failure.

#What are the six layers of the operating model?

People and accountability; obligations and classification; lifecycle and gates; agents, models and tools; data and endpoint; and the enforcement planes. Discovery sits under all six, because nothing above it can govern an asset it has not found.

#What are the two gates an agent passes through?

Architecture review is the design gate and release certification is the deploy gate. An agent moves from discovered, to owned and purposed, through both gates, to operating, and then to suspended or retired with its sessions revoked. A change to the configuration fingerprint re-opens the review rather than leaving the certificate silently valid.

#What is the closed loop?

Detect daily, score exposure, decide and approve, compile and push, read back and verify, seal evidence. The loop is what makes the score a measurement rather than a snapshot: every point traces to a configuration that was read back, not asserted.

#What does in the decision path, not the request path mean?

Every product that enforces at request time is a hop your traffic passes through, with a latency budget to defend and an outage that stops the business. Govern360 decides what should happen and compiles that decision into the planes that already sit in the path. It is in the path of the decision, never the path of the call.

#Is the whole operating model built?

Most of it, and the map marks the exceptions rather than hiding them. Guarded lifecycle transitions are partial — the states and events exist, but one function as the only write path does not yet. Runtime assurance is built and has had no customer telemetry through it, so it reads awaiting customer data rather than being shown as working. A capability with no traffic through it is not the same as a capability in use.

#How does runtime authorization work with no proxy and no agent?

The platform holds the checkpoint. On Enterprise Claude surfaces the platform’s inference hooks call Govern360 before a prompt runs and, with tool-call validation enabled, before a tool executes; Govern360 answers from the signed authorization credential it already holds for that agent. Nothing is deployed into agents, browsers or endpoints, and Govern360 is still not a hop the request passes through — it is asked, out of band, by the platform that is.

#Is runtime authorization enforcing anything today?

No. It ships dormant and shadow-first: it logs the verdict it would have returned, at a staged rollout percentage, with a kill switch, and nothing is enforced until an owner turns it on. It is also fail-open by construction — if Govern360 cannot answer, the action proceeds rather than the platform stalling. A control that takes the business down when the governance layer has a bad day is not a control anyone keeps.

#What does a runtime verdict evaluate, and what is stored?

Per tool call: tool allow or deny, the side-effect class (read, write, send, delete, deploy), the egress allow list, tool-definition drift since approval, and sensitive-data detectors, all against that agent’s contract. Govern360 reads the transcript and tool calls only to decide and stores only the verdict and its metadata, never prompt, response or tool-argument content. Every enforced block is written to the sealed, hash-chained audit record.

#What is runtime authorization not?

Allow or deny only — it does not redact content. Image-only requests are not inspected. It covers Enterprise Claude surfaces rather than Bedrock, Vertex or the raw API, and some native tool calls are not covered. It is one control in a layered programme, not a sole control, and saying otherwise would be the overclaim you discover at the worst moment.

#What is an agent authorization credential?

A signed, verifiable passport for one agent. It bundles the executive authorization, the signed purpose, the tool and data contract, the fingerprints of the approved tools and the release certification into a single document sealed with a SHA-256 fingerprint, which you can open, print to PDF or export as JSON. Regenerate it later and the fingerprint matches only if nothing has changed, which is what makes it tamper-evident proof of what was authorized, by whom and when. It attests the authorizations on record; it does not judge whether the authorization was wise.

#What is MCP tool drift, and why does it matter?

An approved tool does not always stay the same. When an MCP tool’s definition changes after a human approved it — the rug pull, where a trusted tool quietly becomes something else — it is raised as a drift signal in the MCP Gateway and carried into the runtime verdict, so a changed-since-approved tool can be caught at the moment it is used rather than at the next review. Drift is measured against the approved fingerprint, never against a guess at intent.

#What is in the discovery report?

One consolidated document rather than a scan to interpret: the AI inventory across the estate — endpoints and the AI running on them, browser AI, MCP tools, local models and agents — alongside the risk view of exposure, owners, vendor risk and the controls already in place. It is white-labelled under your own Prepared by line, so an MSP, a CISO or a consultant can brand it and send it.

#How do I connect Claude Platform telemetry to Govern360?

Through a standard OpenTelemetry (OTel) Collector. Anthropic’s OpenTelemetry export is protobuf, gzip-compressed and not configurable, so it cannot be pointed straight at a JSON intake. Govern360 gives you a guided setup that generates the exact collector configuration and destination steps, and the collector translates the export into the JSON intake. Metadata only, the same as every other runtime source. Native direct ingest is on the roadmap — this is the path that works today.

#How do I know a connection is actually working, not just configured?

Health is derived from what actually arrived, not from whether a credential was saved. Each source reads expired, failing, stale, degraded, pending, sends-only or healthy, and fetch status is kept separate from freshness, because a call that succeeded and returned nothing is not the same as a call that never ran. A source that has never completed a sync reads no completed sync on record rather than showing a zero.

#How does Govern360 secure and rank the credentials it holds?

Every credential Govern360 holds is treated as a non-human identity in its own right. Each carries a 0-100 credential-risk score mapped to the OWASP Non-Human Identity Top 10, printed as the factors behind it rather than as a black box, alongside what the credential can see and where to revoke it. Credentials are AES-256-GCM encrypted at rest and are never returned to the browser. No connection uses a secretless method yet, and the page says so.

#What makes the AI Exposure Report a report of record?

Recording it freezes the figures. Twelve sections in three editions - board, CISO and auditor - are built from a single read, and recording stores their SHA-256 chained to the report before it, append-only, with a waterfall of what moved by dimension since the last one. A live view is marked as not the report of record. There is no dollar-of-loss-avoided figure anywhere in it.

#What is the evidence ladder, and what counts as verified?

Six rungs on the evidence ladder: Verified, Configured, Claimed, Stale, Compiled, None. Only a read-back of the live state from the plane itself earns Verified - everything below it is a weaker claim, named as the weaker claim it is. Intune is re-read from Graph every 15 minutes and compared requirement by requirement, moving to verified, drifted or superseded. It is the only scheduled read-back today, and three of its eight compiled requirements are readable on the Graph compliance resource.

#How do I find API keys that bypass our identity provider?

Govern360 lists the API keys, service accounts and key-accepting Azure AI resources that reach a model provider without passing through Entra - OpenAI, Anthropic, Azure AI, LiteLLM - ranked by what makes each one risky: admin scope, no owner, unused for 90 days, age and review state. Metadata only. Listing keys needs an admin key, and providers do not report which agent used a key, so keys are not linked to agents.

#Does Govern360 replace Microsoft Agent 365?

No - it sits beside it. Agents Govern360 discovered are shown side by side with the Microsoft Agent 365 registry, so an agent registered on either side is visible in one place, with duplicate clusters so a single decision covers a cluster rather than one row at a time. The Microsoft registry needs an Agent 365 licence; without one the tab says so and still lists what Govern360 found.

#What is authorization intent, and how is it different from purpose?

Purpose is what an agent is for. Authorization intent sits upstream of it: a signed record of what leadership authorised the agent to do and what judgment was delegated, placed beside what the runtime layer actually observed. Structural flags mark the gaps - active with no signed authorisation, authorisation signed after activity was already seen, recorded but never signed. It records and compares; it does not read the wording and judge whether behaviour matches its meaning, which is a human call.