Standards are the fastest path to safer MCP and OAuth adoption

At a glance

What this is: This commentary argues that standards make software safer, easier to integrate, and easier to evolve, with OAuth and MCP used as the clearest examples.

Why it matters: For IAM and NHI practitioners, the point is that standardised identity flows reduce bespoke risk, improve interoperability, and make agent governance more realistic at scale.

👉 Read Curity's analysis of why standards speed OAuth and MCP adoption

Context

Standards are the control point that turns identity and access from a one-off engineering choice into a governable system. In NHI environments, that matters because the same patterns that secure human identity now have to extend to service accounts, tokens, workloads, and agents without creating custom exceptions for every integration.

The article’s central claim is that standards often look harder than they are, but their long-term value comes from shared implementation logic, community maintenance, and ecosystem tooling. For NHI governance, that is the real issue: when AI agents and machine-to-machine flows expand, teams need reusable controls rather than bespoke security logic for every connection.

Key questions

Q: Why do standards matter for non-human identity governance?

A: Standards matter because they create repeatable identity and access patterns that can be reviewed, monitored, and updated across many systems. For NHI governance, that reduces bespoke security logic, improves interoperability, and makes it easier to manage service accounts, tokens, and agents at scale without inventing a new control model for each integration.

Q: How should security teams adopt standards for AI agent access?

A: Security teams should start with existing authentication and authorisation standards, then define token scope, approval, and logging rules before agents are allowed to call tools. That approach avoids custom trust logic and gives IAM and security teams a consistent way to govern agent behaviour across environments.

Q: What is the difference between a standard and a bespoke security control?

A: A standard is shared, documented, and maintained by a broader ecosystem, while a bespoke control is custom-built for one environment. Standards usually improve interoperability and patchability, while bespoke controls can be harder to audit, slower to update, and more fragile when the environment changes.

Q: When should organisations prefer standards over custom implementations?

A: Organisations should prefer standards whenever the control needs to survive integration growth, multiple teams, or external ecosystem change. If the mechanism affects identity, authentication, or delegated access, a standard is usually safer because it makes the control easier to verify, support, and replace over time.

Technical breakdown

Why standards can look harder than they are

Standards often appear complex because they externalise security decisions that custom code usually hides. OAuth 2.0 authorization code flow is a good example: the extra redirect and code exchange exist to limit token exposure, not to add ceremony for its own sake. The same pattern appears in other protocols where a standard separates trust decisions, transport, and credential handling so each step can be reviewed independently. For NHI and agentic AI environments, that separation matters because service accounts and agents often need repeatable, inspectable flows rather than ad hoc authentication shortcuts.

Practical implication: Treat implementation complexity as a question to test, not a reason to default to custom security logic.

How standards reduce vulnerability debt over time

A widely adopted standard creates a maintainer ecosystem that can patch flaws, publish guidance, and evolve the specification after real-world abuse appears. The article points to PKCE as the response to authorization code interception in mobile contexts, which shows how a standard can absorb lessons from failure rather than leaving every organisation to invent its own fix. For NHI governance, that matters because token flows, delegated access, and agent credentials will fail in similar ways across many systems. Standards do not remove risk, but they make risk patterns easier to recognise and correct.

Practical implication: Prefer standards that have active maintainer communities and a visible history of security revision.

Why MCP raises the value of identity standards

Model Context Protocol becomes far easier to adopt when the underlying security layer already uses familiar identity patterns such as OAuth. That reduces the amount of new policy logic a team must create before an agent can safely call tools or data sources. The architectural lesson is simple: every new protocol multiplies risk if it also introduces a new authentication model. For agentic AI, the better design is to reuse established identity standards so the control plane stays intelligible to IAM, security, and platform teams.

Practical implication: Anchor agent connectivity in existing identity standards before adding protocol-specific exceptions.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

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

NHI Mgmt Group analysis

Standards are becoming the only practical way to govern NHI sprawl at scale. Once service accounts, API keys, tokens, and agents multiply across platforms, custom controls become brittle and hard to audit. Reusable standards give security teams a shared language for policy, lifecycle, and verification. Practitioners should treat standards adoption as a governance requirement, not a preference.

