Model context protocol changes the governance model for AI agents

At a glance

What this is: This is an analysis of how MCP and A2A shift AI from retrieval to action, and why governed data and approved use cases become the limiting factors.

Why it matters: It matters because IAM, NHI, and AI governance teams now have to control who or what can act through models, not just who can query them.

👉 Read Collibra's analysis of Model Context Protocol and AI governance

Context

Model Context Protocol changes the practical boundary between information access and action. In plain terms, it gives foundation models a standard way to reach into data sources and tools, which means AI systems can now move from reading to doing inside enterprise workflows. That shift puts identity governance, data quality, and approval boundaries into the same control plane.

The governance gap is that many AI programmes still treat model interaction as a query problem when the real issue is delegated execution. Once an agent can comment on tickets, send email, or update documentation, the question becomes whether the action was authorised, traceable, and aligned to the business context. For organisations building AI programmes, this is typical of the next stage of adoption, not an edge case.

Collibra frames this as a need for stronger bookends around AI initiatives: governed data on one side and business-relevant use cases on the other. That framing is useful for IAM leads because it connects AI output quality to identity and access decisions without pretending the model itself is the control boundary.

Key questions

Q: How should security teams govern AI agents that can use enterprise tools?

A: Security teams should govern AI agents as delegated actors, not as simple chat interfaces. That means defining approved tools, action scopes, and escalation paths before connection, then logging every write-capable action and every handoff. If the model can modify records, send messages, or trigger workflows, those actions need the same governance scrutiny as any other privileged operation.

Q: Why do data quality and access governance matter so much for AI systems?

A: Because AI output is only as trustworthy as the data it can reach and the context it is allowed to use. Poorly governed data produces unreliable answers, but over-permitted data can also produce harmful actions. When AI systems are connected to enterprise tools, access governance becomes part of data quality governance, not a separate concern.

Q: What breaks when AI workflow approval is left informal?

A: Informal approval breaks accountability. If a team cannot show who approved the use case, what actions were permitted, and which data sources were in scope, the organisation cannot prove that the AI acted within policy. In practice, this makes incident review, compliance evidence, and responsibility assignment far harder after the fact.

Q: What is the difference between retrieval-based AI and action-capable AI?

A: Retrieval-based AI returns information, while action-capable AI can trigger changes in external systems. That difference matters because retrieval can usually be governed with data controls, but action requires identity controls, policy checks, and audit logging. Once a model can act, the security question shifts from answer quality to delegated authority.

Technical breakdown

Model Context Protocol turns retrieval into delegated action

MCP is an integration protocol that lets a model query tools and data sources through a shared interface. That matters because the system is no longer only producing text from static training patterns. It can now issue requests that trigger external behaviour, such as looking up records, drafting updates, or initiating downstream workflow steps. In governance terms, this creates an action surface, not just an information surface. The technical risk is not the protocol itself, but the new class of execution paths it opens across business systems.

Practical implication: treat MCP-connected tools as governed execution endpoints, not harmless read-only model extensions.

Agent2Agent coordination creates compound identity and approval risk

Agent2Agent, or A2A, allows multiple agents to coordinate, plan, and execute across tasks. That coordination increases utility, but it also multiplies the number of decisions, handoffs, and implicit trust relationships in the chain. A single agent can inherit context from another agent and act on it without a human re-validation point between steps. From an identity perspective, the risk is that accountability becomes fragmented across agents that can each appear legitimate in isolation.

Practical implication: define who authorises inter-agent delegation and log every agent-to-agent handoff as a governance event.

Governed data and approved use cases are the real control boundary

The article’s central point is that model capability cannot compensate for weak data governance or an unclear business case. If the underlying data is poor, untrusted, or over-exposed, the model only accelerates bad decisions. If the use case has no approved context, the model can still act, but it may act outside organisational intent. This is where AI governance converges with IAM and NHI practice: access, context, and authority must be bounded before the model is allowed to operate.

Practical implication: require data classification, task approval, and action scoping before connecting AI systems to enterprise tools.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Model Context Protocol creates an action surface, not just a data-access surface. The article correctly shifts attention from model quality to what the model can do once it reaches enterprise systems. That is a governance change, not a tooling upgrade. When a model can send an email, update documentation, or interact with a ticketing system, identity controls must govern the action path as well as the query path. Practitioners should treat MCP integrations as delegated execution points, not passive retrieval connectors.

Governed data quality is the first bookend of AI security. The article’s emphasis on data quality is not a generic analytics point. It is an access-control issue because AI output inherits the trustworthiness, scope, and permissiveness of the sources it can reach. Poorly governed data creates both bad answers and bad actions. The practical implication is that AI governance begins with data entitlements, source trust, and contextual boundaries, not with model tuning.

