TL;DR: MCP profiles give enterprises a way to require specific authentication and session behaviours, such as client credentials and tenant-scoped server metadata, without changing the base protocol, according to SGNL. The result is a practical path toward safer enterprise adoption of MCP, but only if teams treat profile negotiation as a governance control, not a compatibility detail.
At a glance
What this is: This analysis examines how MCP profiles can let enterprises enforce policy choices, tenant-specific behaviour, and safer authentication without changing the core protocol.
Why it matters: For IAM and NHI teams, the issue is whether MCP sessions can be constrained tightly enough to support enterprise trust, least privilege, and auditable access.
👉 Read SGNL's analysis of MCP profiles and enterprise policy enforcement
Context
Model Context Protocol, or MCP, is becoming relevant to NHI governance because it connects AI agents to tools and enterprise data sources. The gap is not connectivity itself, but whether an organisation can force secure authentication, tenant-specific policy, and usable guardrails before an autonomous agent is allowed to act.
The article argues that profile negotiation can close part of that gap by making security behaviour explicit at session setup. That matters for IAM because an AI agent with tool access is still a non-human identity, and the enterprise needs a way to determine which authentication methods, scopes, and server responses are acceptable. For background on how NHIs create governance pressure, see the Ultimate Guide to NHIs.
Key questions
Q: How should security teams govern AI agents that use MCP to reach enterprise tools?
A: Treat each AI agent as a non-human identity with explicit authentication, scope, and revocation requirements. Require the session to negotiate an approved profile, then map that session to an owner, a purpose, and a time limit. If those three controls are missing, the agent is operating with ambiguous trust and should not reach sensitive systems.
Q: What is the difference between MCP support and secure MCP governance?
A: MCP support means a client and server can exchange messages successfully. Secure MCP governance means the enterprise has defined which authentication methods, tenant rules, and session constraints are acceptable before the connection is allowed. A working session is not the same thing as a governed session.
Q: When do MCP profiles reduce risk, and when do they create false confidence?
A: Profiles reduce risk when they enforce concrete controls such as client authentication, tenant scoping, and fail-closed negotiation. They create false confidence when teams treat profile support as equivalent to full lifecycle governance. If credentials are not rotated, owned, and revoked, the protocol layer only narrows one part of the exposure.
Q: Why do AI agent integrations complicate existing IAM controls?
A: AI agents combine autonomous execution with tool access, so IAM must govern both identity and behaviour. Traditional access controls assume a human operator or a stable workload pattern, but agent sessions can be dynamic and task-specific. That makes policy negotiation, short-lived authority, and continuous review essential.
Technical breakdown
How MCP profile negotiation works
A profile in MCP is a named set of required behaviours and properties that both client and server can advertise and agree to during session setup. The server exposes supported profiles at a well-known location, the client requests a profile or set of profiles, and the session only proceeds if both sides accept the same terms. That makes policy part of protocol negotiation rather than an afterthought. In enterprise use, that is the difference between hoping an agent behaves securely and forcing the connection to satisfy a defined control baseline.
Practical implication: Teams should treat profile negotiation as an access-control decision point, not just a protocol convenience.
Why OAuth options matter for enterprise MCP security
MCP references OAuth, but a broad protocol cannot safely assume one enterprise will accept the same OAuth options as another. Some deployments need client credentials, mutual TLS, tenant-specific authorization servers, or constrained grant types to reduce impersonation risk. Without that specificity, the protocol may remain technically functional while still leaving policy ambiguity at the point where agents authenticate. In NHI terms, ambiguity at authentication time becomes ambiguity in who or what is allowed to operate tools and data sources.
Practical implication: Security teams should define the exact OAuth and token constraints they will permit before agent deployments go live.
Tenant-specific profiles and backward compatibility
The strongest operational value in profiles is selective enforcement. A SaaS provider can support one tenant profile with strict authentication while allowing other tenants to connect with different expectations, which reduces the pressure to redesign the entire service. Because profile use is optional, older clients can still connect where permitted, but enterprise-grade sessions can be required to negotiate a safer path. That balance is useful, but it also means policy must be checked at runtime, not assumed from the protocol name alone.
Practical implication: Practitioners should verify that server metadata, client policy, and runtime session state all align before granting agent access.
Threat narrative
Attacker objective: The attacker or misconfigured agent gains legitimate-looking access to enterprise data sources and tools through a session that bypasses the intended control baseline.
- Entry occurs when an AI agent or client connects to an MCP server that accepts broad OAuth settings without enterprise-specific policy constraints.
- Escalation happens when the client authenticates successfully but without the tighter scope, token-binding, or tenant controls that the enterprise intended.
- Impact is unauthorized tool use or data exposure through a session that was technically valid but governance-weak.
Breaches seen in the wild
- Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Policy negotiation is becoming a control plane problem, not just a protocol feature. MCP profiles shift security decisions into session setup, which is where enterprise IAM teams need them to be. If the protocol cannot express required authentication behaviour, the enterprise ends up compensating with custom wrappers and brittle enforcement. The practical conclusion is that profile-aware controls are now part of NHI governance architecture, not optional enhancement.
Enterprise adoption of MCP will depend on whether teams can prove who the agent is and what it is allowed to do. Client credentials, mutual TLS, and tenant-specific metadata are not implementation details when the actor is an AI agent with tool access. They are the minimum conditions for treating the agent as a governed NHI. The discipline now is to map MCP sessions to identity assurance, not just application connectivity.
Profile-based control can reduce trust debt, but it does not remove lifecycle risk. Even if an MCP server enforces the right session profile, the credentials, tokens, and certificates behind that session still need rotation, scoping, and revocation. That means MCP governance must be integrated with broader NHI lifecycle controls. Enterprises should see profile support as one layer in a wider identity control stack.
The market is converging on runtime governance for agentic access. The demand is no longer only for discovery or secret storage, but for policy enforcement at the moment an agent binds to a tool or data source. That signals a shift in NHI security from inventory management toward behavioural control. Practitioners should plan for controls that verify identity, scope, and session intent together.
Ephemeral credential trust debt is the right way to describe the remaining gap. Even when sessions are short-lived, enterprises still inherit the burden of deciding whether the temporary identity is sufficiently constrained, auditable, and revocable. The unresolved question is not whether the credential expires, but whether the access it enables was safe in the first place. Teams should measure governance by blast radius, not by token lifetime.
From our research:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means most enterprises still struggle to inventory the identities that would need MCP policy controls.
- For a broader control baseline, read Top 10 NHI Issues to map protocol decisions to lifecycle and access governance.
What this signals
The governance pressure here is not limited to MCP. As AI agents gain tool access, the enterprise needs a way to express policy at the protocol boundary and then carry that policy into lifecycle controls, revocation, and review. Without that chain, short-lived sessions still create long-lived governance debt.
Protocol-to-policy gap: this is the phrase practitioners should watch. It describes the space where a protocol can technically connect an agent to a tool, but the enterprise has not yet proved which authentication paths, session scopes, and tenant rules are acceptable. That gap will increasingly determine whether agentic AI stays in pilot or reaches production.
For practitioners
- Define approved MCP authentication profiles Specify which OAuth flows, token-binding methods, and client authentication requirements are acceptable for AI agent access. Make the allowed profile set a precondition for any production connection, including tenant-specific exceptions.
- Require tenant-scoped server metadata Ensure each MCP server advertises policy and profile support in a tenant-aware way so clients can fail closed when required controls are absent. Treat unsupported profiles as a blocked session, not a degraded warning.
- Bind MCP access to NHI lifecycle controls Connect agent credentials to rotation, revocation, and access review workflows so profile enforcement does not sit outside the identity programme. Revalidate tokens, certificates, and service account ownership on the same cadence as other NHIs.
Key takeaways
- MCP profiles turn session setup into a policy decision, which is exactly where enterprise IAM teams need control for agentic access.
- Authentication choices such as client credentials and mutual TLS matter because AI agents are non-human identities, not ordinary application clients.
- Profiles can reduce risk only when they are tied to rotation, revocation, and access review across the full NHI lifecycle.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | MCP profiles govern agent tool access and authorization choices. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Profiles do not replace rotation and revocation for machine credentials. |
| NIST Zero Trust (SP 800-207) | AC-4 | Runtime policy checks align with continuous verification and least privilege. |
Require explicit agent authentication and scope negotiation before any tool connection is allowed.
Key terms
- MCP Profile: A profile is a named set of behaviours and properties that a Model Context Protocol client and server agree to use during a session. In enterprise settings, profiles let organisations require specific authentication, scope, or service behaviour without changing the base protocol.
- Tenant-Scoped Metadata: Tenant-scoped metadata is protocol information tailored to a specific customer or environment rather than a one-size-fits-all default. For NHI governance, it allows an enterprise to enforce different access and authentication requirements for different business units, tenants, or service relationships.
- Policy Negotiation: Policy negotiation is the process of agreeing on security requirements before a session is established. In agentic environments, it matters because the control decision happens at connection time, where identity, permissions, and acceptable behaviour should be confirmed together.
- Ephemeral Credential Trust Debt: Ephemeral credential trust debt is the residual governance risk that remains even when credentials are short-lived. The problem is not duration alone, but whether the temporary identity was properly scoped, owned, monitored, and revocable for the task it was allowed to perform.
Deepen your knowledge
MCP policy enforcement and NHI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI agent access in a similar environment, it is worth exploring.
This post draws on content published by SGNL: Unblocking enterprise MCP adoption with profiles. Read the original.
Published by the NHIMG editorial team on 2025-08-13.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org