Model context protocol changes the governance model for AI agents

At a glance

What this is: This analysis says MCP and A2A change AI governance by letting models move from answering questions to taking approved actions across systems.

Why it matters: IAM, IGA, and PAM teams need to treat AI agents as actors whose access, context, and permitted actions must be governed before tool use begins.

Context

Model Context Protocol changes the governance model for AI agents because it gives an AI system a standard way to reach into data sources and tools, not just generate text. That shift matters most when the agent can move from recommendation to execution, because the control problem becomes authorisation, context, and accountability rather than model quality alone.

Collibra frames the issue as a governance problem at the bookends of AI: the data feeding the system and the use case determining what the system is allowed to do. For IAM, IGA, and PAM teams, that means the central question is whether an AI action is approved, scoped, and understood before the agent touches business systems.

A2A adds another layer because agent-to-agent coordination can multiply the number of actions, dependencies, and delegated responsibilities in a workflow. Once agents can coordinate work across systems, identity governance has to account for who can initiate, combine, and complete those actions on behalf of a business process.

Key questions

Q: What breaks when AI agents bypass a centralized MCP gateway?

A: When agents bypass a centralized MCP gateway, security controls fragment across notebooks, scripts, and individual servers. Teams lose consistent authentication, authorization, logging, and rate control, which increases the chance of token sprawl, runaway costs, and undetected misuse. It also makes it harder to enforce policy on sensitive data flows or prove accountability after an incident.

Q: Why do A2A workflows increase identity governance risk for AI programmes?

A: A2A increases risk because delegation can move across multiple machine actors before a human sees the result. That makes it harder to preserve context, enforce scope, and prove which identity was authorised to complete the task from start to finish.

Q: How should security teams govern AI agents in shared workspaces?

A: Security teams should treat the workspace audience as part of the authorization decision. If the agent can be seen by people with different entitlements, the system must check whether every recipient is allowed to receive the data before the response is generated. Otherwise, the agent can disclose information correctly retrieved but incorrectly exposed.

Q: How do you know when an AI agent has outgrown its current access model?

A: An AI agent has outgrown its access model when it can initiate or complete actions that were never explicitly reviewed as part of the business process. Signs include broad tool reach, unclear handoff points, and approvals that describe intent but not the actual action set.

Technical breakdown

How MCP turns retrieval into action

Model Context Protocol standardises how an AI model connects to tools and data sources. In practice, that means the model can do more than summarise a record or answer a question, because the same context channel can also carry instructions to send mail, update tickets, or write documentation. The technical change is from passive retrieval to tool invocation. That matters because the security boundary is no longer the model alone, but the combination of model, tool, and permissioned data source. Once the model can trigger side effects, governance has to determine which actions are allowed, under what context, and with what traceability.

Practical implication: treat every MCP-connected tool as an access surface, not just an integration.

Why A2A raises delegation complexity

Agent2Agent is a coordination layer for multiple agents that need to communicate, plan, and execute together. That introduces delegation chains where one agent can hand work to another, which is materially different from a single assistant answering prompts. The more agents participate, the harder it becomes to know which identity initiated a task, which context was inherited, and where approval should be enforced. For identity teams, this is not just workflow automation. It is delegated action across machine actors, which requires explicit boundaries for scope, trust, and logging across the chain.

Practical implication: define where delegation starts, where it stops, and which agent identity is accountable at each step.

Why governance now sits at the bookends

The article’s strongest point is that AI value still depends on the same two bookends: governed data and a valid business use case. If the data source is low quality or ungoverned, the agent acts on unreliable context. If the use case is vague, the agent may do the wrong work efficiently. This is why AI governance for agents is not just a model safety issue. It is an identity, data, and process control issue that must be resolved before the agent is allowed to act. The practical question is whether the organisation can approve actions in advance and prove that approval later.

Practical implication: gate agent actions through governed data sources and approved business context before enabling production use.

NHI Mgmt Group analysis

