How To Run An AI Governance Assessment That Includes Agents And MCP

Key takeaways

• Map your assessment to NIST's Govern, Map, Measure, and Manage functions instead of building a framework from nothing.
• Count every entry point AI can use, not just the sanctioned chat tool, before you score anything.
• Build a living registry of agents and MCP servers with a named owner, runtime location, tool reach, data reach, autonomy tier, and last review date.
• Confirm log-level attribution to a specific person or agent for every action, not a shared service account.
• End the assessment with named owners and a recurring review cadence, because an unowned finding remains unresolved.

Most AI governance programs started with a sensible question: which large language models can employees use, and under what approval process? That question no longer covers the full set of tools running across the enterprise, because browser-based chat tools now share space with agentic AI browsers, desktop copilots, and a growing set of MCP (Model Context Protocol) connections that let an agent call tools and move data without a person in the loop.

Running an assessment that covers all of it means extending a framework you likely already reference: NIST's AI Risk Management Framework. Apply it across every place AI and agents enter the business, then prove the inventory, identity, and runtime controls hold up under that wider scope.

The sections ahead walk through that extension: where to look, how to structure the review, and what a credible agent and MCP inventory contains.

Map every entry point before you score anything

An AI governance assessment that only asks which models are approved is scoring a fraction of the environment. Island's AI Playbook for Security Teams maps roughly nine distinct entry points where AI and agents reach the business, from browser-based AI chat tools and agentic AI browsers to desktop apps, extensions, and MCP or API connections.

Most existing reviews cover one of those nine, usually the sanctioned chat tool, and leave the rest to surface as a surprise during an audit or an incident. Island's research on layering AI governance onto existing endpoint protection walks through that pattern in more depth. Treating AI as a single sanctioned model also means treating it as a single threat surface, and that framing breaks down once agents and MCP servers are part of the picture, a shift Island covers in AI as the new threat surface.

Before you draft a single question for the assessment, list your organization's own version of that entry-point map. Walk through browser chat, agentic browsers, desktop copilots, extensions, and MCP or API connections, and mark which ones your current review touches today. That list becomes the scope statement for everything that follows, and it's usually shorter, and more incomplete, than most teams expect going in.

Borrow a framework instead of inventing one: NIST AI RMF as the backbone

You don't need a new taxonomy to start this assessment; a framework your organization likely already references does most of the organizing work. The National Institute of Standards and Technology's AI Risk Management Framework organizes AI governance into four functions: Govern, Map, Measure, and Manage. Govern covers policy and accountability, Map covers an inventory of AI operating locations and potential failure points, Measure covers testing and monitoring controls, and Manage covers responding to what the first three functions find.

The extension for this assessment is simple to state and easy to skip: apply all four functions to agents and MCP connections, not only to the models an AI council already approved. Govern should name the owner of agent and MCP risk. Map should include the entry-point inventory from the prior section, and Measure should test MCP-call visibility against standard web-request visibility. Island's own AI governance framework research follows the same logic: start from a structure regulators already trust, then widen what counts as AI.

Inventory agents and MCP servers like supply-chain components, not settings

A governance assessment that treats agents and MCP servers as a setting to check once misses how fast they change. A development team can stand up a new MCP connection in an afternoon, and an employee can install an agentic extension without ever filing a request. Island's agent inventory model treats each one as a tracked component rather than a configuration flag, with six fields: owner, runtime location, tool reach, data reach, autonomy tier, and last review date. That list works because it matches how security teams already track software supply-chain risk, where an unowned package is itself a finding.

The scale of the blind spot is measurable. Island's governance research scanned nearly 34,000 public MCP servers. About one in three carries a high or critical severity finding, and roughly 92 percent of their owners have no verifiable organizational affiliation. Those numbers describe the open internet, but the same pattern shows up inside companies: an MCP server a developer connected for a one-off task, then left running with no owner and no review date. Build your registry now, then reconcile it against what endpoint discovery surfaces, because the difference between the two lists is usually where the real risk sits.

Check whether agents have their own identity or are borrowing yours

Most identity programs were built around people logging into systems, not agents acting on a person's behalf. That mismatch becomes an assessment question fast: when an agent reads a file, calls an API, or pulls data through MCP, can you say which person or which specific agent did it? Many organizations find a shared service account behind the honest answer. That account gives every agent action one person's full access and erases the distinct audit trail.

This is also where recent government guidance narrows the acceptable range of answers. Five Eyes cybersecurity agencies, including CISA, have published guidance on the "careful adoption of agentic AI services", advising organizations against granting agents broad or unrestricted access, especially to sensitive data or critical systems. Island addresses this at the connection layer: the Island MCP Gateway issues just-in-time, task-scoped credentials and holds the underlying API key so it never reaches the agent directly. That keeps a compromised agent from inheriting standing access it never needed.

