Can you see it, does it behave, what stops it?

Ask an organisation whether it has AI visibility, assurance and protection in place, and the answer is usually yes. The trouble is what that tends to mean: visibility as optional telemetry, assurance as a one-time review, and protection as a late-stage hardening exercise. That was tolerable while AI answered questions and a human decided what to do with the answer. It stops being tolerable once AI starts acting on its own.

Governance decides what should happen. This post is about the three areas that make those decisions operational, so an organisation can see them, prove them and enforce them. It also covers how each area changes when the AI is an agent.

Govern actions, not just intelligence

Start with the order in which decisions get made. Too many AI programmes start with technology: a platform chosen on a vendor’s recommendation, or because the licences are already there. Processes are then bent to fit the tool, people are trained on the platform, and a strategy is written last to justify what has already been decided. The order should be the reverse: business intent first, then people, then processes, and technology last. The platform is the last decision, not the first.

Governance connects people, processes and technology across four levels:

• Strategic: what we commit to.
• Tactical: the policies and processes that carry the commitment.
• Operational: the technology that enforces and monitors it.
• Foundational: the people and the change management that make it stick.

Done well, governance gives clear ownership, repeatable decisions, practical guardrails, and people who are confident using AI. It should make AI easier to run, not heavier to use.

Agents make all of this more pressing. With a classical AI assistant, a human asks, the model answers and the human decides. An agent acts on delegated authority: it takes a goal, plans, calls tools and systems, acts, observes the result and adapts. The focus of governance moves with it, to authority and delegation, permissions and boundaries, actions and outcomes, runtime monitoring, and the ability to intervene. The shared foundation (accountability, roles, risk management, security, data governance, lifecycle and literacy) stays the same.

That leaves three questions every leadership team putting agents into production should be able to answer:

1. How much visibility do we have into AI and agentic AI deployment?
2. How aware are we of the implications and capabilities of autonomous AI?
3. Do we have the right security guardrails for managing AI agents?

Three questions, three pillars

Each of those questions is the leadership version of a pillar:

• Visibility: can you see it?
• Risk & Assurance: does it behave?
• Protection: what stops it?

Governance is not a fourth pillar alongside them. It is the frame they sit in, and it forms the strategic level at the top of each one. The three pillars are how governance becomes operational. Each pillar has to run all the way down through the levels (strategic, tactical, operational), because that is where most programmes quietly stop.

Visibility: can you see it?

You can’t govern or secure what you don’t know exists. Visibility means knowing which AI systems and agents exist, what they can do, what they can touch, what they did and with what objective. That knowledge has to be available at the moment it matters, not once a year.

Strategic: one list to argue from. Many organisations have multiple lists: the IT inventory, the security team’s list and an export from whichever platform built the agents. They disagree. Leadership needs one registry, the list it argues from, backed by a commitment: we will know what exists and what it did. Attribution is not negotiable.

Attribution means every action resolves to an agent identity, and every agent has an accountable owner or sponsor who answers for its risks and the consequences of what it does. Where that isn’t technically possible yet, the fallback has to be explicitly accepted as a risk.

The strategic level also decides how shadow agents are treated. They are an operational problem, not only a policy violation. They need to be found, classified, contained or remediated according to their risk, and their builders need education.

Tactical: a registry is a routine, not a purchase. An inventory that isn’t reconciled is a list, not a control. Four routines keep it true:

1. Register at creation, and update the record when capability changes. Registering at deployment is already too late, because the tools, connectors and data sources were decided during the build.
2. Reconcile on a cadence against real signals from identity, SaaS and connector telemetry. Completeness is measured, not assumed. This is the single practice that separates a control from a spreadsheet.
3. Write a telemetry standard that names the required event types, correlation identifiers, retention periods and the queries an investigation will actually need. Write it down before the first agent ships, not after the first incident.
4. Give shadow discovery an owner. It runs on a schedule, someone receives the output, and there is a defined response path. Discovery without a response path produces a list nobody reads.

Operational: identity per agent, telemetry at the level of actions, and discovery of the ones nobody registered. At this level the platform has to answer four questions when it matters: what acted, under whose authority, with which tools, and on which data. Answering them takes five things:

• a registry
• a distinct identity for each agent
• an audit event for every invocation and tool call
• a map of what each agent can reach
• discovery that feeds unregistered agents back into the registry

The weak point is the telemetry itself: an agent that emits no invocation event is invisible to every view. Registration is a telemetry standard, not a form.

In Microsoft today (status as of October 2026)

• Registry: Microsoft Agent 365 (GA since May 2026) gives one tenant-wide inventory across Copilot Studio, Foundry and connected third-party platforms. It shows owner, platform and status, and counts the agents that have no owner.
• Identity: Microsoft Entra Agent ID (GA since April 2026) gives each agent a distinct identity, created from a blueprint, with a sponsor required at creation. Agent sign-ins are their own event type in the logs.
• Action audit: Microsoft Purview Audit records invocations, tool calls and model calls as audit events. DSPM adds a per-agent view of activity, risk level and sensitive interactions for agents active in the last 30 days.
• Reach: Microsoft Defender maps each agent’s declared tools, MCP servers and identities, and what those identities can reach. Agent-level posture is in preview.
• Discovery: Defender for Endpoint finds local agents on Windows and macOS laptops (macOS in preview), Entra Global Secure Access finds agents in network traffic (preview), and Defender for Cloud Apps finds SaaS AI apps.

