RiskRubric v2 extends MCP governance into agentic AI risk

At a glance

What this is: RiskRubric v2 broadens AI security assessment from models to MCP servers and AI agents, with a key focus on tool abuse, transitive trust, and excessive agency.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern agent-linked access paths, tool permissions, and delegated trust across both human-run and autonomous workflows.

👉 Read AppSOC's analysis of RiskRubric v2 and MCP security standards

Context

Model Context Protocol has become the connective tissue between AI systems and enterprise tools, which means identity governance now extends beyond the model itself to the servers that broker tool use, data access, and workflow execution. In that environment, security teams need to assess not only what an AI system says, but what it can touch, trigger, or inherit through delegated access.

RiskRubric v2 matters because it treats MCP servers and AI agents as distinct risk-bearing components rather than treating them as implementation detail. That is the right problem framing for IAM, NHI, and PAM teams, because tool connectivity introduces transitive trust, overbroad privilege, and exposure paths that traditional model reviews do not capture.

The article’s starting point is typical of the market, not exceptional: organisations are moving faster into agentic architectures than their governance models are adapting, so the control gap is structural rather than isolated.

Key questions

Q: How should teams govern AI agents that use MCP?

A: Treat each connected agent as a non-human identity with an owner, a scope, and a review cycle. The practical control set is familiar: least privilege, secret rotation, access expiration, and auditability across the systems the agent can reach.

Q: Why do conversational AI systems create new identity and access risks?

A: Because they can combine data retrieval, decision-making, and execution in a single interaction. That collapses the gap between information access and business action, which traditional IAM and security tools were not built to manage. The result is higher exposure when the system can modify records or disclose sensitive guest data.

Q: What breaks when AI agents are given broad standing access?

A: Broad standing access breaks governance because the agent can move from one task to another without a fresh authorization check. That creates a control gap between intended scope and actual runtime behaviour. The result is weak accountability, limited containment, and audit trails that show activity without explaining why the activity was allowed.

Q: How do organisations evaluate whether an AI agent tool chain is safe enough?

A: They should test tool description fidelity, provenance, command handling, response exposure, and whether each connector introduces additional authority beyond the agent’s intended role. A safe tool chain is one where the trust path is explicit, limited, and auditable end to end.

Technical breakdown

Why MCP servers create a transitive trust problem

MCP servers sit between an AI system and enterprise resources, which means they inherit trust from the agent while also extending trust into applications, data sources, and workflows. That creates a transitive trust chain: if the MCP server is poorly governed, the agent gains a broader effective privilege set than its own policy would suggest. RiskRubric v2 responds by evaluating tool description fidelity, provider identity, provenance, and data exposure through tool responses because those are the practical indicators of whether the trust chain is still intelligible.

Practical implication: Practitioners should inventory MCP servers as governed access intermediaries, not as neutral integration plumbing.

How excessive agency changes the identity risk model

The Excessive Agency pillar addresses a different problem from ordinary misconfiguration. When an AI agent can choose actions, invoke tools, and continue execution without a human approval gate, the security question shifts from authentication to authority boundary management. Risks such as goal hijacking, privilege escalation, memory poisoning, and capability abuse emerge because the agent can act on intent at runtime, not just on pre-approved instructions. That is why agent identity must be assessed as an operational subject, not merely as an API consumer.

Practical implication: Security teams need controls that constrain agent authority at runtime, especially where tool use can chain into business actions.

What MCP tool-call abuse looks like in practice

Tool-call abuse occurs when an agent or surrounding workflow manipulates tool arguments, command inputs, or response handling to make an otherwise legitimate connector do something unsafe. The problem is not only injection in the classic sense, but also the way a tool response can carry data back into the agent session and expand the next action set. This is why the framework includes command injection through tool arguments, supply chain integrity, and vulnerability identification as separate evaluation signals. Those signals expose whether the connector can be trusted under adversarial use, not just under happy-path testing.

Practical implication: Teams should test MCP servers for argument handling, response sanitisation, and provenance before allowing production agent access.

NHI Mgmt Group analysis

MCP governance is now an identity problem, not just an application integration problem. Once an AI system can reach enterprise applications through a protocol bridge, the question is who or what is authorised to act, at what scope, and with what delegated trust. That pushes MCP servers into the same governance conversation as service accounts, privileged tokens, and workload identity, because they mediate actionable access rather than passive data exchange. Practitioners should treat MCP adoption as an expansion of the identity perimeter, not as a feature of the model layer.