Cross-functional AI use cases fail when approval and business context are separated. The article is right to stress that value comes from a team that understands the business impact of the use case. In identity terms, that means the action must be authorised in the same context in which it will be executed. When AI systems are allowed to act without business-context approval, compliance and operational risk converge. Practitioners should align AI use-case approval with identity governance, not treat it as an adjacent review process.

Agent-to-agent delegation introduces governance debt that most IAM programmes are not yet measuring. A2A coordination is useful because it scales task execution, but it also creates hidden trust chains. Each delegation hop can obscure who initiated the action, which context was inherited, and which policy boundary was crossed. The implication is that identity programmes need visibility into delegation, not just authentication and access at the outer edge. Teams that cannot observe these hops cannot certify the resulting behaviour with confidence.

AI governance is becoming an identity discipline across human, NHI, and autonomous execution. The boundaries that matter are no longer only user logins or service accounts. Once an AI system can act through tools and coordinate with other agents, governance has to span machine identity, delegated authority, and human approval. That does not make every AI workflow autonomous, but it does make the identity layer central to control design. Practitioners should reframe AI security as governed execution across the full identity stack.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That governance gap connects directly to the identity control problem described in OWASP NHI Top 10, where delegated action and tool misuse become the primary concern.

What this signals

Action-capable AI is forcing IAM teams to expand their control boundary. It is no longer enough to know which user or workload authenticated to a system. Teams now need visibility into what the model or agent was allowed to do once connected, especially when the workflow includes write actions or delegated tool use. The practical change is that approval, logging, and entitlement design must move closer to the execution layer.

Delegation chains will become the hidden weak point in many AI programmes. As agents coordinate across tools and other agents, the organisation may lose sight of where authority began and where it was inherited. That is a governance issue as much as a technical one, and it calls for explicit lineage tracking, not just standard access reviews. For practitioners, the next control question is who can act through the model, not just who can log in to it.

With 80% of organisations already seeing AI agents act beyond intended scope, the governance gap is no longer theoretical. The teams most exposed are the ones that have treated AI as a productivity layer instead of a delegated execution layer. Internal control design should now assume that action, not just analysis, is part of the AI footprint.

For practitioners

• Classify every MCP-connected tool as a governed action endpoint Map each tool the model can reach to its data sensitivity, action type, and approval requirement. Separate read-only retrieval from write-capable actions, and require explicit policy review before connecting the model to systems that can change records, send communications, or trigger workflows.
• Require business-context approval before enabling agent workflows Tie each AI use case to an approved business objective, accountable owner, and permitted action scope. If the use case cannot be described in operational terms, do not expose enterprise tools to the agent until the workflow and its escalation path are defined.
• Track agent-to-agent delegation as a governance event Log every handoff between agents, including the source context, destination agent, and resulting action. Treat delegation as part of the identity trail so investigators can reconstruct who or what initiated the task and why the downstream action occurred.
• Bound AI access with data classification and source trust Limit model access to datasets that have been classified, quality-reviewed, and approved for the intended use case. Reassess whether the source can support the action being requested, not just whether the model can technically read it.
• Use the OWASP Agentic AI Top 10 to pressure-test tool chains Review the attack surface created by prompt-to-tool workflows against the OWASP Agentic AI Top 10 and align controls to the specific failure mode, especially tool misuse, delegation, and over-permissioned access.

Key takeaways

• MCP and A2A shift AI from a conversational interface into a delegated execution model that identity teams must govern.
• Governed data, approved business context, and action scoping are now the practical boundaries that determine whether AI acts safely.
• As agents gain tool access and delegate to one another, IAM, NHI, and AI governance converge into a single control problem.

Key terms

• Model Context Protocol: A protocol that lets a model connect to external tools and data sources through a shared interface. In practice, it extends AI from answering questions to taking actions, which means the connection itself becomes part of the governance and identity boundary.
• 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.
• Delegated Execution: A control model where one identity is allowed to act on behalf of another within a defined scope. For AI systems, this means the model or agent is not just producing output, but performing actions that must be authorised, logged, and bounded like any other privileged actor.
• Governed Action Endpoint: Any connected system that an AI model or agent can use to create, change, or trigger something in the enterprise. The term matters because write-capable tools are not passive integrations. They are execution points that require policy, auditability, and scope control.

Deepen your knowledge

Model Context Protocol, delegated execution, and AI action scoping are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for tool-using AI systems, it is a strong place to start.

This post draws on content published by Collibra: analysis of Model Context Protocol, Agent2Agent, and AI governance. Read the original.