Risk & Assurance: does it behave?

Risk & Assurance is where business intent turns into security and compliance consequences. Its objective is to validate, continuously, that an AI system is safe, secure, compliant and fit for purpose, and to tie the depth of that assurance to the actual risk. As a question: can we show it is safe enough before release, and that it stays that way after change? The second half is where most assurance falls short.

Strategic: a loop and a limit. Risk & Assurance is not separate paperwork; it is a closed loop between levels. It works like this:

• Leadership sets the objectives for AI and the risk the organisation is willing to accept. Those risk preferences have to be made explicit, or nobody below can apply them.
• The tactical level turns them into processes and requirements.
• The operational level turns them into concrete measures on each agent as it is built and deployed.
• Evidence flows back up so leadership can see whether its preferences hold, and correct course.

The limit is that you can’t govern everything at the same intensity. Over-control the trivial and the business routes around you. Under-control the serious and you find out later. The first direction stalls progress and pushes people towards ungoverned alternatives. The second takes on risk nobody chose, and the discovery comes from an incident or an audit. A blanket no is not a strategy either.

Telling the trivial from the serious takes two questions.

Autonomy: how independently does the agent decide and act? Each level up removes a point at which a person could catch a mistake:

• A1 assistive: it proposes, a person acts. It searches, summarises and drafts, but changes nothing itself. Classical AI, such as Copilot chat or a RAG application, sits here.
• A2 gated: it acts, but every consequential action waits for approval through a gate it cannot skip.
• A3 autonomous: a person approves the run, not each action, and supervises the outcome.
• A4 self-initiated: nobody starts the run. It acts on its own trigger, sets its own sub-goals and adapts. The person only observes.

Capability: what can it do, and what can it reach? Autonomy tells you who is watching; capability tells you how much damage a mistake can do. The levels read like job titles: C1 analyst reads, C2 clerk writes within a bounded process such as its user’s calendar, C3 operator changes shared systems and sends messages on its own, and C4 administrator has broad write access to production systems, identities or payments.

Actions are only one way to cause harm, so capability is assessed through three lenses, and the level is the highest of the three:

• Action: what can it commit on its own? Blast radius, from read-only to administrative changes across systems.
• Data: what can it reach or surface? Exposure, from public information to special-category or regulated data at scale.
• Influence: what decisions does its output steer, whoever acts on it? Decision quality, from purely informational output to decisions about credit, employment, public services or security.

That is why a system that never acts can still be C4. An assistant over the full HR archive changes nothing, but what it can surface puts it at the top of the data lens. A credit-scoring model that only recommends is C4 on influence: a person signs, but the model steered the decision. Record all three scores, because each points to different controls: runtime limits for action, labels and data loss prevention for data, decision audit trails and bias testing for influence.

Ask only one and you govern the wrong thing. A self-initiated agent with modest reach and a gated agent with administrator rights both land at high: the first because nobody starts or checks it, the second because one approved mistake can reach the whole estate. Together the two axes place an agent in a risk tier (low, medium, high or critical), and the tier sets how much assurance and control it gets.

The tier definitions belong to the organisation. Frameworks and control catalogues give you a starting point, but each organisation has to decide what each level means, how to recognise it and what it requires. Make those decisions early, as part of the initial governance work, and communicate them, so developers know what’s expected before they build.

Tactical: the tier becomes a set of obligations. Assurance depth is proportional to tier. Someone signs before it ships. Four routines carry it:

1. Classify at intake. Record each agent’s autonomy, capability and tier in the registry before the build starts, so the team knows what it will owe before it has built anything.
2. Stack the obligations by tier. Each tier adds controls and process obligations to the one below, some required and some recommended, and who signs off rises with it. Agree them in advance, so assessment is quick once a build starts.
3. Gate the release on evidence. Agree pass criteria before testing starts, and put the gate in the release pipeline, not a document review: paper assurance can’t keep pace with how fast agents are built.
4. Reclassify on change, not on the calendar. A new tool, data source, model or scope can move an agent up a tier, so each change triggers reclassification and a re-test before production.

Operational: assurance at agent speed. Agents act faster than people can watch, so assurance has to come from detection, evaluation and posture, run as a five-stage loop:

• Classify: stamp each agent with its tier, which sets the depth of every other stage.
• Test: before release, evaluate task completion, tool use and safety, and probe for prompt injection. The tactical thresholds decide whether it ships.
• Monitor: in production, detect attacks and abnormal behaviour, such as injection attempts, leaked credentials or unusual data access, and raise them as incidents.
• Posture: confirm the controls you think are in place actually are, and map what the agent can really reach. Posture finds gaps but doesn’t close them, so fix what an attacker could reach first.
• Re-test: on every change, re-run the same tests and score sampled live traffic with the same evaluators, so results compare. A change that could raise the tier goes back to classification.

