How do you prove your AI governance works? Lessons from Toronto

Your MCP tool returns a successful response, but does that tell you who authorized the action, whether it matched the user's intent, or what happened afterward?

Three examples from MCP Dev Summit Toronto, held October 5-6, examine the controls teams are building, what those controls can demonstrate, and where they still fall short.

Who gets access to which tools?

When one developer connects an agent to an MCP server, managing access can be fairly straightforward. When hundreds of employees and thousands of agents share services, the requirements change.

In his Running MCP for Real keynote, Chris Alexiuk (Senior Product Research Engineer, Deep Learning, NVIDIA) explained how NVIDIA uses an MCP-as-a-service layer to manage shared connections to internal tools and information.

The approach puts authentication and access checks at the service boundary rather than leaving each MCP server to handle them independently. Users retain separate access contexts, including for caching and persistent state, while different applications receive different sets of tools.

A coding assistant, for example, doesn't automatically need access to the same resources as a research agent. NVIDIA's system filters which MCP services are exposed based on the application's purpose, rather than presenting every available tool to every agent.

Chris also described guardrails at multiple points in the workflow, including checks on incoming requests, tool calls, tool results and final responses. The aim is to make authorization decisions where they can be enforced, while maintaining appropriate access boundaries as tools are shared across an organization.

His practical advice included assigning clear ownership to MCP servers, enforcing permissions at the service boundary and making deliberate decisions about which tools each agent can use.

For teams adopting this approach, proving governance means being able to establish which tools were available to a particular user or agent, which permissions applied and where access decisions were enforced. A successful connection alone doesn't establish any of that.

What happens when the agent finds another way?

At Accenture, employees wanted agents to handle tasks such as reading emails and drafting replies. But allowing an agent to send messages directly as the employee raised different concerns, including whether recipients would know an agent was involved.

In the keynote, Governing MCP for a Workforce the Size of a City, Michael Forrester (AI Workforce Transformation Lead, Accenture LearnVantage) addressed the challenge of governing MCP across an organization with hundreds of thousands of employees.

The architecture described in the session included a registry to track MCP servers and their owners, a gateway to centralize identity, authorization and policy enforcement, and admission controls to prevent unapproved servers from entering the environment. Workload identity and runtime detection were also part of the approach.

Some of the most revealing examples came from employees using agents to accomplish everyday tasks where the organization declined to provide that capability through an MCP server. Michael described how an employee's agent generated a PowerShell script that interacted directly with Outlook and sent messages using the employee's existing access.

Another experiment used browser automation to interact with Teams and Outlook.

Michael explained these weren't security violations, rather the agents had used capabilities already available on approved systems, following paths the organization hadn't adequately restricted.

The distinction between user intent and organizational authorization is stark. The agent was following what the employee wanted, but the organization had deliberately declined to provide that capability through its approved MCP interface. Yet blocking an MCP tool hadn't prevented the action from happening through another route.

Michael also emphasized the importance of involving employees in governance. His team found that explaining restrictions, understanding what people wanted to accomplish and treating internal AI services more like a product helped make users part of the process.

The examples raise a broader enforcement problem. MCP gateways can govern MCP calls, but agents can also run scripts, use browsers and interact directly with applications. Teams need to establish where those other actions are controlled, and whether their records capture what happened outside the MCP boundary.

Can you prove what happened afterward?

Authorization is one part of the problem. Establishing what happened after an action was approved is another.

Attendee Przemek Tomczak highlighted a number of talks in his Toronto recap, including Architecting Agents That Scale: Orchestration Patterns with MCP at the Core by Shivam Tyagi, a Principal AI Engineer at RBC.

Discussing the challenges of coordinating agents as their capabilities and complexity grow, Shivam described an architecture in which an agent worker can be replaced without losing the record of what was found, approved and done.

The model proposes an operation, the service checks and executes it, and the backend establishes the outcome.

That separation is useful when agent workers are replaced, tasks are interrupted or systems change during execution. The organization still needs to know which information was available, what was approved and what work took place.

Przemek also highlighted the use of traces and evaluations to detect changes in behavior when tools, prompts or models are updated.

These observations connect to a practical distinction between recording an action and verifying its outcome.

An MCP log might show that an agent requested a tool operation and received a successful response. But that record alone may not establish that the intended business action was completed, whether an approval applied to that particular operation, or what happened when execution was interrupted.

A useful audit trail connects the request, the relevant identity and permissions, the authorization decision, and the resulting operation.

For teams operating agents at scale, that evidence needs to survive beyond any individual model invocation or agent worker. The ability to reconstruct those decisions and outcomes is how governance controls can be tested rather than simply documented.

What should teams be checking?

The examples from Toronto provide four practical questions for engineering teams:

• Identity: Can you identify the user, agent and permissions involved in an action, including when that action passes between services?
• Enforcement: Are restrictions applied where actions happen, including outside MCP through scripts, browsers and other execution paths?
• Intent: Can the system distinguish an action requested by a user from one the organization has authorized the agent to perform?
• Evidence: Can you reconstruct what was requested, approved, executed and verified, including failures and uncertain outcomes?

These checks apply at different points in an agent's workflow and provide a useful starting point for reviewing governance in an existing agent system: inspect the identities and permissions it uses, test the boundaries around its actions, and check whether the evidence is sufficient to explain what happened.

More on governance in San Jose

These issues will also feature at AGNTCon + MCPCon North America, October 22-23 in San Jose.

Several sessions connect directly to the engineering issues raised in Toronto:

• From DCR to CIMD: MCP Client Identity in Production with Alvaro Inckot - client identity, authorization and preserving attribution from human to agent to tool to API.
• Agent Governance Lives in the OS with Alexander Sklar and Roberth Karman - enforcing restrictions on files, network access and processes beyond the MCP layer.
• Who, May, Did: Composing Agent Identity with Verifiable Proof of What Agents Actually Do with Steven Mih - connecting identity and authorization to verifiable records of actions performed.

Toronto also featured a workshop on governing agent actions beyond MCP. The subject returns in San Jose with Governing AI Agent Actions: MCP and Beyond, led by Shannon Williams and Bill Maxwell, covering access controls, approvals and audit records across MCP servers and other agent actions.

Register and use COMMUNITY25 to save 25%.