To test this in your own assessment, pull a sample of logged agent actions and try to name the accountable person or agent behind each one. Any action you can't attribute cleanly is a finding, and it belongs on the same list as a login with no owner.

Score runtime and data controls at the point agents act, including MCP-specific risk

Approving a model isn't the same as controlling what happens after an agent starts using it. The assessment should check visibility into the prompt a user sends, the connection request an agent makes, and the data moving across an MCP call, not just the model name on an approved list. Island's broader AI capabilities show what that wider view looks like in practice: coverage that extends from the browser interface down to the tool calls an agent makes behind the scenes.

AI Protect extends that coverage to more than 18,000 AI extensions with real-time risk scoring, and the same approach gives security teams visibility into MCP tool calls as they happen, instead of relying on a quarterly survey of what employees say they're using. Runtime visibility instead of a point-in-time survey is the difference between an assessment that catches a risky MCP server this month and one that finds out about it after a data loss incident.

Ask for a scan of the MCP servers already running in your environment as part of this section of the assessment, not as a follow-up project. If the scan turns up servers nobody claims, that's the finding to act on first, since an unclaimed server with tool access and no review date is exactly the pattern the inventory from the earlier section is built to catch.

Turn findings into ownership and a review cadence, not a one-time report

An assessment that ends in a slide deck changes nothing by itself. The last piece of the work is assigning an owner to each finding and setting the next review date. Assign named owners across security, legal, and the business units that requested the agents and MCP connections in the first place, so accountability doesn't default to the security team by omission.

Set a review cadence that runs at least quarterly, with a trigger clause for anything sooner: a new agent framework, a newly discovered MCP server, or a vendor update that changes what an existing agent can reach. Gartner's research on agentic AI project failure predicts more than 40 percent of agentic AI projects will be canceled by the end of 2027. The common cause is a lack of planning for governance, security, or clear value from the start. An assessment with named owners and a standing cadence is one way to keep a promising agent program off that list, because the failures it predicts tend to be the ones nobody was assigned to catch. Give the assessment an owner and a date for its own next review, the same way you would for any other control, so the document doesn't go stale the week after it ships.

FAQs

What's different about assessing agents and MCP versus assessing chatbots and models?

A chatbot assessment usually stops at which model is approved and who can access it. Agents and MCP connections add two questions a model-only review never asks: can an agent act without a person approving each step, and can a connection move data or call tools on its own? Extend the NIST AI RMF's four functions to cover both, and the assessment stops treating agents as an edge case.

What is MCP, and why does it need its own line item in the assessment?

MCP, or Model Context Protocol, is the connection method an agent uses to reach tools and data sources outside the chat window. It belongs on the assessment separately from model approval because a connection can be stood up in an afternoon, outside any review process, and because Island's governance research found that of nearly 34,000 public MCP servers scanned, about one in three carries a high or critical severity finding and roughly 92 percent of owners lack verifiable organizational affiliation. Assume the same pattern exists inside your own environment until the inventory proves otherwise.

Where do we even start if we've never inventoried agents or MCP servers before?

Start with the entry-point map, not the inventory spreadsheet. Walk through browser chat, agentic browsers, desktop copilots, extensions, and MCP or API connections, using Island's entry-point model as a checklist (AI Playbook for Security Teams), and mark what your current review touches. Only then build the registry, capturing owner, runtime location, tool reach, data reach, autonomy tier, and last review date for each item the map turns up, following the agent inventory structure.

How do we tell whether an agent's actions are attributable to a specific person?

Pull a sample of logged agent actions and try to name the accountable person or agent behind each one. If the trail leads to a shared service account instead of an individual or a named agent identity, that's a finding, not a technicality. Recent Five Eyes guidance on the "careful adoption of agentic AI services" specifically warns against the broad, unscoped access that makes this kind of attribution impossible, so closing that attribution hole also closes a compliance exposure.

Does this assessment require new tooling, or can we run it with what we already have?

You can start the inventory and the identity sampling with spreadsheets and existing logs. Most teams hit a wall at runtime visibility: seeing the prompt, the connection request, and the data crossing an MCP call as it happens, rather than reconstructing it after the fact. AI Protect and the Island MCP Gateway are built to close that runtime-visibility shortfall, so treat the manual version as a starting point, not the end state.

How often should we repeat the assessment once it's done?

Set a cadence of at least quarterly, with a trigger clause for anything sooner: a new agent framework, a newly discovered MCP server, or a vendor update that changes what an existing agent can reach. A single point-in-time assessment goes stale fast given the pace at which agents and connections multiply, so the cadence matters as much as the first pass.

Who should own the findings once the assessment is finished?

Assign named owners across security, legal, and the business units that requested the agents or MCP connections in the first place, rather than letting ownership default to security by omission. Gartner's research on agentic AI project failure predicts more than 40 percent of agentic AI projects will be canceled by the end of 2027, often from a lack of governance planning, a useful reminder that unowned findings tend to sink a program later.