Ephemeral integrations still need durable trust rules. MCP and similar protocols do not remove the need for identity boundaries, they make those boundaries more important because agents can act across tools and data sources. If the trust model is improvised, the blast radius grows with every new integration. Practitioners should standardise authentication and authorisation before expanding agent autonomy.

Security teams should expect standardisation pressure to shift from infrastructure to identity controls. The more AI systems rely on interoperable protocols, the more access decisions move into policy, tokens, and delegated authority. That means IAM, PAM, and NHI governance must align around consistent controls rather than application-specific exceptions. Practitioners should build identity policy once and reuse it across agent and workload surfaces.

Standards do not eliminate vulnerability, but they make remediation scalable. The article is right that a shared specification can concentrate exposure, yet that same shared surface is where coordinated fixes happen fastest. In NHI security, the alternative is hundreds of private implementations that fail differently and are patched slowly. Practitioners should prefer standards that can be governed, tested, and updated across environments.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• That pattern reinforces the lifecycle problem described in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs: standardised controls only help when they are actually governed end to end.

What this signals

The strategic signal for IAM and NHI programmes is that protocol adoption is now inseparable from identity governance. Once AI agents and tool-use systems depend on standards such as OAuth, the team’s real task becomes deciding how policy, approval, and audit rules travel with the protocol instead of living around it. That is where reusable identity controls start to matter more than application-specific exceptions.

Identity portability debt: every new integration that redefines authentication, authorisation, or token handling increases the cost of later governance. As MCP-style ecosystems expand, security teams should align their policy model to established identity standards and tie it back to NIST Cybersecurity Framework 2.0 functions for govern, protect, and detect. The programme risk is not just technical inconsistency, but fragmented accountability across tools and teams.

For practitioners

• Standardise agent authentication on existing identity protocols Use established identity flows for AI agents and tool access instead of inventing bespoke auth patterns for each integration. This keeps policy review, token handling, and audit trails consistent across workloads and reduces the number of places where trust decisions are embedded in application code.
• Map every new protocol to a control owner Assign IAM, platform, and security ownership before introducing MCP or similar protocols into production. The important step is deciding who approves token scopes, who reviews delegated access, and who responds when the protocol changes or a flaw is published.
• Prefer community-maintained standards over private extensions Where a standard exists, adopt the standard first and reserve custom extensions for narrowly justified exceptions. Community-maintained specifications usually surface implementation guidance, tooling, and patches faster than proprietary approaches, which helps with long-term NHI governance.
• Review agent-to-tool trust boundaries before scaling autonomy Document which tools each agent can call, which tokens it can obtain, and which actions require additional approval. That review should happen before production rollout, because the risk grows as soon as the agent can chain decisions across multiple systems.

Key takeaways

• Standards are not just interoperability tools, they are the mechanism that lets security teams govern identity flows repeatedly instead of improvising each integration.
• In AI and NHI environments, the biggest value of standards is not simplicity at first glance, but maintainability when failures, patches, and new protocols arrive.
• Practitioners should treat standards adoption as an identity governance decision, because the alternative is accumulated trust debt across agents, workloads, and tools.

Key terms

• Model Context Protocol: A protocol that lets AI agents connect to tools and data sources in a structured way. Its security value depends on the identity and authorisation layer beneath it, because the protocol can only be governed well when access decisions are explicit and reusable.
• OAuth Authorization Code Flow: An OAuth pattern that exchanges a temporary code for tokens instead of sending tokens directly through the browser redirect. The design reduces exposure during the authentication step and is widely used because it separates the front-channel interaction from token issuance.
• Non-Human Identity: Any identity used by software rather than a person, including service accounts, API keys, tokens, certificates, workloads, bots, and AI agents. NHI governance focuses on lifecycle, scope, and trust boundaries, because these identities often outnumber human users and are easier to over-privilege.

Deepen your knowledge

Standards-based identity governance and NHI lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is extending OAuth, MCP, or workload identity patterns into agentic systems, it is worth exploring.

This post draws on content published by Curity: an analysis of why standards matter for software security and adoption. Read the original.