Accountability stays with the team that defines the trust policy and the resource owner that grants access, not with the identity provider alone. Federated identity changes how access is proven, but it does not remove governance obligations around scope, revocation, and monitoring. Organisations still need clear ownership for every MCP trust relationship.
Why This Matters for Security Teams
When MCP access is federated, the identity provider proves who authenticated, but it does not own the trust decision that allows a model, agent, or service account to call a resource. Accountability sits with the team that defines the policy, the resource owner that exposes the tool or data, and the operators who monitor revocation and misuse. That split matters because federated access often hides weak scopes, stale grants, and unclear revocation paths.
The operational risk is not theoretical. NHI governance failures are already widespread, with the Ultimate Guide to NHIs reporting that 97% of NHIs carry excessive privileges, which broadens the attack surface when trust is federated but not tightly governed. OWASP’s OWASP Non-Human Identity Top 10 and the OWASP Agentic AI Top 10 both reinforce the same point: identity proof is only one control layer, not the accountability model.
In practice, many security teams encounter broken MCP governance only after an unexpected tool invocation or sensitive data access has already occurred, rather than through intentional access design.
How It Works in Practice
A federated MCP setup usually involves three distinct responsibilities. First, the identity provider authenticates the subject, such as a workload, agent, or human operator. Second, the policy owner defines which MCP servers, tools, datasets, or actions are allowed. Third, the resource owner enforces and reviews the grant. The team accountable for access is therefore the one that can answer, at any time, why the request should be allowed and how it will be revoked.
For autonomous or goal-driven agents, static RBAC is often too blunt. An agent may need to chain tools, call APIs in sequence, or request different scopes depending on task context. That is why current guidance suggests intent-based authorisation, JIT credential issuance, and short-lived workload identity rather than long-lived standing privileges. The practical pattern is to bind access to the task, not to the identity alone. NHI research such as the 52 NHI Breaches Analysis shows how weak lifecycle control and poor visibility turn access into a durable risk.
- Use workload identity to prove what the agent or service is, not just where it came from.
- Issue ephemeral secrets or tokens per task, with automatic expiry and revocation on completion.
- Evaluate policy at request time using context such as tool, tenant, data class, and operator approval.
- Log each federated trust decision so the resource owner can audit who approved what and when.
For implementation, OWASP Agentic AI Top 10 is useful for framing agent misuse, while the accountability model in the Ultimate Guide to NHIs helps teams separate authentication from ownership. These controls tend to break down when MCP servers are shared across many tenants and policy enforcement is split between platform, app, and data teams because no single owner can revoke access quickly.
Common Variations and Edge Cases
Tighter federation often increases operational overhead, requiring organisations to balance cleaner trust boundaries against slower approvals, more review points, and more frequent token rotation. There is no universal standard for this yet, especially where AI agents act on behalf of humans in mixed-trust workflows.
One common edge case is delegated access. If an agent acts for a user, the user may authorise intent, but the resource owner still owns the MCP trust policy and the emergency revocation process. Another edge case is service-to-service federation, where platform teams may run the identity plumbing but application teams remain accountable for scope and monitoring. In both cases, accountability should be documented as an operational control, not assumed from the authentication chain.
Best practice is evolving toward zero standing privilege, short-lived credentials, and explicit policy records for each trust relationship. NIST’s OWASP Top 10 for Agentic Applications 2026 and the Ultimate Guide to NHIs both support the same operational lesson: federation changes how access is proven, but the resource owner still carries the burden of safe delegation, revocation, and monitoring.
In practice, federated MCP access fails fastest in shared platform environments where teams treat the identity provider as the owner of policy, even though only the resource owner can safely define and revoke the actual trust relationship.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic systems can exceed intended scope without explicit trust controls. |
| CSA MAESTRO | GOV-2 | Governance must assign clear ownership across federated agent trust chains. |
| NIST AI RMF | GOVERN | AI RMF governance requires accountable ownership for automated decisions. |
Document policy owner, resource owner, and revocation authority for each MCP trust.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