Excessive agency is the right concept for agentic AI risk because it names the failure mode, not the symptom. Traditional controls assume actions are bounded by stable human intent and reviewable approval points. In agentic systems, the action chain can continue, re-plan, or amplify itself after the initial request, which means policy written for static access requests can miss the actual risk boundary. The implication is that governance models must be evaluated against runtime authority, not just provisioning-time permissioning.

Transitive trust debt is the hidden liability in MCP ecosystems. Each additional connector, server, and tool response expands the trust surface even when the agent itself looks unchanged. That means the weakest point is often the least visible intermediary, not the model or the user interface. Organisations should reframe MCP review as continuous trust accounting across the full delegation chain.

Shared evaluation standards will matter more than isolated point solutions as the ecosystem grows. The move toward multi-scanner assessments reflects a practical reality: no single team can validate every MCP server or agent path at the pace adoption is happening. For IAM and security leaders, the important shift is toward evidence-backed governance, where access, provenance, and operational safety are evaluated using repeatable criteria rather than ad hoc approvals.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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, according to AI Agents: The New Attack Surface report.
• For a broader control lens, review the OWASP Agentic Applications Top 10 alongside your MCP governance model so tool access, privilege, and agent behaviour are assessed together.

What this signals

Transitive trust debt: every new MCP connector increases the amount of authority that must be explained, reviewed, and monitored across the agent path. That means teams should stop treating connector onboarding as integration work and start treating it as access governance work, especially where tools can reach business systems or sensitive data.

With 98% of companies planning to deploy more AI agents even as 80% report rogue behaviour in current deployments, the governance model is already behind the adoption curve. The practical response is to build runtime guardrails now, using evidence from OWASP Agentic Applications Top 10 and internal access reviews, rather than waiting for scale to force the issue.

Teams should expect MCP and agent oversight to merge with PAM, NHI, and AI governance workflows. The next maturity step is not another checklist, but a control plane that can explain who or what can act, by which tool, under which delegated authority.

For practitioners

• Establish MCP server inventories Record every MCP server, its owner, its connected data sources, and the business workflows it can trigger. Treat unknown or community-sourced servers as unmanaged access brokers until they are evaluated and approved.
• Evaluate transitive trust before production use Test whether an agent inherits permissions, data access, or workflow reach through the server rather than through a direct policy grant. Reject deployments where the delegated trust chain cannot be explained in plain terms.
• Add runtime controls for agent tool use Constrain which tools an agent can invoke, what parameters it can pass, and which actions require approval. Use those restrictions to reduce excessive agency before the agent can chain into high-impact systems.
• Require provenance and ownership for every connector Block MCP integrations that do not declare provider identity, maintenance ownership, and vulnerability handling. Provenance gaps are a governance failure, not a documentation issue.

Key takeaways

• RiskRubric v2 shifts agentic AI security toward the access paths that actually carry authority into enterprise systems.
• The biggest governance gap is transitive trust across MCP servers, where a weak connector can expand privilege beyond the agent’s intended role.
• Practitioners should evaluate agent tool use, connector provenance, and runtime authority together instead of treating them as separate reviews.

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.
• Excessive agency: A condition where an AI system is given more operational authority than its task requires. The risk is not just poor output. It is that mistakes, manipulation, or compromise can produce destructive actions at machine speed across the systems the agent can reach.
• Transitive trust: The hidden risk created when one trusted app inherits confidence from another trusted relationship. In SaaS environments, approving a third-party tool means trusting its hosting, storage, developers, and connected services, which widens the attack surface beyond the original login event.
• Tool-call abuse: Tool-call abuse occurs when an agent or related workflow manipulates a tool invocation so the connector performs an unsafe action. The risk is technical and governance-related at once, because the call may look legitimate while still producing unauthorised access, data exposure, or workflow execution.

What's in the full article

AppSOC's full blog covers the operational detail this post intentionally leaves for the source:

• How RiskRubric v2 maps MCP-specific indicators across transparency, reliability, security, privacy, and excessive agency.
• The full list of example assessment dimensions, including tool description fidelity, provider identity, provenance, and data exposure risks.
• Details of the multi-scanner model and how contributors can submit evidence into the RiskRubric knowledge base.
• The planned public access and on-demand testing workflow for evaluating newly discovered MCP servers.

👉 AppSOC's full post covers the MCP risk categories, assessment approach, and planned community testing model.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.