In Microsoft today (status as of October 2026)

• Classify: No product does this. The tier is your decision, recorded in the registry.
• Test: Foundry evaluations score task adherence, tool-call accuracy, groundedness and safety before release; evaluations are GA, but several agent evaluators, including task adherence, are still in preview. The AI Red Teaming Agent probes adversarially and reports an attack success rate (GA in the Foundry portal; local and scheduled runs in preview). Copilot Studio evaluation runs test sets with pass rates you can gate a release on (GA since March 2026; preview in the new agent experience).
• Monitor: Defender raises near-real-time detections of jailbreak, indirect prompt injection and credential leakage (preview). Purview Insider Risk Management gives each agent a risk level from its own behaviour (preview). Entra ID Protection flags risky agents, with offline rather than real-time detections (preview). That is three surfaces with three owners.
• Posture: Defender’s AI security posture finds misconfigurations and attack paths, and Foundry Control Plane shows guardrail coverage across deployments (preview).
• Re-test: Foundry continuous evaluation scores sampled live traffic, red-team scans can run on a schedule, and the Copilot Studio evaluation API re-runs the same test set on every change. All three are in preview.
• Know before you rely on it: Red-team runs use synthetic data and mock tools, so they don’t replace testing under real conditions. Since 1 July 2026, Defender’s agent detections and agent posture require Agent 365 licensing.

Protection: what stops it?

Protection prevents or limits exposure, risk and harm through enforceable guardrails, both technical and procedural. It is where the requirements of the other two pillars get enforced, and the standard is demanding: an agent cannot exceed its intended boundaries even when it is prompted, compromised or misconfigured. A system prompt or an agent description that says “don’t do that” is not a control.

Strategic: boundaries and a stop. An agent gets its own bounded space, not a person’s. The boundary defines four things, in the order a request crosses them:

1. Its own identity, never a person’s. An agent doesn’t inherit access or privilege directly from a human.
2. Its intended reach: the tools it may call.
3. The data it may retrieve: only what it needs to read and act on.
4. The tenant: where standing privilege would otherwise take it.

Outside every ring sits a stop: a kill switch with a named owner, tested, for when a threat or risk requires it.

Tactical: choose controls, don’t pile them on. Controls are selected in a chain:

1. A security baseline that every agent gets: its own identity, audit logging and access review. It is set centrally and not negotiated project by project.
2. The agent profile: its autonomy, capability and context.
3. Its risks and obligations: threats, risks and compliance requirements, assessed per agent.
4. Tailoring: add the controls that agent actually needs.

Three administrative controls deserve particular attention:

• Access reviews on a cadence. Non-human identities accumulate privilege faster than human ones.
• Tool allowlisting and approval. Tools, skills, connectors and dependencies are tracked as a supply chain. Adding a tool doesn’t look like a security change, which is exactly why it needs an approval path.
• Human approval by tier. Human-in-the-loop sounds like the safest option, but applied everywhere it fails, because people asked to approve every action start approving without looking. Approval fatigue is itself a control failure. Keep human approval for high-impact actions, sized to the consequence.

Operational: enforced by the platform, not the agent. The operational picture is a set of rings around the agent: identity, action, data and reach. The stop sits outside them all, and the shape of the rings is set at build time. Each ring is a check the platform performs whatever the agent has been told.

In Microsoft today (status as of October 2026)

• Identity: Entra Agent ID gives each agent its own identity, with credentials held by the blueprint rather than the agent (GA). Conditional Access for agents decides whether an agent may sign in at all (preview). For an agent acting as itself, the only available control is block.
• Action: Defender real-time protection evaluates tool invocations against policy before they run. It is the only product in the stack doing action-level authorisation. It is GA for Agent 365 tool invocations and in preview for Copilot Studio and Foundry agents.
• Data: Purview sensitivity labels, DLP and Adaptive Protection apply the same policies you use for people, extended to agents. A label that encrypts must explicitly grant the agent access, or the agent can’t read the content.
• Reach: Entra Global Secure Access routes Copilot Studio agent traffic through the same web, threat and file filters as your users. Foundry egress controls hold a hosted agent’s outbound calls to an allow-list that fails closed (preview).
• Stop: You can block the agent in the Microsoft 365 admin centre, disable its identity in Entra, or block it with Conditional Access. That is three switches with three owners. The admin-centre block restricts who can use the agent, and for Foundry and SharePoint agents it only removes them from Copilot Chat; disabling the identity is what stops the agent from getting new tokens.
• Build time: Copilot Studio connector and data policies, and Foundry guardrails (in preview for agents), decide the shape of the rings before the agent ever runs.

Three takeaways

1. Intent first, then layers. Let business intent lead, not the technology, and govern across every layer so the impact compounds rather than stalling at policy.
2. Control what matters, not everything. Agents differ in reach and risk, so controls must differ too, and at agent speed they must be technical and continuous, not periodic.
3. Start with profiles and tiering. Agent profiles and risk tiers give developers guidance, create alignment, and carry business intent into security and governance.

---

This post builds on Secured and Governed AI, the talk Mobeen Arif and I gave at Fælles AI implementering on 8 September 2026.