Model Context Protocol creates an authorisation problem, not just an integration problem. Once an AI system can reach tools and data sources through a shared protocol, the governance question shifts to who authorised the action, not whether the model could technically perform it. That means identity controls have to define permissible action space before runtime, because the model is now operating with side effects. Practitioners should stop treating tool connectivity as neutral plumbing and start treating it as a governed access path.

Agent-to-agent coordination multiplies the governance surface. A2A turns a single AI actor into a chain of machine-to-machine delegation, which means context can move farther than the original approver intended. That creates a governance gap between initiation and completion, especially when multiple agents can plan, hand off, and execute without a human checkpoint. The implication is that approval models built for one actor do not automatically survive multi-agent workflows.

Governed data is the first control plane for AI action. If the data source is not quality-controlled and access-governed, the agent inherits noise, stale context, and potentially excessive reach. Collibra’s framing is useful because it puts data governance back at the centre of AI control design rather than treating it as an afterthought. The practitioner takeaway is that AI action governance begins with source trust, not model confidence.

Approved action context is the new boundary for identity governance. The old assumption was that the system asks, then the human decides, then the system responds. MCP and A2A blur that sequence because the agent can both infer and act inside a business workflow. That means identity programmes must govern not only who has access, but which actions are pre-approved within a stated business context and which remain out of scope.

Identity governance for AI agents must be lifecycle-aware from the start. If an agent can be created, connected, delegated to, and retired quickly, then standing approval becomes a liability unless offboarding and scope review are explicit. This is where NHI governance and agentic AI governance converge, because the same lifecycle discipline now applies to a machine actor that can take action. Practitioners should manage AI agents as governed identities, not disposable software features.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Authorisation Guide

What this signals

Approved action context: AI governance for agents is shifting from model evaluation to runtime permissioning. When MCP exposes tools and A2A extends delegation across agents, the control question becomes whether each action is pre-approved within a named business context or simply technically possible.

The strongest programme response is to align AI identity governance with existing lifecycle discipline for non-human identities. That means access review, scope removal, and offboarding must apply to agents as governed actors, not as loosely supervised software features.

The broader signal is that data governance and identity governance are converging around the same boundary: what an AI system may do with trusted context. Organisations that keep those disciplines separate will struggle to prove that agent actions stayed inside policy.

For practitioners

• Define approved action boundaries for AI agents Document which tool actions, data sources, and workflow steps an AI agent may perform without additional approval. Separate read-only assistance from side-effecting actions such as sending, changing, or closing records.
• Classify MCP-connected tools as access surfaces Inventory every tool exposed through MCP and assign an owner, purpose, and review cadence. Treat each connection as a governed access path that can expand the agent’s effective reach.
• Build delegation controls for A2A workflows Map which agent can hand off work to another agent, what context carries forward, and where the chain must stop for human approval. Record the accountable identity at each hop.
• Tie AI action approval to governed data sources Only enable agentic workflows when the underlying data source is quality-controlled, owned, and reviewed for the business use case. If the source cannot be trusted, the action should not be trusted either.
• Review agent offboarding and scope removal Remove credentials, tool bindings, and delegation rights when an AI agent is retired, repurposed, or no longer needed. Scope reviews should confirm the agent cannot continue acting on stale approvals.

Key takeaways

• MCP and A2A do not just expand AI capability, they change the governance question from output quality to authorised action.
• Once agents can coordinate and act across tools, approvals, delegation chains, and accountable identities become core controls, not administrative extras.
• Identity teams should govern AI agents as access-bearing actors with scoped permissions, lifecycle controls, and explicit action boundaries.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Agent2Agent Protocol: A coordination layer that lets one agent communicate, plan, and execute with other agents. The security challenge is not only what each agent can do, but how authority, context, and accountability move across the chain during delegation.
• Action Boundary: The action boundary is the point where a user or system turns a request into a business-impacting decision, such as a payment approval or access grant. It is the most important place to add controls when attackers are using legitimate-looking messages to redirect trusted workflows.
• Agent Lifecycle Management: The process of provisioning, governing, updating, and retiring an AI agent or other non-human identity. It includes credential issuance, permission changes, logging, rotation, and offboarding. Without lifecycle control, agents can retain access after their business purpose ends, creating persistent risk.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.