Curity Blog

MCP Authorization Isn’t Enough For AI Agents

Michal Trojanowski — Thu, 03 Sep 2026 00:00:00 GMT

As we delegate more and more tasks to AI agents, we need to ensure that they act with proper permissions. Users and organizations should treat an agent as another type of identity that acts in their systems and limit their capabilities accordingly.

We're used to limiting permissions to users — we want to ensure that a user with access to a system operates with the minimum privileges required so that they do not abuse that access (either by themselves or when their credentials get stolen). The same principle applies to agents: when you delegate a task to an agent, you should ensure that the agent operates with minimum permissions to perform that task so that it does not misbehave.

Definition

Agentic authorization is the practice of granting AI agents only the minimum, revocable permissions needed to complete a specific task. Ideally, it should be governed by a centralized policy that the user and organization control, not the agent or the server it's calling.

The Model Context Protocol (MCP) specification and user-facing agents (like Claude Code) offer some features that are supposed to address the access problem:

MCP authorization,
step-up authorization in MCP
tool call control in agents

While they offer some level of control, in this post I will explain why they fail to enable fine-grained agentic authorization where the user stays in control of the agent's capabilities. At the end, I explain what we, at Curity, think is the solution.

Why MCP Authorization Isn't Fine-Grained Enough

The MCP authorization part of the specification ensures that only authenticated and authorized agents access an MCP server. The specification uses OAuth to implement this protection, assuming that, at least initially, there is a user who runs the flow and delegates access to their resources through the MCP server. For example, when you connect Claude Code to the GitHub MCP server, you will run an OAuth flow, log in with your GitHub account, and grant the agent access to your resources.

This allows the MCP server to ensure that only authorized agents call its tools. It also allows the MCP server to use the agent's token to call any underlying services (APIs) that process tool calls. The server informs the client what scopes it should use when asking the user for authorization, which limits the capabilities of the agent.

However, scopes offer only coarse-grained access control, are fairly static (once granted, the access token will have the scope for a longer time), and are at the discretion of the MCP server. This means that the user has limited control over what permissions they will grant to the agent and for how long. A usual MCP authorization flow looks similar to this:

The user wants to connect an MCP server to their agent.
The MCP server returns a request for authorization and indicates the scopes the user should grant to the agent.
The agent initiates an OAuth flow asking the user to grant consent to the scopes. Once the user grants access, the agent gets an access token with the scopes that allows it to call any tools that require the given scope.

The user is not able to control which tools the agent can access, with what parameters, or for how long. It's also usually at the agent's discretion to ask only for the necessary scopes; however, it might be tricky for the agent to know upfront which minimum set of scopes is necessary. Again, the user has no control over this behavior.

Why Step-Up Authorization Still Leaves the MCP Server in Control

The MCP server can request step-up authorization in two ways: through a direct 403 MCP response or with URL elicitation. In the former case, the MCP server returns an `insufficient_scope` error response directly to the client, which triggers another authorization flow. When using elicitation, the MCP server returns a URL to which the client should redirect the user. The URL can direct the user to a page where they can provide consent to the high-privilege operation or enter some additional credentials required by the tool.

Both approaches lead to the same result — to allow the agent to perform a sensitive operation. However, there is one notable difference. With the direct approach, the agent receives the high-privilege token and then retries the operation.

With the elicitation approach, the user performs the approval outside of the client, then asks the agent to retry the operation. It allows the agent to eventually fulfil the given task, but it does not handle any high-privilege tokens or credentials that were needed for that. With the direct approach, as the agent takes control of the high-privilege token, there is a risk that the agent will misuse it.

Step-up authorization enables the MCP server to implement greater control over agents' behavior. Yet again, the control stays in the MCP server's discretion. When connecting to third-party MCP servers, users and organizations cannot decide which tools they deem high-risk, nor can they apply fine-grained policies to tool calls. A tool's sensitivity can differ based on the parameters used to call it.

Why Tool Call Control Doesn't Solve the Issue

Agents that act as MCP clients usually implement some kind of tool call control in their harness. The agent informs the user that it plans to call a tool on a specific server with concrete parameters. The user has an option to accept or reject the action. Very often, the agent will also give the user an option to allow all future calls of the given tool.

This gives the user control over the agent's behavior. However, the feature has some limitations:

It requires the agent to have an interface to the user — either direct (front channel) or indirect (back channel). The agent needs a way to collect the user's consent.
Giving consent for future tool calls is not fine-grained. Usually, this means consenting to using the given tool, regardless of the parameters or context.
The feature might be affected by the agent's non-deterministic behavior. For example, when the agent wants to get the user's consent for future tool calls, sometimes it will ask to consent to calling the tool with concrete parameters, and sometimes to consent to just the tool being called, even when the same prompt triggers the question.
A tool call can be fairly technical. It might be hard for the user to understand what the agent is trying to achieve given just the tool name and parameters.
Agents solve more and more complex issues, which usually means calling a number of tools to reach the goal. This can quickly lead to consent fatigue, where the user automatically approves tool calls without actually verifying what the agent is trying to do.
Even if the user gets fairly fine-grained options to control the agent's behavior, the control is local and is not governed by a standard policy. This means that organizations cannot control the policy centrally, and the user cannot port the policies to other agents.

How the Approaches Compare

Approach	Granularity	Who's really in control	Key limitation
MCP Authorization	Coarse (scope-level)	MCP server	Scopes are static and broad once granted
MCP Step-Up Authorization	Medium (per high-privilege operation)	MCP server	Server defines which operations are high-risk, not the user
Tool Call Control	Fine, but per-tool not per-context	User, locally	Not centralized, not portable, consent fatigue

While the different approaches offer some control over the agent's behavior, neither of them provides fine-grained, contextual authorization that users and organizations can control centrally.

Token Vaulting: Centralized, Fine-Grained Agentic Authorization

Securing access to third-party MCP servers with OAuth access tokens gives a robust foundation on which you can build a fully-featured authorization solution. At Curity, we think that users and organizations can solve agentic authorization by implementing token intelligence patterns like the token vaulting approach.

In the token vaulting pattern, high-privilege access tokens are kept away from the agent by default. When the agent wants to call MCP servers, it performs a token exchange so that the MCP server eventually receives the vaulted token. During the exchange, the vault consults a policy using context information to make an informed authorization decision on whether the agent should perform the given action.

Such a solution leverages existing standards to hand back control over the agent’s behavior to users and organizations. It allows them to apply centralized, fine-grained policies, where the vault component makes authorization decisions based not only on static permissions but also on dynamic, context-aware attributes. For example, a policy can allow the agent to call a mail-sending tool only if it tries to send e-mails to pre-approved recipients.

Organizations can control agent behavior regardless of whether the agent has a user interface and do not rely on controls applied either by the agent or the MCP server. At Curity, we strongly believe such an approach is necessary to keep agents from misbehaving.

5 Business Benefits of an Intelligent Access Layer

Sutton Maxwell — Wed, 19 Aug 2026 00:00:00 GMT

Your access layer can be so much more than a cybersecurity mechanism. Access Intelligence supports secure AI adoption and broader business goals.

Today's enterprises rely on a vast array of digital connections behind the scenes. And a core connective tissue for safely exchanging data is the access layer — a critical piece for controlling access and authorization to underlying systems. Yet, not all access layers are robust, AI-native, and equipped to handle human and non-human actors through dynamic access decisions at runtime.

An intelligent access layer should unify access for all types of users and clients, issue tokens, and control access to APIs, applications, services, and AI agents. This is a foundational component of identity and access management (IAM), helping to determine whether parties requesting resources are who they say they are and whether they have the proper permissions.

While an access management platform is essential for modern authentication and authorization, its benefits extend far beyond cybersecurity or compliance. A dedicated access layer built by experts is the linchpin for modern business and AI enablement. It's important for guiding API-connected growth and preparing organizations for AI and agent-driven interactions.

Without a standard access layer, enterprises run the risk of ad hoc user logins, stifled partner innovation, inconsistent access policies, and reduced performance and reliability. Below, we'll explore these areas and see how an access management platform can benefit enterprises at scale by reducing expenses, unlocking business growth, and improving AI readiness, all while ensuring safe integrations with critical data.

1. Improved AI Readiness & Agility

An intelligent access layer is core to modern digital transformation. And the most important change occurring across IT at large is AI transformation. More specifically, large language model (LLM)-based AI agents are gaining increasing levels of autonomous read and write permissions to business systems, carrying with them novel security concerns.

Since LLMs are prone to unpredictable outputs, they require more explicit controls around what they are allowed to do. Multi-agent systems (MAS) can experience privilege drift, too, in which scopes become repurposed and spread across agents, granting broad, over-permissioned access and making agentic systems prone to data leakage, unauthorized actions, and unclear audit trails. On top of that, many AI agents are operating on systems with fragmented access controls or rely on long-lived API keys.

What we're facing is a new access control dilemma. What's needed is a zero-trust strategy for the agentic AI era, combining highly scoped privileges, just-in-time access, real-time credential grants, and zero standing privileges. Instead of a new identity for agents, organizations should focus on flexible authorization and granular permissions in order to support agentic AI.

With an intelligent access layer as a foundation, you can continually check for proper AI authorization. This makes it much easier to safely enable agent-driven transformation across your internal services as well as expose services as Model Context Protocol (MCP)-based capabilities for external agents to consume. Without a strong access control model in place, organizations risk losing pace with competitors.

2. Reduced Effort & Lower Costs

In corporate scenarios without shared access infrastructure, a classic result is different departments using competing home-brewed authentication and authorization methods, as developers reimplement them for every new project.

Re-engineering similar components and workflows for partner identity and access management (PIAM), customer identity and access management (CIAM), or internal employee access wastes time and effort. It can also be considerably costly to develop and maintain. These systems also require deep engineering knowledge of core identity protocols and standards, such as OAuth 2.0 and OpenID Connect, to implement effectively.

By externalizing access control to a dedicated, standards-based access layer, you enhance technology reusability and rely on specialists to maintain complex security infrastructure as its own component. Having a dedicated, flexible access layer removes duplication, lowers development effort, and, in effect, lowers costs.

According to Gartner, 90% of firms permitting AI agent credential sharing will have to rebuild their identity systems. Organizations that use a dedicated access layer, instead of building one ad hoc, can prevent this unnecessary rebuilding.

3. Safer Integrations & Compliance

Enterprises are now facing a heap of regulatory requirements, including GDPR, HIPAA, PSD2, CCPA, and others. These regulations create strict expectations around how sensitive data is accessed, shared, protected, and audited. In some sectors, such as open banking, organizations must also support secure data sharing with authorized third parties.

An access layer is essential because it authenticates the requesting subject, issues tokens with the right claims and scopes, and enables services, gateways, and policy engines to enforce authorization decisions. In an enterprise setting, these are essential ingredients to guide safe, compliant access to resources.

A robust access infrastructure is ultimately required to enforce least-privilege access for the correct parties at runtime, helping enterprises secure microservices and APIs that interact with sensitive data. All in all, safer integrations help avoid loss of consumer trust, since security failures can trigger customer churn. Better security also helps avoid data leakages and resultant fines for non-compliance with data sharing regulations.

4. Partner Enablement & Growth

APIs are the lingua franca of today's digital business. They enable partners to automatically access data and perform actions within important business systems, and many APIs are products in their own right. By building API-first, businesses reap the platform effect, which in turn spurs co-creation. However, this openness requires careful access management.

An intelligent access layer empowers API-enabled business growth. With a standard, centralized access layer across every API, you are better prepared to quickly delegate third-party access to your systems in a safe, controlled fashion. OAuth-based workflows supported by an authorization server help streamline the traditionally cumbersome process of enterprise integration and federation.

With a centralized access layer, you are well-equipped to secure and serve various consumer types, whether they are internal users, external customers, partners, or machine-based workloads. By eliminating the overhead surrounding delegated access, you're far better positioned for innovation and supporting increased revenue.

5. Better Reliability & Performance

Access control requires highly performant and reliable cloud-native infrastructure at enterprise scale. This includes performant token issuance, efficient token validation patterns, resilient key management, and well-designed approaches to session and token revocation. Mature access infrastructure built on durable, time-tested industry standards is generally more reliable than internal access control systems built ad hoc per project or department.

Specialized access management platforms deliver the sort of service-level agreements (SLAs) that enterprises require in order to meet their security standards. But beyond meeting performance guarantees, using a dedicated access layer is an added investment in ongoing research and development (R&D).

Access management is grounded in mature security practices but continues to evolve with the pace of industry trends, the digital sovereignty movement, and government-led data security mandates. New advances include digital wallets, verifiable credentials, passkeys, and a slew of protocol-level identity standards. Investing in standards-based access infrastructure means your access control systems stay state-of-the-art as these trends manifest into real-world production expectations, without having to perform all the research yourself.

AI-Native Access Control: A Standard Practice for Today's Digital Enterprises

Access layers are a standard practice within today's enterprise IT stacks. They are a critical abstraction for preserving API security: many CISOs agree that IT security is moving beyond traditional endpoint or perimeter-based security to address the growing API attack surface. With this comes the need to arm business-critical connections with high-grade access control.

But as we've seen, the business benefits extend far beyond cybersecurity. A shared access layer positions organizations to support partner and consumer growth, enable compliant interactions, reduce duplicated engineering work, and connect today's heterogeneous software systems with an equally diverse consumer base.

In short, a dedicated AI-native access layer reduces engineering costs, strengthens compliance and safe data sharing, accelerates partner and API-driven growth, prepares organizations to securely adopt AI agents, and delivers the reliability enterprises require — making it foundational infrastructure for modern digital business.

Curity provides a reliable access management foundation for innovation while addressing the nuances of API-connected and AI-driven interactions. To learn more, explore how Curity Identity Server and Access Intelligence can help organizations strengthen access control across APIs, applications, services, and AI agents.

Curity Identity Server 11.4: FIPS 140-3, DPoP binding and Database Scopes in the Admin UI

Curity — Tue, 11 Aug 2026 00:00:00 GMT

Curity Identity Server 11.4 is out. Three things stand out: a FIPS-compliant mode, DPoP binding extended across the OAuth endpoints and Database Scopes moving into the Admin UI.

FIPS 140-3 compliance

On September 21, NIST moves every remaining FIPS 140-2 certificate to the historical list. Existing deployments keep running, but from that date a 140-2 validation no longer satisfies new federal procurement. Anything acquired after it needs an active 140-3 validation.

The Curity Identity Server can now be configured to run in FIPS-compliant mode, so cryptographic operations are performed using validated algorithms and modules. It ships as a FIPS-compliant Docker image, available with the FIPS support add-on.

This matters beyond US federal. If you supply organizations that sell into government or you work in defense, financial services or critical infrastructure, FIPS validation has become procurement shorthand for cryptographic assurance.

DPoP binding across the OAuth endpoints

The server now issues DPoP-bound access tokens for all client types and can bind the authorization code itself to the client's proof-of-possession key. Server metadata and the introspection endpoint reflect the binding. Both the Admin UI and the DevOps Dashboard expose DPoP configuration at the OAuth profile and client level, so you can roll it out per client rather than flipping a switch across the estate.

This is Token Intelligence in practice. A token only works for the client that earned it, which means a stolen one is worth nothing on its own. Bearer tokens assume the holder is the owner. Proof of possession removes the assumption.

Database Scopes in the Admin UI

Database Scopes introduced as an experimental feature in 11.3, can now be fully managed from the Admin UI. A setup wizard walks through enabling and configuring the feature, a simplified schema editor handles creating and editing scopes, with support for Ephemeral Clients. The GraphQL API also gains the ability to filter scopes by claim name.

The practical effect is that scope changes stop queueing behind the one person who knows the config. Teams managing large or fast-moving scope catalogs can make changes where they already work.

Also in 11.4

A new SDK service lets plugins publish their own metrics. The Passkeys and WebAuthn authenticators support configurable rpId. Persistent background jobs get continued hardening. Temporary Lockout now emits an event when it reaches its maximum, and there is tighter handling of activation-email resends and password-reset link invalidation.

Get the details

Full release notes are on the Developer Portal.

We are running a walkthrough webinar on August 17. Register to catch the session live.

Or go straight to it: start a free trial and see how 11.4 fits your architecture.

5 Agentic AI Security Incidents & Vulnerabilities

Bill Doerrfeld — Mon, 03 Aug 2026 00:00:00 GMT

The tech world is off to the races with AI agents. These large language model (LLM) based AI assistants can operate autonomously, sync up tools, data, and APIs, and speed up both engineering and business workflows in the process. Agentic AI is a powerful leap for the industry — however, recent security incidents are showing their flaws.

A number of recent security incidents and vulnerabilities have proven how agents can act unpredictably, which has led to outcomes like deleting production databases, leaking sensitive data, or triggering unauthorized commands. Agents are often left to operate with high degrees of autonomy and over-permissioned access, making them a growing concern.

Below, we’ll look at recent examples of agentic AI risks. We’ll briefly state what happened with each, what the outcomes were, and what security engineers and architects need to know going forward. These examples showcase the importance of least-privilege permissions and setting up new guardrails for agentic AI.

1. Replit database deletion

In mid-2025, The Register reported that Replit, an AI coding tool, deleted customer production databases, even though the user had given it clear instructions not to change any code without permission. Due to “a catastrophic error of judgement” on the part of the AI coding agent, the database was overwritten.

Additionally, the user, the founder of SaaStr, shared that the coding agent was prone to creating fake reports and data, including a 4,000-record database full of fictional people. Although the user was able to roll back to an earlier version of the database, it was a stark wake-up call.

The Replit database deletion story demonstrates that, even with clear prompts, AI and agents can behave erratically. It also underscores the risks of providing agentic AI with too much access to sensitive actions. Instead, taking a least privilege approach and providing granular access permissions when necessary should be the default.

2. Moltbook token leak

Moltbook is an interesting social network, coded purely by AI, and designed to be a place where AI agents can chat among themselves. The platform made headlines as the first AI-native social network, quickly garnering over a million user signups.

But in February 2026, researchers at Wiz, a cloud security company, discovered an API key to a misconfigured Supabase database, which then could be used to leak all of the Moltbook platform’s data.

The leak exposed 35,000 emails and 1.5 million API keys for users in the network. It also discovered there were actually 17,000 human owners behind the network’s purported 1.5 million AI agents. Although the bug was quickly remediated, it showcases the frailties of vibe-coded applications, which can be prone to misconfigurations and exposing credentials.

Relying on static API keys was already risky before agents existed, but the blast radius is now amplified in the AI agent era, since agents can act at scale and faster than a human could. And if AI agents have unauthorized read and write access to these kinds of exposed APIs, the damage can be much worse.

3. PocketOS system outage

In mid-2026, Cursor, an AI tool powered by Anthropic’s Claude Opus model, was responsible for deleting a production database operated by PocketOS, a software provider for rental car businesses.

As EuroNews reported, the AI tool was performing a routine task when it decided to delete an entire database related to customer records and bookings was the most efficient course of action. The deletion resulted in a 30-hour outage in which core PocketOS business systems were offline.

“This isn’t a story about one bad agent or one bad API,” PocketOS founder Jer Crane told EuroNews. “It’s about an entire industry building AI-agent integrations into production infrastructure faster than it’s building the safety architecture to make those integrations safe.”

The incident shows how LLM-powered agents can produce destructive actions, even when prompted otherwise, which can directly lead to loss of business. The story further emphasizes the need to insert human-in-the-loop controls for destructive actions, or reduce the privileges these agents have in the first place.

4. GitHub agentic vulnerabilities

In July 2026, researchers at Noma Security discovered a prompt injection-style vulnerability within GitHub’s Agentic Workflows, a tool for syncing AI agents with GitHub Actions to bring more automation to repository management. They call the vulnerability GitLost.

They discovered that an unauthenticated attacker could leave instructions in natural English language within an issue made to a GitHub repository. The agent attached to the repository would then read these instructions and incorporate them into its prompt. By following this strategy, an attacker could manipulate the workflow into leaking data from private repositories.

Other researches have unearthed potentially toxic agentic AI flows involving GitHub. In 2025, Invariant Labs found that by using the official GitHub MCP server, one could hijack a user’s agent with a malicious GitHub issue and manipulate it into performing unintended actions.

Both of these vulnerabilities highlight the fact that agents depend highly upon their context in order to function. And when that context is poisoned, things can go awry. To respond to agentic mishaps, strategies like just-in-time access and zero standing privilege are emerging to limit long-lasting privileges to short-lived access when sanctioned in the moment.

5. Salesforce Agentforce data leakage

Noma Security has also discovered the possibility of prompt injection-style attacks within other common enterprise software. In late 2025, they outlined how Salesforce Agentforce agent could be hacked by including malicious instructions within trusted data sources like external domains.

This vulnerability was quickly patched by Salesforce with Trusted URLs. And while no business was impacted by this incident, that we know of, it nevertheless reinforces the idea that AI agents have created a novel attack surface. It also demonstrates how one method of response is scoping what the agent can access to verified, trusted content.

Overpermissioned access is the common thread

The Least Privilege Research Report 2026 analyzed over 3 billion permissions and found that, on average, only 4% of permissions were used in the last 90 days. Furthermore, nearly one in three permissions can modify or delete sensitive data.

Since agents usually inherit human privileges, it means they too often have over-permissioned access. And with a high degree of access, agents can act of their own accord in ways that have real, sometimes irreversible consequences. And it’s not just agentic AI: simple chatbots can suffer the same fate.

Just take the well-covered chatbot incident with Air Canada, in which a chatbot hallucinated and incorrectly promised a passenger an airline discount. While it’s less “agentic” per se, it’s proof that even AI-powered chat with too much authority can have direct business repercussions that go beyond traditional security breaches.

Avoiding agentic AI incidents

Given the incidents above, it’s clear that the risk surface has expanded. So, how should organizations respond? Preventing agentic AI risks holistically will require a variety of approaches:

Better prompting and context: Information provided to agents needs to be accurate and free from malicious injection. The OWASP Top Ten for LLM Applications provides guidance on avoiding generic LLM-based threats.
Consent and approval flows: Human-in-the-loop controls should be used for destructive actions, along with audit logs and restrictions that scope agents to verified, trusted content.
Proper access control: A high degree of standing access to data, API endpoints, and sensitive functions unnecessarily expands the surface area. One approach is defaulting to read-only modalities and upgrading to write modes when necessary.
Granular permissions: Use scoped tokens, delegated authorization, identity-based authentication and authorization, policy enforcement, and least-privilege access to every API and data source agents touch.
Highly scoped access: Limiting permissions can reduce the possibility that an unpredictable action leads to exposed data, unauthorized commands, or the loss of a production database.
Just-in-time access: Least privilege is evolving beyond traditional zero trust principles that involve long-lasting privileges. Just-in-time access provides short-lived access when sanctioned in the moment.
Zero standing privilege: This goes further by removing long-lasting privileges altogether. Access is highly scoped, granted when necessary, and removed immediately after actions. This is the pinnacle of limiting privilege drift and reducing the consequences when agents act of their own accord.

What Is Zero Standing Privilege?

Bill Doerrfeld — Mon, 13 Jul 2026 00:00:00 GMT

Today's enterprises are full of accounts with standing privileges to sensitive data and functions. Standing privilege is when an actor, whether a user, admin, or machine, has long-lived permission to access a resource. These entitlements often follow role-based access control (RBAC), but they are becoming stale and insufficient as the modern attack surface expands and new agentic threats emerge.

Zero standing privilege (ZSP) is a response that evolves today's cybersecurity defenses. The practice extends the principle of least privilege with more time-boxed access policies. Whereas least privilege grants only what an entity requires and nothing else, zero-standing privilege goes one step further to remove standing privileges from identities altogether. Instead, ZSP evaluates each access request at execution time and grants temporary privileges only for the specific action being performed.

How Zero Standing Privilege Differs from Least Privilege and JIT Access

Approach	Access Scope	Access Duration	Standing Privileges
Least privilege	Minimum required	Long-lived	Yes
Just-in-time (JIT)	Broad, granted in real time	Time-limited	No
Zero standing privilege (ZSP)	Task-specific	Revoked immediately after the action	No

Zero standing privilege, also known as zero standing access (ZSA), is part and parcel of an enterprise's access intelligence. The concept is similar to just-in-time (JIT) access, aside from a couple of nuances. Arguably, ZSP is the pinnacle of a JIT access system. Instead of issuing broad access in real time, zero standing privilege takes this idea a step further.

With ZSP, identities have no entitlements to a resource until they are invoked and elevated in real time. This quality is especially important in the era of AI agents, since this technology can behave erratically, requiring tight capability restrictions and time-bounded access.

Why Zero Standing Privilege Is Important

Nowadays, identity and scope sprawl are common. Enterprises are juggling a slew of different identities across their platform architecture, from cloud accounts and admins to end users, partners, and beyond. The issue is that identity and access management (IAM) systems often configure various roles and permissions once and then let them sit.

However, such standing privileges pose a cybersecurity threat. Since backend systems change, if security teams are not actively reassessing the privileges of entities, stale credentials can easily turn into a form of shadow IT. And it's not just user-based accounts that require identity forethought and active privilege management — machine-to-machine accounts are often granted long-lived entitlements as well. Yet, some container-based workloads are ephemeral, requiring identities and their privileges to be created in the moment.

Another driver is agentic AI. The nondeterministic nature of large language model (LLM)-based agents makes their ability to make and connect API calls unpredictable. Removing persistent privileges and adopting ZSP make agentic access to critical resources temporary and time-controlled, benefiting an enterprise's cybersecurity posture at large and improving its access control foundation for cloud-native architectures and agentic AI. For a real-world example of what happens when these principles are ignored, see our analysis of the Vercel breach — a high-profile incident driven by overprivileged OAuth tokens and standing access.

What's Involved In Zero Standing Privilege

There are a few key concepts and components involved in a zero-standing privilege setup. First is the scope, which determines what systems the entity can access and what privileges are required. Next is the time, including when access is granted and how long the duration of access will be.

This is made possible with token intelligence. For example, instead of providing a long-lived access token that a requesting party can use indefinitely, the system issues an extremely short-lived access token upon request with a short expiration window. In addition to access being granted for a very short time span, scopes are highly granular and task-specific. These can represent particular tasks or actions, such as making a lookup in a database or making edits to a table.

The token is typically issued and validated by an identity provider within an OAuth-based flow. After the action has been completed, the token expires, or access is revoked as quickly as possible. In practice, ZSP requires an access engine to accept and validate requests, invoke and elevate privileges, and then remove them once the session is finished.

type: embedded-entry-inline id: 901xN5zjLQugnPfmVE2TA

Examples of Zero Standing Privilege

There are a number of scenarios where zero standing privilege would be useful for those working within high-security domains. There are clear cases within highly regulated banking and healthcare scenarios, as well as sensitive company data functions.

For example, imagine an administrator for a bank's internal architecture must share access to a bulk user data export function for a third-party partner. This might be programmed logic behind an API endpoint. In this scenario, allowing access just in time is not enough. Access should be highly scoped to that particular method and then revoked immediately after the action is complete.

Or, consider an AI agent assigned to access healthcare records for a particular patient across multiple healthcare providers. In this case, the AI agent should not hold standing privilege to sensitive read or write functions. Instead, it should be granted access to specific functions on a case-by-case basis only when needed.

For a deeper look at how to implement this securely, see our guide on securing backend agents with Access Intelligence.

In both scenarios, the requesting party would request access, and an identity system or authorization server would validate the request, elevate the privilege of the requesting identity, set a time frame for the operations, and then revoke access upon completion.

Benefits of Zero Standing Privilege

The benefits of zero standing privilege are numerous. Most importantly, it reduces the exposed attack surface. Always-on standing privilege can be a big security risk and lead to compromised accounts, breaches, data exposure, and possibly even hefty fines. A more continuous approach to authentication and authorization ensures permissions are assessed on a more constant basis.

Adopting zero standing privilege naturally helps address some of the biggest risks within the OWASP API Security Top 10. Many of the top vulnerabilities in this list have to do with broken access control and authorization-related faults. Minimizing the exposed capabilities to an entity at runtime reduces these vectors.

Removing overprivileged accounts minimizes your cyberattack surface tremendously, improving overall security hygiene. It also puts an organization in a far better position to grant access on the fly to AI agents as they request institutional knowledge or conduct API requests against backend systems.

Zero Standing Privilege: Critical For Agentic AI

To combat emerging threats, enterprises are evolving their least privilege strategies as part of modern zero trust environments. A key element of this access intelligence is removing standing privileges, which is especially important for enterprises juggling multiple user types or deploying machine-based entities.

Agentic AI also underscores the need for zero standing privilege. The nondeterministic nature of large language model (LLM)-based agents makes their ability to make and connect API calls unpredictable. By elevating privileges only at the moment of action, organizations can guard against undesirable behaviors and remove entitlements that might otherwise be unintentionally passed to these agents.

More policy-based decision-making is the future of access intelligence. By adopting zero-standing privilege, IT systems can restructure permissions around not only the minimum access required for a task but also the exact moment access is requested and the shortest time window needed. It's a simple concept, but one that's complex to implement with meaningful implications for securing identities across the enterprise stack.

AI Agent Access Control: What Anthropic Gets Right - and Where Enterprise Security Needs More

Sutton Maxwell — Thu, 02 Jul 2026 00:00:00 GMT

Anthropic recently debuted a new model for how Claude Tag, its multiplayer AI workspace product, handles agent access. The model is described for "agent identity" but the question it's actually answering is an access question: when an AI agent operates autonomously across a team, what should it be allowed to reach and on whose authority?

Their answer: the agent needs its own identity, scoped by an admin, independent of any single person in the channel. We agree. But the solution they describe is designed for a very specific engineering situation using Slack — and that distinction matters a lot if you're thinking about AI security at the infrastructure level.

Anthropic's solution encourages broad, persistent permissions by default and lacks just-in-time credential grants, running the risk of breaking a least privilege model. The solution also lacks the identity maturity and complexity required by highly connected enterprise setups involving partners or third-party agentic access.

For an isolated Claude Tag deployment, this may be workable. But as a broader enterprise security model, it risks moving too much authorization logic into an AI workspace instead of keeping access decisions anchored in the organization's IdP, authorization server and policy layer.

What Anthropic Got Right

Anthropic’s agent identity post is honest about why per-user credential delegation stops working for autonomous, multiplayer agents. They cite two reasons:

First, agents now run procedures long after the person who triggered them has logged off. They schedule their own tasks, respond to events and operate without human supervision. The user who started the task isn't steering it anymore so their credentials shouldn't be driving it either.

Second, in a shared channel with multiple contributors, whose permissions apply? Any single choice is arbitrary and probably wrong for some share of the requests. Binding agent access to whoever happens to be present means permissions change with every person who walks in or out, and that's both unpredictable and exploitable.

Anthropic’s answer is to give Claude its own service accounts — in Slack, GitHub, a data warehouse — provisioned by an admin and scoped to the workspace or channel. Claude posts as the Claude app, opens PRs as the Claude GitHub App, queries the warehouse under a service account with no personal credentials in play. Revoking the identity ends access everywhere it was used.

This is sound thinking. The move from "act as the user" to a dedicated non-human identity is the right direction for agentic systems and it reflects what we've been arguing for in the context of API access control. But a dedicated identity only solves half the problem. For that identity to work at speed and scale, the token it generates needs to carry the right context — who the agent is, who delegated to it, what it's permitted to do — so every API downstream can make the right access decision without a separate lookup. That's exactly what Token Intelligence is designed to do.

Where the Models Diverge

Claude Tag's agent identity model is designed for one agent (Claude) operating inside one controlled environment (currently only on Slack). That context shapes every design choice and it also defines the limits of what the model addresses.

The agent is known and trusted by assumption

Anthropic built Claude, operates it and controls its behavior. Admins aren't making a trust decision when they configure Claude Tag cause that decision was already made. The access model works because the agent on the other end is not arbitrary. The harder enterprise problem lies in what happens when the agent calling your APIs is a third-party system, a dynamically registered client or something your security team didn't build and can't inspect. This is also where the revenue and utility for AI sits in general. If organizations are aiming to roll out AI towards consumers in revenue-line services, this becomes a significant and unmanageable risk. The solution requires an access model that doesn’t assume trust.

Access is static, yet needs to be runtime-evaluated

An admin configures what Claude can reach in a given channel. That configuration persists until someone changes it. There's no per-request evaluation of whether this specific action, at this moment, from this agent, on behalf of this user, should be allowed. Claude Tag enforces access at the channel boundary. This is a useful control, but only a coarse-grained control. Enterprise environments are more complex than a single Slack channel and that complexity demands runtime authorization: every API call in the chain gets evaluated against identity, context and risk at the moment it happens, not just at the door.

Standing privilege vs. zero standing privilege

Zero standing privilege means an agent holds no valid credentials between tasks — access is issued per interaction and expires when the task ends, leaving no live permissions to steal or misuse. Claude Tag creates persistent channel-level identities. The agent holds ongoing service accounts in connected systems and access ends only when the identity is revoked entirely. This is operationally convenient but represents standing privilege, a credential that exists and is valid between uses. Companies operating under compliance frameworks or handling sensitive data can't afford that. They need access that is scoped to the task, expires when the task is done and leaves no live credentials behind.

User and agent identity are separated, not combined

In Claude Tag's model, channels use agent identity and DMs use user credentials. There's a clean firewall, but the API layer never sees both identities at once in the channel context — there's no way to enforce policy based on who asked the agent to act. Enterprises need both identities present and verifiable throughout the request chain, so that access decisions can account for not just what the agent is allowed to do, but whether the person who triggered it had the authority to ask.

The model is proprietary to one platform. Claude Tag's access controls live inside Anthropic's infrastructure. They don't integrate with your existing IdP, API gateway or authorization server.

What this tells us about where the market is heading

There's something worth noting before getting into the implications: Anthropic is an AI company and they chose to publish a post about an access model. This signals that identity and access control are no longer just the IAM team’s problem, but are becoming a broader business concern — a prerequisite for deploying AI agents and making them workable in a trusted manner.

Agents are calling production APIs, handling sensitive data and operating with autonomy that legacy access control wasn't designed for. The Claude Tag model solves a specific problem well: how to scope a trusted, known agent's access in a product you control. That's a legitimate requirement and their design is thoughtful.

However, enterprise security teams face a much deeper challenge. They need to secure APIs from agents they didn't build, running frameworks they don't control, acting on behalf of users in ways that aren't fully predictable. For that, you need an access model that doesn't assume trust, authorization that evaluates every request rather than just the initial configuration, and credentials that disappear when the job is done.

There's no magic here. The cryptographic foundations are mature. OAuth, token-based authorization and runtime policy enforcement have been around for years. What hasn't kept pace is how organizations actually deploy them for non-human clients: tokens that carry the wrong context, policies that weren't designed for autonomous agents, authorization that stops at the perimeter. AI agents aren't a special case that requires a new security paradigm but they do demand a more rigorous approach to machine IAM than most organizations have in place. That's the gap Access and Token Intelligence is built to close.

How Curity Access Intelligence Addresses These Gaps

Access Intelligence is built around four capabilities that directly address the enterprise security requirements Claude Tag does not cover:

Ephemeral clients: agents authenticate per interaction with no standing privilege. Access disappears when the session ends.
Token Intelligence: both agent and user context are carried in a single credential, so every API in the chain has what it needs to make the right decision without a separate lookup.
Runtime authorization: every API call is evaluated against identity, context and policy at the moment it happens, not just at the perimeter.
Human-in-the-loop controls: high-risk actions require explicit approval before an agent can proceed.

Access Intelligence works with any IdP, API gateway or agent framework - no rebuild required. Ready to secure agents you didn't build? Explore Access Intelligence.

EUDI Wallets: Enterprise Takeaways from DICE 2026

Gary Archer — Wed, 01 Jul 2026 00:00:00 GMT

I recently attended the DICE (Digital Identity unConference) event in Copenhagen, where most of the focus centered on rollouts of EU Digital Identity Wallets. Many identity experts bring their knowledge to DICE events, which use an unConference format, where all attendees participate in the design of interactive sessions. Attendees can learn about new identity topics or brainstorm ideas related to problems not yet solved.

The EUDI Wallet Ecosystem

DICE began with a panel discussion on Rollouts of Government Wallets, with panelists representing government agencies from Denmark, France, Germany and Moldova. Although Moldova is not currently in the EU, its participation highlights the wider interest in EUDI wallets.

The panel discussed how each of the 27 member states will first release a compliant wallet. Those states have existing identity infrastructure, so nation-states can use their own strategies to roll out wallets and ensure continuity with existing systems.

Citizens will use wallets (typically mobile applications) to present cryptographically signed digital credentials (a.k.a. verifiable credentials) to authorized digital services. Digital credentials enable citizens to provide their identity or other attributes with a high level of assurance (LoA).

Wallets use privacy-preserving patterns to present personal data, since users selectively disclose attributes. Wallets are also anti-tracking, since they use distinct signing keys and user identifiers for each digital service.

Who Can Issue EUDI Wallet Credentials?

The initial issuers of digital credentials will be government agencies like identity card authorities or passport offices within each member state. The first digital credential will be the user’s PID (Person Identification Data), containing attributes like name, nationality, and date of birth.

There are technical and infrastructure costs for member states to become compliant and manage the digital credential ecosystem. The talk on Scaling Privacy and Security explained the details, where member states must implement Essential Standards and Technical Specifications (STS).

Once the infrastructure is in place, other organizations will be able to issue their own digital credentials to EUDI citizen wallets. To do so, they may need to pay their national authority or intermediaries. For example, healthcare providers, transport authorities, universities, banks, insurance companies, and private businesses could issue digital credentials.

To act as Issuers of Digital Credentials, a.k.a Attestation Providers, organizations will need to register with their member state and explain the credential types they will issue, the user attributes they will use, and why. Registration will help to ensure industry-specific best practices, interoperability, and user privacy.

Many attendees were interested in the presentation on European Business Wallets (EBW). Business wallets will hold organizational digital credentials. They will enable Know Your Supplier (KYS) use cases, like an employee first proving their identity with an EUDI wallet and then using an EBW that proves authorization to sign contracts on behalf of their organization.

The Enterprise Opportunity: Acting as a Verifier

By far the main topic of conversation among attendees, both within sessions and when socializing afterwards, was EUDI wallet use cases for citizens and organizations.

Early use cases for EUDI wallets are likely to be around replacing cumbersome operations, like scanning passports, to prove a user’s identity or age. Citizens will then seamlessly perform operations like presenting proof of age to buy online items. Similarly, enterprises can more easily implement Know Your Customer (KYC) flows when users sign up to their digital services.

To enable these use cases, citizens must be able to present digital credentials to Enterprises who act as Verifiers, a.k.a Relying Parties. The DICE session on Evolving Verifier ID explained how wallets need trusted external context about the party asking the user for their personal information. Therefore, verifiers must also have a cryptographic identity that wallets can trust.

To act as a verifier, enterprises will need to register with their member state to gain access to wallet attributes and explain how and why they consume user attributes. Therefore, EUDI wallets provide built-in data minimization techniques for citizens to help enforce regulations like the General Data Protection Regulation (GDPR).

Discussions often raised the difficulty of industry-specific use cases, which will take longer to materialize due to the need for stakeholder agreement across both nations and industries. Example use cases might be the use of driving licenses across borders or a German citizen using their EUDI wallet as legal proof of ownership of a French property.

EUDI Wallets Are a Global Trend, Not Just an EU One

You can think of the use of wallets as a global security design pattern. The DICE session on VC’s & Wallets Outside the eIDAS Echo Chamber discussed wider usage, with topics like NIST IR 8112, which defines ways for organizations to work with federated attributes.

At DICE, there were attendees from many countries outside the 27 EU member states. I spoke or listened to attendees from the United Kingdom, South Africa, and Japan on the desire for technical alignment and interoperability. Over time, the citizen wallets trend will extend to many locations outside the EU.

Wallet-Ready Security Architectures

DICE sessions often dived into the security protocols that EUDI wallets use. These are OpenID4VCI to issue digital credentials to wallets and OpenID4VP to authenticate users who present digital credentials from wallets. You can think of digital credentials as tokens for authentication, where those tokens use an externally defined format that individual organizations cannot control.

To be wallet-ready, organizations need a strategy to integrate wallets with APIs and API clients, which will need to use attributes from digital credentials. The OpenID4VCI and OpenID4VP protocols are designed to integrate with OAuth 2.0 to enable issuance and verification use cases. In OAuth 2.0, each organization adds its own tokens for authorization, using access tokens, and should be able to fully control access token attributes.

Curity discussed this topic in our session on AI Agent Access Control. We explained how each organization should design its own access tokens to meet its particular requirements to protect resources. We explored how access tokens enable policy-based access control patterns and least-privilege access to enterprise resources as an architecture that helps to mitigate AI risks.

To use OAuth 2.0 and enable users to authenticate with wallets, clients simply run a code flow that uses a wallet authenticator. The authorization server can verify digital credentials and issue their attributes to access tokens. Clients then send access tokens in APIs, which use the attributes from JWT access tokens to authorize access to resources.

A wallet-ready security architecture should also externalize wallet integration complexity from application and API teams. Instead, an identity team can use the OAuth 2.0 authorization server to implement wallet integrations. When an organization needs to refine wallet integrations, it can do so multiple times without changing code in applications.

Learn More

At Curity, we recommend an end-to-end architecture that starts with API access control and also enables federations, like EUDI wallets. Using this architecture enables you to change security more easily and to provide business agility. To learn more about wallet integrations, check out the following resources on the Curity website.

Curity Identity Server 11.3 is Here

Curity — Mon, 15 Jun 2026 00:00:00 GMT

Curity Identity Server 11.3 is out and we're excited about this one. Here's what we've been building:

The headline addition is a built-in, React-based login application. Modern, API-driven and ready to use out of the box - no need to build your own front end. Enable it at the system, profile or individual client level and you have a polished login experience from day one.

Token issuance authorization gets a substantial upgrade with new Global, Script and Composite authorizers. This is what we mean by Token Intelligence: these additions give you the fine-grained control you need to open your platform to the world without opening your risk. Token Issuance Authorization can now also be implemented directly as a Script plugin, making authorization rules easier to build and combine.

Other highlights include persistent background jobs for scheduled and resilient task execution, experimental database scopes for managing OAuth scopes through a GraphQL API and signed OpenID Connect authorization request support for regulatory interoperability.

You can find the full release notes, go-through webinar and everything else you need on the Developer Portal.

Want to try it? Get started with a free trial and see what 11.3 can do for your architecture.

Wallets Are Becoming the Distribution Layer for Digital Trust

Judith Kahrer — Tue, 09 Jun 2026 00:00:00 GMT

Digital identity has had a distribution problem for a long time.

Banks, governments, insurers, employers, universities, and many other organizations verify people and organizations every day. They perform onboarding checks, validate documents, assess risk, and establish trust. But in most cases, that verified identity data stays inside the organization that performed the check.

A bank may know that a customer has been identity-proofed. An employer may know that a person is an employee. A government may know that a credential is valid. But that trust rarely travels beyond the organization that created it.

That is starting to change.

How Digital Identity Wallets Make Verified Data Portable

As digital credentials move into widely available wallets, verified identity data becomes portable. A person can hold a credential in a wallet and present it when needed, allowing trusted information to move with the user rather than remaining locked inside the original issuer.

Google Wallet is an important signal because of its reach, and it helped bring this shift into focus. If credentials from banks and private issuers can be distributed into wallets that many users already have on their phones, the adoption barrier changes. But the bigger story extends far beyond Google Wallet. In Europe especially, certified EU Digital Identity Wallets and other digital identity wallets will also play an important role.

The strategic shift is broader: wallets are becoming the standard place where people carry reusable digital proof.

Verifiable Credentials Turn Identity Into Reusable Trust

For issuers, this changes the value of verified data.

Today, many organizations verify identity during onboarding and use that information only internally. In a wallet-based model, that same verified data can become a service. A bank, employer, university, or private issuer can provide a credential that the user can reuse with other parties.

Identity proofing becomes a reusable trust asset instead of a one-time onboarding exercise.

The hard part is no longer only:

“How do I get the user to prove who they are?”

It becomes:

“How do I turn a verified credential into the right access decision at the right moment?”

Why Verifiable Credentials Are Evidence, Not Authorization Decisions

A wallet can deliver trusted proof. A verifiable credential can confirm trusted facts about a person, organization, or application. But proof and authorization are not the same thing.

A credential provides trusted input. The authorization system still needs to evaluate context, policy, risk, delegation, and the action being requested.

That is where Curity fits.

As wallets become more widely deployed, organizations will need a reliable way to consume credentials and translate them into access decisions. This applies to human users, mobile apps, business clients, and AI agents.

The value is not just in storing credentials. The value is in using verified claims safely at runtime. This becomes even more important as software increasingly acts on behalf of people and organizations.

Wallets solve distribution. Verifiable credentials provide portable proof. Curity turns that proof into runtime access decisions.

Why Digital Identity Wallets Matter for AI Agents

An agent calling APIs, initiating payments, or performing regulated actions should not be trusted simply because it has a token.

Systems need to understand who the agent represents, what authority it has, and whether a particular action requires stronger proof.

In that world, identity cannot remain a one-time login event. It has to become a dynamic authorization signal.

Dynamic Authorization and Just-in-Time Trust

At this point, the required evidence may go beyond identity. Depending on the transaction, the authorization system may require evidence of authority, delegation, client integrity, or proof of possession. This becomes particularly important as AI agents begin acting on behalf of users and organizations.

For example, an AI agent might be allowed to perform low-risk tasks with an existing access token. But when the workflow reaches a sensitive action, the authorization server may need to challenge the client for additional evidence. That evidence could be a client attestation, or other proof-of-possession material such as a verifiable presentation from a wallet. Only after that evidence is validated should stronger access be granted.

Emerging OAuth work, such as client challenge flows, points to how this works in practice. This is the core idea behind just-in-time authorization: instead of forcing every client to present its strongest proof on every request, the authorization server dynamically demands additional evidence only when the context or transaction risk requires it. This makes access decisions adaptive, risk-aware, and aligned with the sensitivity of the transaction.

Layer	What it does	Why it matters
Wallet	Stores and presents credentials	Makes verified identity data portable
Verifiable credential	Provides trusted proof	Lets claims be reused beyond the original issuer
Authorization system	Evaluates policy, risk, context, and requested action	Turns proof into an access decision
Curity Identity Server	Takes a crucial role in the authorization system that consumes trusted claims and enables runtime authorization	Makes wallet-based trust actionable in APIs, apps, and agentic workflows

The Future of Digital Trust

The next phase of digital identity will not be defined by one wallet alone. It will be defined by an ecosystem of wallets, issuers, verifiers, and authorization systems working together.

Wallets make identity proof portable. Verifiable credentials make it reusable. Authorization makes it actionable. In an agentic world, that combination becomes essential.

Learn how Curity turns trusted credentials and other forms of evidence into runtime access decisions.

Secure Backend Agents with Access Intelligence

Gary Archer — Tue, 05 May 2026 00:00:00 GMT

At Curity, we recently collaborated with the Azure Developer CLI (azd) team to produce an azd template hosted on the awesome-azd gallery. The repository’s goal is to demonstrate how enterprises should use authorization to implement AI initiatives safely.

The GitHub repository may initially seem a little complex, with deployment resources for both security and AI, as well as code examples that combine AI with token-based security. In this article, I provide some insights behind the implementation.

Enterprise Use Cases

The Microsoft Foundry provides a next generation enterprise-grade platform for AI. A common initial use case is for customers to operate their own resources using natural language commands. To get different results, customers simply issue a new command.

In such initiatives, authorization is a key requirement. Although customers can operate productively on their own data, mistakes by AI technology must never result in the customer gaining access to unauthorized data, like that of another user.

Developer Experience

From a development viewpoint, the Microsoft AI ecosystem provides productive tools for developers. Developers can use SDKs that enable external applications to integrate with Azure backend environments. The azd template uses C# code to demonstrate the following protocols, and the template could be adapted for other programming languages:

An external application uses the A2A protocol and the Microsoft A2A SDK to send a natural language command to a backend agent.
The backend agent uses the MCP protocol and the Microsoft MCP SDK to communicate with an MCP server.

Developers only need to write APIs and API clients, which they have been doing in their preferred language for years. Azure AI Foundry deals with the complexity of natural language processing (NLP). The authorization requirement should be met with the same experience.

AI Deployments

Azd templates include deployments, to spin up the backend infrastructure. The bigger picture that enterprises should consider is how such deployments will scale. You need a future plan to deploy multiple AI components, serve multiple clients and work with external organizations.

At the organizational level it is no different to how you already deploy APIs and applications. Typically, you externalize the management of these components from developers, and a platform engineering or DevOps team owns deployment and operational best practices.

The example azd template demonstrates uses layered provisioning to enable a clean separation between base infrastructure and the components developers deploy. It also uses an internal network, to enable the use of internal URLs and limit endpoints exposed to the internet.

Securing AI

The main enterprise concern with AI technology is that it can make mistakes, such as when processing complex text input from users. Malicious users may attempt to use tools that send dangerous commands, to cause backend API requests to try to access unauthorized data.

To mitigate authorization risks, APIs should use short-lived least-privilege OAuth 2.0 access tokens to authorize access to data. Agents should never be given permanent access to APIs, with mechanisms like API keys. When using short-lived access tokens, agents only gain short-lived access. Authentication and authorization must take place for internal endpoints as well as those exposed to the internet.

The azd template combines the use of Microsoft AI SDKs with OAuth security, to secure A2A and MCP endpoints. The example Portfolio MCP Server authorizes access to fictional stocks data and uses access token attributes like those shown here.

If you inspect the code, you will see that developers continue to get a straightforward experience. The Portfolio MCP Server, and any upstream APIs, can easily use the highlighted token attributes to implement authorization.

The access token is integrity protected so that no malicious party, such as an untrusted AI agent, can alter the token values. In this example, the agent can only gain read-only access to stocks and only for the customer and region in the access token. APIs reject any incorrect or malicious access by AI components.

Designing AI Security

Typically, the only work for development teams should be to use access tokens that an identity person designs. An identity person or team should design access tokens for each component. Development teams then receive easy-to-use, short-lived, least-privilege access tokens that enable the correct authorization.

Access Intelligence

Once you have a token-based setup, the details of tokens, and flows to get them, are important, to enable real-world AI use cases. For a first milestone, ensure that you can issue access tokens with any runtime attributes that your APIs need. For future milestones, plan to issue access tokens to secure real-world AI flows like those summarized here:

A user expresses an intent to an agent, such as conditions for a purchase. When those conditions are met, the agent triggers human approval. The agent then gets a high privilege access token and can complete its task.
Agents can collaborate across organizations. Your agent may need to call an agent from another organization, and pass on any security context. For that, it is likely to need advanced token exchange capabilities.

Using access intelligence to meet end-to-end requirements like these is the goal of the OAuth 2.0 authorization framework. The central component is the authorization server, which should act as a specialist token issuer. In the azd template, the Curity Identity Server implements this role and can do so without changing user account storage or login screens. In the azd template, Entra ID stores users and manages user authentication.

Try the Architecture

For many organizations, AI is no longer optional. Instead, it is a critical success factor. Limiting the use of AI can create a competitive disadvantage. Meanwhile, ungoverned deployments create unacceptable levels of risk. Access intelligence bridges that gap, so that you embrace AI with confidence, and security provides a competitive advantage.

To implement access intelligence, you need end-to-end security for users, applications, agents and APIs. The azd template demonstrates the setup and deployment of that architecture. The template separates concerns across 3 main roles:

An operational-focused person can study the deployment resources.
An Identity-focused person can study the use of tokens.
A development-focused person can study the application code.

You can download the Curity Identity Server from the Microsoft Market Place, or use the template to run it as containers in Azure. You remain within the Azure platform and can choose best-of-breed components from both managed services (like Foundry and Azure SQL) and cloud-native services (like your backend agents and the Curity Identity Server).

The Vercel Breach: A Failure of Identity, Not Code

Judith Kahrer — Fri, 24 Apr 2026 00:00:00 GMT

The Vercel breach epitomizes why zero-trust and governed OAuth are so vital for protecting today's software supply chain.

The recent Vercel breach surprised the engineering world. In April 2026, Vercel, a platform for deploying and hosting web applications, had its internal systems breached and sensitive customer data stolen.

The breach involved a compromised OAuth token, leaked API keys, and unauthorized access via an untrusted third-party SaaS application. It marks one of the most high-profile security incidents involving Vercel to date.

What's surprising is that the Vercel breach wasn't a code vulnerability at all. It was primarily an access and identity issue stemming from an insecure third-party integration. In other words, this was not a breach of infrastructure: It was a breach of identity boundaries.

While Curity was in no way affected, it's an unfortunate story we've witnessed multiple times, and one we feel strongly about given the strategies to prevent these sorts of exploits are readily available.

What Happened?

According to Vercel's statement issued on April 19th, the breach began with an OAuth integration. A Vercel employee connected Context.ai, a small third-party AI tool, to their Google account.

Eventually, Context.ai became compromised. Using this entry point, a hacker was able to access a Vercel employee’s Google Workspace account to gain unauthorized access to internal Vercel systems, which was then used to leak unencrypted secrets such as customer credentials and API keys.

Vercel now reports that these variables, including API keys, tokens, database credentials, signing keys, should all be considered as exposed. TechCrunch reports the hacker group is actively selling this information on the dark web.

What Could Have Prevented It?

It's easy to call foul in hindsight. However, this breach has many of the hallmarks of poor identity and access management, a lack of technology governance, and over-permissioning.

Not treating OAuth integrations as implicitly trusted Just because you set up an OAuth integration does not mean the external party should be trusted with long-lived access or many permissions. OAuth connections should be well-scoped with fine-grained access, and tokens should be cycled often. In the case of Vercel, doing so would have limited the blast radius significantly.

Context-dependent authentication mechanisms The bulk of API breaches occur via authenticated access, and this breach was no different. If access decisions had incorporated context, such as IP, device, or anomalous behavior, the lateral movement from the compromised OAuth session could have been flagged and prevented.

Better governance of third-party applications Compromised third-party SaaS can be highly damaging. Notably, Vercel's architecture allowed for a single employee to compromise the organization with a single third-party connection. If there were more oversight on tooling use, security teams could have caught the defects inherent in the external platform.

Safeguarding all credentials and API keys The onus is on customers as well. In this breach, the real risk for Vercel customers had to do with any credentials that were not encrypted using Vercel's "sensitive" feature. So, there is an argument to be made for using your platform's native security features.

AI Amplifies The Need For Zero-Trust

The Vercel breach is a classic case of shadow tech. An employee integrates a third-party application, likely without considering the security consequences of their actions, and the connection comes back to haunt them.

The compromise also highlights a weak chain in today's heterogeneous enterprise systems: Even valid, OAuth-compliant integrations can shelter malicious access to internal systems.

Responding to this reality will require a zero-trust approach, founded upon intelligent token-handling practices, and a careful identity and access management architecture bolstered by continuous verification.

Unfortunately, the string of supply chain attacks will likely continue. And as organizations increasingly connect third-party tools via OAuth, especially AI-driven assistants, the attack surface is expanding.

As such, a new form of Access Intelligence is required to cater to just-in-time access and real-time authorization decision-making in the age of non-human identities.

How Access Intelligence Helps

Access Intelligence has two important principles:

Access requests are evaluated at runtime.
Access tokens convey just enough privileges and just-in-time access.

By continuously evaluating access requests at runtime, it is possible to evaluate the context and any required data before granting access. It allows organizations to adapt the process such as enforcing additional factors or approvals when deemed required. The decision is then reflected in the access token that carries the minimum information in the form of scopes and claims for APIs to grant or deny a request.

Just-enough privileges and just-in-time access are key characteristics for access tokens to mitigate risks associated with token leakage or privilege escalation. Instead of giving an AI agent full permissions all the time, they only receive the permissions needed for the current task and as long as needed.

Just-in-time access removes standing privileges and expires any access after a given time period. Agents have to request new access tokens which restarts the evaluation and issuing process. The result is a re-evaluated set of permissions ensuring an AI agent can only access what’s needed, for as long as necessary, which limits what a rogue agent or attacker can do with the access token.

The Takeaway: Continuously Protect All Integrations

The Vercel hack is a wake up call for how brittle the modern software supply chain actually is. These sorts of sophisticated, targeted supply chain attacks continue to occur, and they can have a very broad exposure field.

Given that today's enterprise landscape is so highly interconnected and reliant upon API-based connections, a breach within a single external dependency can have a cascading effect across many internal components. Access Intelligence limits the impact by continuously evaluating access and by only granting what’s needed for a given purpose in the first place.

Just because you add an application via OAuth doesn't mean it's secure. OAuth must be governed with the proper scopes, token lifetime, and trust decisions to protect its use. Modern enterprises should treat all their connections and integrations with the care and rigor they deserve.

Preventing these sorts of breaches and customer leakages will hinge on treating every integration as untrusted by default, and continuously verifying access.

Token Intelligence: Why IAM Needs a New Mental Model

Judith Kahrer — Wed, 08 Apr 2026 00:00:00 GMT

Identity and Access Management (IAM) is undergoing a significant transformation. Modern use cases demand more - more identities, more complexity, more speed, and far more dynamic behavior than traditional IAM was designed for. Meeting those demands requires a mindshift in IAM from static rules based on user permissions to dynamic rules with a holistic view that includes both human and non-human identities.

To meet these demands, IAM needs a new mental model—one that moves beyond static, user-centric permissions toward context-aware, dynamic authorization.

Why User-Centric IAM Falls Short in Modern API Architectures

Most IAM systems are built around a simple question: “Is this user allowed to perform this action?”.

This model works well in controlled environments where the main challenge is human user login.In modern architectures, authorizing solely on user permissions neglects an important detail, though: users never perform requests on their own.

Technically, it's always an application that makes requests on behalf of a user. In fact, some applications do not even operate in an end-user context. So when authorization decisions are based only on user permissions, an important part of the picture is missing. The system has no way of understanding how a request is made or whether it is expected in that context.

Users never perform requests on their own - they always depend on applications to perform requests, present data, and interact with data.

type: embedded-entry-inline id: 1JMHDGbugJHOcnEDn3FeCq

Application-Centric IAM: A Better Model for APIs and AI

A more accurate way to think about IAM is to start with the application.

Applications exist to fulfill a purpose. They interact with APIs—some act on behalf of users, others operate independently. Treating all requests as if they come directly from a user flattens this difference.

The application-centric approach decouples the permissions applications have from the permissions a user has. It lets you define rules where one application may act on behalf of a user in one way and another application in another way. Many companies realize just now that this mindset is extremely useful for emerging use cases such as AI and automation where actions are delegated and context changes continuously.

What APIs Need: Context for Authorization

Ultimately, applications access data from backend systems (APIs). The important questions to answer are:

whether the application is allowed (expected) to send certain requests (access certain data), and
whether the API should allow the request (release data) given the current circumstances.

To be able to enforce authorization rules, the backend systems (APIs) need information, some context - called claims. APIs may need a user identity to authorize a request. They may also need an application identity or other data. Ultimately, what information they need depends on the rules.

To securely grant access to the assets, APIs need data - data that gives them the power to evaluate whether, according to their rules, it is safe to allow a request in the current context.

The Curity Token Intelligence: Turning Context into Authorization Decisions

This is where Curity’s Token Intelligence comes in. Instead of being simple credentials, they become carriers of context providing APIs with the information needed to make access decisions based on real-world conditions. This enables a more dynamic and precise form of authorizations, supporting least privilege access and easily adapting to changing scenarios.

The Curity Identity Server enables you to define permissions for applications (based on their expected behavior) and to provide data (claims) that help the backend system to perform authorization. This approach makes it, for example, comparably easy to support AI use cases with the Curity Identity Server. AI use cases require just-in-time, least-privilege access, which you can convey via access tokens. As mentioned before, this approach also implies a mental model that is fundamentally different from the mental model of other vendors.

The Curity Identity Server utilizes a mental model that enables the enforcement of challenging authorization rules, including AI use cases, with the help of specialized access tokens.

Curity acknowledges that authentication and authorization are very specific to a context. Consequently, the Curity Identity Server is highly customizable both in terms of user authentication and the authorization details that it can provide to the backend system via access tokens. The latter is what we refer to as "Token Intelligence", a part of Access Intelligence.

Beyond Login: Building Secure Authorization with the Curity Identity Server

Jonas Iggbom — Thu, 19 Mar 2026 00:00:00 GMT

In modern API-driven systems, authentication is only the starting point. Simply logging a user in is no longer enough. Organizations need to control how APIs are accessed, how microservices communicate, how tokens are protected, and how permissions are enforced across distributed environments.

Real-world authorization is rarely simple. It requires precision, flexibility, and strong security guarantees.

The Curity Identity Server is designed to address this broader challenge. It goes beyond authentication to provide a solid, standards-based foundation for secure authorization across modern API and application ecosystems.

Supporting Real Authorization Complexity

Modern authorization isn’t just about checking whether someone is logged in. In distributed systems, access decisions often depend on multiple factors, such as:

User roles and attributes
Resource ownership
Tenant boundaries
Device context
Risk signals
Service-to-service communication

APIs frequently need fine-grained, resource-level permissions. At the same time, microservices should only receive the minimum access they need when calling each other. In regulated industries, there may also be requirements for strong client authentication, auditing, and real-time policy enforcement.

As organizations adopt zero-trust principles and multi-cloud architectures, authorization must become more adaptive and context-aware. Static, role-only checks are no longer enough.

So, can the Curity Identity Server handle this level of complexity?

At its core, Curity is a fully standards-compliant OAuth 2.0 authorization server and OpenID Connect provider. It issues access tokens and ID tokens that can include custom claims configured through token procedures and claims mapping, such as roles, groups, tenant identifiers, and other business-specific attributes.

This enables fine-grained access control. APIs and gateways can evaluate not just whether a user is authenticated but also what they are allowed to do, which resources they can access, and under what conditions. Instead of relying solely on coarse role checks, organizations can move toward attribute-based access control (ABAC) and enforce least-privilege policies across APIs and services.

For even more advanced scenarios, Curity integrates seamlessly with external policy engines like Open Policy Agent (OPA), Cerbos, or any AuthZen-enabled Policy Decision Point (PDP). In these setups, the Curity platform handles authentication and token issuance, while the policy engine evaluates context-aware rules at runtime. This clear separation of responsibilities supports scalable, policy-driven authorization in multi-tenant, regulated, or zero-trust environments.

But secure authorization is not only about architecture. OAuth and OpenID Connect also need to be configured correctly, and small mistakes can easily introduce vulnerabilities.

Preventing OAuth and OpenID Connect Misconfiguration

OAuth 2.0 and OpenID Connect are powerful and flexible frameworks. But that flexibility can also introduce risk. Because they support multiple flows, client types, and token handling patterns, insecure configurations can easily occur.

Common mistakes include:

Using the wrong grant type for a client (for example, enabling implicit flow instead of authorization code with PKCE)
Failing to strictly validate redirect URIs
Allowing overly broad scopes
Issuing long-lived tokens
Not clearly separating public and confidential clients
Storing tokens insecurely in front-end applications

Misconfigurations can also occur on the API side. Services may skip signature verification, accept tokens meant for another audience, or fail to validate expiration and issuer claims. In distributed systems, inconsistent validation across gateways and services can significantly increase risk.

The Curity Identity Server helps reduce these risks by enforcing strict standards compliance and secure-by-default configurations. It supports PKCE, strong redirect URI validation, and clear separation between public and confidential clients. By guiding teams toward recommended flows and secure token handling practices, it lowers the likelihood of common implementation mistakes that can lead to vulnerabilities.

Securing Tokens Throughout Their Lifecycle

Token security does not stop at issuance. It covers the entire lifecycle: how tokens are created, protected, validated, refreshed, and revoked.

Security starts at issuance. Tokens should be cryptographically signed to guarantee integrity and, when necessary, encrypted to protect sensitive claims. They must include correct audience, issuer, and expiration claims so that receiving services can validate them properly.

Token lifecycle management balances security and usability. Short-lived access tokens reduce exposure if a token is leaked. Refresh tokens allow users to maintain sessions securely without frequent reauthentication. Techniques like refresh token rotation help detect and limit replay attempts.

Revocation and introspection mechanisms are also essential. They make it possible to invalidate tokens before they expire—for example, after a credential compromise or logout. In distributed systems, consistent validation across gateways and services ensures that expired or revoked tokens are not accepted.

Token Security and Lifecycle Management in the Curity Identity Server

The Curity Identity Server manages tokens securely from creation to expiration. Tokens are signed and can be encrypted when required. Token lifetimes are configurable to strike the right balance between usability and risk. Refresh token rotation helps mitigate replay threats, and revocation and introspection endpoints provide real-time control when tokens must be invalidated.

Curity’s identity server also supports standards-based capabilities such as token exchange, enabling controlled delegation and on-behalf-of scenarios in service-to-service communication. This allows services to obtain tokens appropriate for calling downstream systems, helping enforce least-privilege principles and reduce the impact if a token is compromised.

Reducing Token Leakage and Replay Risks

Access and refresh tokens are typically bearer credentials. That means anyone who possesses a valid token may be able to use it until it expires. If tokens are exposed, they can be misused.

Leakage can happen in several ways:

Insecure storage in browsers
Logging tokens in application logs
Sending tokens over unencrypted channels
Misconfigured CORS policies
Exposing tokens in front-end code
Passing tokens between services without proper scoping
Accidental check-in to the code repository

Replay attacks occur when an attacker intercepts a token and reuses it to access an API or impersonate a legitimate client. Long-lived tokens and a lack of sender constraints make this easier.

Protecting Against Token Leakage and Replay Attacks

The Curity Identity Server addresses these risks with sender-constrained tokens, including mutual TLS (mTLS) and DPoP. These mechanisms bind tokens to a specific client or cryptographic key, making intercepted tokens useless to attackers.

In addition, the Curity Identity Server supports secure architectural patterns such as short-lived access tokens, the Phantom Token Pattern, and the Split Token Pattern. These approaches ensure that front-end applications only receive opaque reference tokens, keeping JWTs containing sensitive user data (PII) out of public-facing contexts. This while guaranteeing that internal APIs receive properly validated, cryptographically verifiable tokens.

These capabilities allow organizations to implement secure authorization without building complex token and policy infrastructure from scratch.

Beyond Login

Modern authorization requires more than verifying identity. It demands enforceable policies, secure token handling, runtime decision-making, and alignment with zero-trust principles.

The Curity Identity Server provides these capabilities within a standards-based, API-first architecture. By combining fine-grained access control, strong token protection, and rigorous protocol compliance, it helps organizations move beyond login and implement real-world authorization across modern API architectures.

API Security: Common Misunderstandings for Business Teams

Stefan Nilsson — Tue, 17 Feb 2026 00:00:00 GMT

APIs sit at the center of most digital services today. They connect organizations to partners, support mobile apps, and enable new products to reach users faster. Gone are the days when APIs could be thought of as a technical detail in the background. They are, and should be, an essential part of how the business operates and grows.

For enterprises with complex infrastructures, APIs are also the primary way to manage that complexity. They make it possible to connect teams, systems, and partners without slowing everything down. In that sense, APIs are not just part of the platform, they are a key business enabler.

Despite this, API security is still very often treated as a purely technical concern, something to be handled by infrastructure teams or added once an API is already live. In reality, how access to APIs is designed and enforced directly affects business risk, customer trust, and the ability of the organization to move quickly.

One part of the problem is that many discussions about API security focus on tools and protocols, rather than on what actually matters to the organization. For example: who is allowed to access which services, under what conditions, and what happens when those assumptions turn out to be wrong?

Here, we’ll look at some of the most common misunderstandings about API security and why they frequently lead to problems later. The goal is not to turn business teams into security experts, but to clarify why API security deserves earlier and wider attention than it often gets.

Misunderstanding 1: APIs Are Internal so They’re Low Risk

It’s not unusual for APIs to be labelled as “internal” and assumed to be safe by default. If end users cannot see them, the risk feels limited. In fact, most APIs are accessed by many systems beyond a single team or application. Mobile apps, cloud services, partners and other B2B integrations, as well as automated processes all rely on them. That means these APIs are exposed, even if they are not public.

The thing to remember is that the risk is not about whether an API is meant to be internal but about how many systems can reach it, and what they are allowed to do once they do.

When APIs are treated as low risk, access rules are often unclear or inconsistent. Over time, this creates blind spots that only surface when something goes wrong, often at the cost of trust, time - or both. By ensuring that all APIs, including internal ones, have authentication and authorization controls implemented, you're sure the API is protected against threats from within your organization also.

Why this matters: Treating internal APIs as low risk leads to vague access decisions that are hard to audit, explain, or correct once systems scale.

Misunderstanding 2: API Security is Just about Blocking Traffic

Another misconception is that API security is just about stopping bad requests. Firewalls, gateways, and rate limits become the main focus, with the assumption that blocking enough traffic equals security.

Blocking bad traffic is important but not enough because the approach misses a key question: who or what is calling the API, and why. Many API requests are valid on the surface but inappropriate in context. This fact becomes more prominent as APIs are increasingly used by automated workflows and AI-driven agents that act independently, trigger actions across systems, and call APIs without a human-in-the-loop. Without clear access rules, systems cannot reliably tell the difference between good or bad requests.

This is where identity becomes central, not as a one-time login, but as something that needs to be evaluated every time an API is used.

From a business point of view, blocking traffic without considering identity in the decisions leads to either over-blocking, which slows things down, or under-protecting, which creates risk. Neither supports reliable growth nor good user experiences.

Why this matters: Without identity-aware access decisions, organizations either restrict legitimate use or fail to prevent misuse, weakening trust and agility.

Misunderstanding 3: OAuth and Tokens are Implementation Details

Standards like OAuth are often seen as something technical teams deal with after the real access decisions have already been made. In practice, tokens shape how access works across products, partners, and services. Tokens are not just credentials; they carry the information that APIs use to make access decisions. When designed and issued intelligently, they can reflect context, roles, and risk. When treated as static values, they limit how precisely access can be controlled.

When access security choices are made late, teams end up working around them. That usually shows up as friction for users, complex integrations for partners, or limitations that are hard to change later.

OAuth and token design directly shape partner integration speed, user experience, and the cost of change over time.

What looks like a technical detail early on often turns into a business constraint further down the line.

Why this matters: Treating OAuth as an afterthought locks organizations into access models that are expensive and risky to change once APIs are in use.

Misunderstanding 4: Security Can Be Added Later

API security is frequently postponed in the name of speed, with the plan to launch first and tighten controls once things are proven.

The problem is that access decisions tend to spread quickly. Once APIs are in use, changing how they are secured becomes much harder and a lot more expensive. Your team may be forced to balance fixes against existing integrations and expectations.

Addressing API security earlier in the process avoids rework and makes it easier to scale with confidence, rather than constantly reacting to risk. APIs are particularly vulnerable now with the rise of AI agents, where an attacker doesn’t necessarily need a major flaw, only weak enforcement.

Why this matters: Access decisions made under time pressure often become long-term constraints that slow growth instead of enabling it.

How Curity Supports API-First Access

At Curity, we work with teams that are building and operating APIs at scale, often across complex environments with many moving parts. A common challenge is that access decisions end up scattered across gateways, applications, and custom logic, making them hard to reason about and even harder to change.

Curity helps bring those decisions together at the API layer. Instead of relying on static rules or perimeter controls, teams can evaluate access based on who or what is calling an API and under what conditions, every time that API is used.

This becomes especially important as APIs are increasingly used by partners, automated workflows, and AI-driven agents that act without a human-in-the-loop. This kind of token intelligence becomes especially important as APIs are used more heavily by automated workflows and AI-driven systems. The Curity Identity Server makes it possible to handle these cases consistently, separating authentication from authorization and applying policies across APIs as systems and usage evolve.

The result is an API-first approach to identity and access that supports growth without adding friction. Teams can move faster, adapt more easily, and keep control as their platforms and integrations expand.

type: embedded-entry-inline id: 4OkIjj3zonCbmy3rr9GUqg

How to Think About API Security

API security works best when it is built into how digital services are designed, not as a control added at the end. The most common problems tend to arise when access decisions are assumed to be simple, static, or someone else’s responsibility.

The goal is not for business teams to master technical details, but to recognise where and how identity and access choices affect outcomes. APIs determine how systems interact, how partners integrate, and how trust is maintained at scale. In that sense, trust is not just protected by security controls, but designed through the access decisions applications make every day.

When identity and access are considered early and applied consistently at the API level, teams are more likely to grow without constantly revisiting decisions made under pressure. That shift in thinking is often the difference between security that slows the business down and security that supports it. For organizations building API-first platforms, that difference directly impacts how quickly they can adapt, integrate, and compete.

In summary, API security is less about individual controls and more about how access decisions are designed and maintained over time:

APIs are where access decisions actually happen
API security is about identity and authorization, not just blocking traffic
OAuth and tokens are business infrastructure, not implementation details
Access decisions made late are costly and difficult to change
Designing API security early enables growth without constant rework.

Learn how Curity helps teams design and enforce strong API access from the start.

API Security Trends 2026

Judith Kahrer — Tue, 16 Dec 2025 00:00:00 GMT

Looking back at Nordic API’s Platform Summit that took place last October, 2025 was the year of AI and MCP. Both will remain hot topics to a great extent even in 2026, and they already bring some good changes as they are forcing organizations to rethink their IAM strategies, alter their frames of mind, and improve security.

AI will continue to drive IAM in 2026. I'm convinced that its impact on authorization will be long-lasting. With that in mind, I believe 2026 holds some exciting trends worth watching.

Machine Identities Will Take Center Stage

In the context of AI and autonomous applications, it will become increasingly important to authenticate and authorize machines, AI agents, and their human operators, if any. Consequently, machine IAM will get quite some attention in 2026. Questions like how to trust arbitrary applications whose code organizations can't control, how to onboard them, and how to authorize requests will be hot topics.

Simply strengthening machine identities will not be enough. AI demands speed and dynamics in authorization decisions - particularly for applications. Authorization will need to be fast and secure.

Access Control Will Concentrate on Speed

Conventional Privileged Access Management (PAM) and Identity Governance and Administration (IGA) solutions struggle to meet modern requirements for provisioning access for machines or applications in a timely manner. IAM simply cannot rely anymore on processes with manual steps and approvals, where it may take weeks to onboard applications and provision access. Autonomous applications require autonomous decisions.

Admin-time authorization will need to focus on setting up the trust and defining the rules for how to retrieve permissions for applications and users dynamically during runtime. Runtime authorization will need to continuously evaluate permissions.

Permissions can change quickly depending on events at other parts of a system architecture. Therefore, analysing and sharing data and signals between components will be important for the success of IAM. This is a great chance for the adoption of certain standards.

OAuth Integrations Will Mature

Along with the focus on machine identities, more organizations will start to strengthen OAuth client credentials. More organizations will utilize their infrastructure, such as workload identities for client authentication. However, as with usernames and passwords for humans, it will take decades to get rid of client secrets or their equivalent to authenticate applications. At least, 2026 will spark off some initiatives in the right direction. With MCP dictating an OAuth profile, organizations will become more aware of the best practices. In 2026, OAuth integrations will improve beyond strong client credentials: More organizations will make use of token exchange for least privileged access and of the JWT-assertion-grant protocol to cross security boundaries. How to enable Single Sign-On for users across trust domains and federate authorization without compromising security is one of the challenges to solve in 2026.

While AI and the resulting requirements will dominate IAM to a great extent, some regulations, namely eIDAS and PSD3, will also have an impact during 2026.

Verifiable Credentials Will Begin to Shine

There is quite some work happening in the European Union for the rollout of Verifiable Credentials and a European Identity Wallet. As the deadline is getting closer and the results get more and more reliable in 2026, organizations that are far-sighted will prepare for the change. Verifiable Credentials enable a new, convenient, and cheap method for identity verification and authentication for a large part of the population in Europe. 2026 is the year when things will start to feel real.

Open Finance Will Disrupt the Finance Sector

As with PSD2, which created quite some excitement and anxiety in the banking sector, PSD3, PSR, and FIDA will have a similar impact on more actors in the financial industry. It's likely that the regulations will be finalized during the first half of 2026. So, 2026 is the time to have a closer look and prepare for the impact. The regulations promise more harmonization and stronger customer protection. Among other things, PSD3 strengthens Strong Customer Authentication (SCA). For example, SCA implementations also need to be accessible to all users, including people with disabilities, elderly people, or people with less technical skills. Sounds good and human in my opinion.

Weak API Security Will Continue

Companies will continue to make mistakes because there will still be gaps in the understanding between infrastructure teams, application developers, API developers, and the business. Such misunderstandings, together with other implementation flaws, represent the main threat to API access control. The increase in automated API attacks that target broken authorization adds to the risk. Consequently, broken authorization is the area where most exploits will occur.

Organizations need to proactively improve their API security implementations to avoid broken authorizations from the beginning. The ability to communicate and convey business requirements, and translate them into technical implementations while providing seamless user experience (including developer experience) and keeping up with security will remain important for the success of an IAM program.

Refine Your API Security in 2026

IAM for APIs and API clients remains a complex topic. In fact, the trend is towards more complexity, which requires more sophisticated building blocks such as non-human identities. The best practices for API access control and AI agents are going to be more relevant than ever in 2026. I believe that the new year will bring some exciting improvements regarding IAM. Who knows, maybe 2026 is the year that will rewrite the list of top API vulnerabilities and contain fewer authorization problems?!

Identity and Access Management for AI Agents

Judith Kahrer — Thu, 27 Nov 2025 00:00:00 GMT

Many companies are starting to experiment with AI agents to automate tasks or support users, but these agents don’t behave like the applications we’re used to securing. They make their own decisions, adjust their actions as they go, and interact with systems in ways that aren’t always predictable. That shift exposes gaps in today’s machine identity and access controls. Before getting into the details, it helps to look at why these agents challenge some of the assumptions in traditional IAM.

The Characteristics of AI Agents

AI agents use advanced algorithms to determine the steps needed to solve a task. They not only use algorithms to resolve required steps dynamically but also feed back results to improve the execution of the algorithms. This allows AI agents to dynamically adapt their behavior, making their execution indeterministic and unpredictable.

AI agents are software systems with the ability to operate autonomously or semi-autonomously, often on behalf of a user, in an indeterministic manner.

The interdeterministic characteristic of AI agents stands in contrast to conventional software, where the steps to solve a task are predefined and execution is deterministic. This contrast highlights a fundamental change in how applications operate. It implies that the assumptions on which many security solutions were built have changed as well.

Authorization Premises Are Changing

Historically, the focus of IAM has been authentication and authorization of human users. The adoption of multi-factor authentication, passwordless login methods, together with identity governance and administration (IGA) processes to, for example, approve access requests for humans serves as proof. IAM for applications (machine IAM) did not follow a comparable evolution.

With applications being indeterministic and issuing unpredictable requests on behalf of users, being able to perform authorization on the correct premises becomes more prevalent. Static entitlement mappings for service accounts are not enough to meet the requirements of the new dynamic in applications. Instead, the identity and entitlements of applications need to play a greater part in access control decisions.

What really becomes important when protecting access to data from AI agents is identity governance and administration for applications. IGA for applications implies that there are processes and tools that allow organizations to assign and enforce access rights for machines which include AI agents. This requires setting up (machine) identities for AI agents.

Identities for AI Agents

AI agents are applications and, as such, fall under the umbrella of machine IAM. The industry has identified that the dynamic characteristics of AI agents require similar approaches for access control to what is typically in place for human users. However, this does not mean that AI agents are human users and should be treated as such. Mixing human and machine identities creates ambiguity that is hard to maintain. Instead, AI agents remain machines and should use existing means of machine identities.

Common forms of machine identities are:

Service accounts + secrets
API keys
JWT-based workload credentials
X509 (client) certificates

As with usernames and passwords for human users, symmetric credentials for applications like secrets and API keys pose security risks. Therefore, whenever possible, use application credentials that are based on asymmetric cryptography, such as JWT-based credentials and X509 certificates. Prefer authentication mechanisms that use key-bound credentials and require a proof-of-control of a private key like X509 certificates with mutual TLS (mTLS). Mutual TLS has been around for many years and is widely supported by various tools in a technology stack.

Since AI agents are applications, you can assign identities as you do for other applications and learn from best practices. For example, for a self-hosted AI agent on the backend, consider workload identities. For public agents, consider self-assigned identities using mechanisms like dynamic client registration, which is a common approach for mobile applications.

An argument for treating AI agents differently than other applications is delegation, the fact that they (autonomously) act on behalf of a user. Any user-facing application performs delegation, actually, and batch applications also run autonomously - sometimes with user identity involved. There are already well-established protocols that solve user delegation to applications: OAuth and OpenID Connect. Apply them to AI agents!

type: embedded-entry-inline id: 1b8tmuqgKjdhIsNbS0uX8w

(O)Authorization for AI Agents

The fact that AI agents perform automatic, unpredictable tasks on behalf of users does not mean they need dedicated identities or authentication mechanisms. AI agents are still OAuth clients like other applications. Consequently, the challenges that arise from onboarding public clients are not specific to (public) AI agents and remain similar across various applications. The challenges have just become more prevalent.

In the context of OAuth, AI agents are simply OAuth clients.

Theoretically, AI agents can run the same OAuth flows to retrieve access tokens like other applications. However, you need to adapt how you enforce access control rules for AI agents and applications in general. For example, with AI agents performing unpredictable tasks, it becomes important to keep a human in the loop, such as triggering approval requests where appropriate before granting access. These kinds of processes are typically part of identity governance and administration.

Identity governance and administration for applications means focusing on which application can access what under which circumstances, independently of the operating user. Part of that logic already resides in an application-centric identity server, an authorization server like the Curity Identity Server, that maintains a list of all (registered) OAuth clients and scopes they are allowed to request.

In the long run, and to enforce global policies, APIs and any other policy enforcement points should support integration with external access management systems that maintain access policies and can return access control decisions in real time. In that way, access control decisions can take into account many data points across a system and time. This enables risk-based access control decisions that address the challenges from AI agents.

Reducing AI Security Anxiety

AI agents and any other indeterministic applications change certain premises with regard to API access control. However, while AI agents may significantly change how we interact with machines, they do not rescind the foundations of API access control. OAuth was designed for delegation and continues to be the tool of choice for that purpose. In that context, AI agents are simply OAuth clients.

What you need to update are access control rules beyond OAuth integrations and the enforcement of those rules. This includes identity governance and administration for applications, and OAuth is part of it.

The following capabilities are the new basic requirements for API access controls. You need to

design access control rules targeting applications,
be able to identify and optionally authenticate clients,
add relevant identity information in access tokens and
integrate with external authorization systems to dynamically enforce policies.

There is no need for agentic identities, no magic, just robust API access control with an emphasis on identity governance and administration for applications.

Learn more about how Curity can help you to secure IAM in the age of AI.

And make sure to attend a live webinar - MCP and AI Agents: Identity Strategies for Safe API Access - on December 4. Learn more and register.

Guarding Against AI-Agent Attacks: A Cautionary Tale from a Recent Incident

Jacob Ideskog — Mon, 17 Nov 2025 00:00:00 GMT

In the wake of a recent cyber incident described by Anthropic involving an army of AI agents, we’ve witnessed a striking example of how attackers can leverage artificial intelligence to exploit weaknesses and gain access at a scale and velocity impossible before. AI agents were able to systematically extract and steal large volumes of sensitive data, running tasks in Claude Code that would be tedious and time-consuming (and therefore somewhat easier to spot) for human operators. The Claude agents had been granted enough leeway to operate for quite a while before anyone realized what was going on.

This is not just a cautionary tale for AI focused enterprises; it’s a wake-up call for everyone exposing APIs and digital services.

In that incident, an army of AI-driven agents orchestrated a sophisticated attack, taking advantage of whatever access they could gain. While the specifics in that case didn’t revolve solely around APIs , the broader principle remains universal: any exposed surface, especially APIs, becomes a prime target for malicious agents.

APIs are particularly vulnerable here because AI agents excel at rapid, repetitive, and incremental probing. If privilege boundaries are too broad or too static, an attacker doesn’t need a major flaw, only weak enforcement.

What could make a difference? By enforcing the use of OAuth to acquire fresh tokens with expanded privileges only when truly needed, you introduce checkpoints that require every meaningful access request to be justified. If your APIs have stricter access models, for example, more granular rules on what constitutes reasonable access, how often data can be requested, and when elevated privileges are required, then the whole scenario could be different.

In practice, this means leveraging mechanisms like human-in-the-loop approval or policy enforcement engines to evaluate whether a particular request for access is legitimate. How often has this agent asked for data? Is this frequency normal? Is it even allowed? Additionally, you can forward signals from your token issuance system to other systems, like risk engines, that can analyze usage patterns and help detect anomalies early. By doing this, you stand a better chance not just of spotting attacks in progress, but potentially mitigating them before they cause significant harm.

Ultimately, as we expose more APIs, and in particular more AI-friendly APIs, we need to think ahead. Monitoring traffic alone will not suffice. Having a ubiquitous and robust privilege management system, like the one Curity provides, helps you catch these signals and respond more swiftly to threats and risks.

Takeaways From the 2025 Nordic APIs Platform Summit

Michal Trojanowski — Thu, 06 Nov 2025 00:00:00 GMT

I’ve attended Nordic APIs’Platform Summit a few times, even before my time at Curity, but this year felt a bit different. It was still the same time and place — mid-fall in Stockholm in the halls of hotel Clarion, which offers unique views of the city (for those of you who haven’t been there, or maybe did not notice: the hotel is built on top of an entry to a highway tunnel and offers a nice view of the disappearing road and a part of the Stockholm archipelago).

To me, two reasons made this year’s experience exceptional:

The conference was accompanied by a half-day unconference focusing on API security.
You could not hide from hearing about the new cool kid on the block — Model Context Protocol (MCP).

The API Security Unconference

An unconference is a great platform for exchanging experiences, sharing knowledge, and learning. Unlike a “regular” conference, an unconference has no designated speakers — everyone is an attendee — and there is no fixed agenda; the attendees choose the topics they want to discuss during the day. In my opinion, this worked really well. We managed to get some good discussions, where people actively shared their experiences or challenges.

Some conversations did not reach any specific conclusions, but they allowed us to confirm that all the participants deal with similar issues and have similar reservations — this in itself can be reassuring, even if it is not immediately helpful. But there were also sessions that allowed people to learn a lot. For example, we had a very good discussion on API authorization patterns. The person who started it wanted to learn about modern, scalable approaches to API authorization and got exactly that — there were attendees who work with the OpenID Foundation on the AuthZen project, who were able to share their knowledge and present different approaches.

The unconference was a great place to network — it made it easy to meet new people and have great discussions. I recommend trying this format to anyone who finds hallway discussions at conferences an important part of the experience. I’m really glad that Nordic APIs has already announced that there will be another edition next year.

Platform Summit

The conference itself stuck to its well-established format with opening and closing keynotes and breakout sessions in one-hour-long blocks. Each block ended with a joint Q&A which acted as a mini-panel with speakers from the block’s talks. The 20-minute limit for a single talk is enough to get the most important information distilled.

And it turns out that 20 minutes were enough to squeeze MCP into almost every talk, even if not directly mentioned in the title. Apparently, people were placing bets on whether they would manage to attend a talk in which MCP was not mentioned. I don’t know if that really happened, but I know I have been to a few talks that didn’t mention MCP.

Model Context Protocol Taking the API World By Storm

I have never seen a technology or specification become such a buzz like MCP this year. Even in the early days of GraphQL, people were talking a lot about it, but it wasn’t as ubiquitous as MCP currently is. And MCP is just one year old! To illustrate what I mean — MCP was covered so much, that I felt sorry for my listeners that I added an “MCP explainer” slide to my talk, which was in the afternoon of the second day.

I think the reason for this is that MCP can affect APIs from so many different angles:

An MCP server is an API in itself, protected by OAuth, and you can focus on the security of its connection to the MCP client.
You can focus on the authorization requirements of APIs that will be consumed by MCP servers’ tools.
You can focus on how to design and document your APIs so that they can be more easily consumed by MCP servers.
You can view all the above topics from two perspectives — external customers and enterprise (workforce). Both of them have different challenges and available solutions.
You can talk about how MCP servers can help you with the design, development, testing, or management of APIs.

Even though MCP dominated the discourse, it wasn’t the only thing people presented at the conference.

API Security is as Important as Ever

API security is still a popular topic. It is good, as it proves that we understand its importance. On the other hand, it also shows that we need to continue talking about it to get even more people to think about security first (and get authorization issues off the top of the OWASP list).

I always enjoy security talks, as they allow me to expand, or at least consolidate, my knowledge. Being physically at the talk also allows me to better concentrate on the content, unlike reading an article online.

I especially enjoyed a talk by Roger Bergling on hacking APIs, where he showed a number of tools useful for checking the resilience of your APIs. It was both enjoyable and disturbing to see that it takes seconds to crack a JWT signed with a weak symmetric key. This is exactly why at Curity we have been discouraging people from symmetrically signing JWTs for a long time now.

Platform Summit as a Technology Radar

Another reason I like conferences is that you can learn a lot. Of course, I try to follow trends and news around APIs and API security, but sometimes things slip under the radar. And, also quite obviously, I can’t just sit in front of a web search engine and start to search for the things I don’t know. After every conference I go to, I come back with a list of at least a few technologies or specifications and usually around a dozen tools or vendors I want to check out.

Here are the things that caught my interest at the Platform Summit that I’d like to learn more about:

Fuzzy testing of APIs, which means using algorithms to automatically generate tests that try to break your APIs in creative ways.
Event Destinations specification, which tries to enhance interoperability in event-driven systems.
I first learned about TypeSpec in 2024, and it was nice to see more talks about it this year, even though I still confuse the name with TypeScript… I hope to try it out with the next API I will design.
I already mentioned the talk about hacking APIs, and it mentioned a lot of tools I hope to play around with.
SAFE-MCP, a security analysis framework for MCP.

Learning From Real-Life Experiences

I mentioned how the unconference is a great place to learn from others’ experiences, but of course, the “regular” conference had no shortage of educational talks. It’s always appreciated when speakers share their journey, so you can either find guidance in how you should approach a similar problem, or what to avoid. This might be why I kept hearing in hallway conversations that one of the most interesting talks at the conference was about an API governance journey in a very large and old insurance company.

Sometimes, the thing you learn might not even be the main topic of the session. For me, the most interesting part of the talk on combining Webhooks and REST, was learning about the architecture of a mostly air-gapped system that runs on an airplane to process sales. How it uses an onboard web server to host a website for passengers, and connects to point-of-sale terminals. It was interesting to hear about some other architecture than a simple web server exposed on the internet.

Conclusion

I enjoyed this year’s Platform Summit a lot, and I’m really glad that Nordic APIs has already announced the dates for next year: 12-14 October 2026. I hope I will be able to join both the unconference and the main event.

I am curious to see how MCP will evolve and how the worlds of AI and APIs will work together. At Curity, we have been working with it a lot recently. This is why we have just set up a dedicated AI Lab, where we will develop AI agents and reference API architectures that can interact safely with them, either via MCP, or any protocol that emerges. Keep an eye on our blog and website, as we will share our insights as we progress.

If you are curious about this year’s Platform Summit talks, or you have been there and want to refresh or share some with your colleagues, then head down to the Nordic APIs YouTube channel. You will find this year’s recordings there soon, but you can already enjoy all the sessions from previous years.

From Screws to Software: The Power of Standards

Michal Trojanowski — Tue, 07 Oct 2025 00:00:00 GMT

We are surrounded by standards, even if we don't realize it. A lot of different things, from cars and home appliances to electrical grids, screws and paper sheet sizes, are standardized. Standards make our life safer and allow for interoperability. For example, when you buy a screwdriver, you don't have to worry too much about which manufacturer produced the screws or whether the tool will fit.

The situation is similar with software. There are plenty of standards that regulate many aspects of software, like architecture, security features, data structures, flows, and interfaces. Some are created by professional standardization bodies like IETF, CNCF, or OpenID Foundation. Others, like the recent Model Context Protocol, are maintained by communities of dedicated practitioners.

The origin of the standard is not the most important factor. What matters is if it becomes widely adopted. Some standards are initially created by companies or communities, but once they gain popularity, they are taken over by professional bodies.

This ensures quality and proper support for the standard. However, even though we have some popular and well-established standards in the IT ecosystem, I still meet people who are reluctant to follow them. I think there are two main reasons for this reluctance:

perceived implementation difficulty
illusion of vulnerability

Myth: Standards Are Hard To Implement

People sometimes look at a standard and think it is overcomplicated and hard to implement. While I'm not saying this is never the case (we developers sometimes have this innate ability to over-engineer), I think that more often than not, it is just a feeling.

For example, look at OAuth 2.0 and its authorization code flow. I had conversations about why the flow is so complicated, why the authorization server returns a temporary code instead of tokens, and how it only complicates things.

In this case, the standard’s authors made design decisions to introduce better protections for the flow — the additional request to get tokens is there to better protect them. And when you distill the flow, it turns out that its implementation is pretty straightforward — an OAuth client needs to send a POST request, be able to receive a GET request (the authorization server's response sent through a redirect), and send another POST request. Sometimes, a standard might look complicated, but very often the decisions are well thought through, and we might just not know the details.

When we are consumers of standards, it is hard to know the reasoning behind every design decision, so we usually have to accept that the standard solves the issues in the best way. Very often, when we try to come up with a better and simpler solution than the standard proposes, we start small and build up to create the new solution, solving any issues as they arise. In the end we usually just come to the conclusion that, indeed, what the standard proposes helps solve the issue pretty well.

Myth: Standards Make Vulnerabilities More Dangerous

Another argument I heard against using standards, especially the popular security standards, are the vulnerabilities that inevitably show up in any software. If everyone is using OAuth, and someone finds a way to hack an OAuth flow, then everyone becomes vulnerable. In essence, this is true, but there is another side to this.

When you have a popular standard, you also have a group of maintainers that looks after it. If someone finds a vulnerability, then you have these experts who can quickly come up with a solution and propose an update to the standard.

To stick with the OAuth example, when people found out that in a mobile environment, an attacker can intercept the authorization code and steal tokens, they came up with PKCE. Because you are using a proprietary solution doesn’t mean you are automatically more secure — you don't have the community of experts that vet standards and can help with patching them. If someone hacks your proprietary solution, then you are on your own to patch it.

Yet, the support from maintainers is not the only reason why it is beneficial to follow standards.

Standards Facilitate Adoption and Innovation

Using standards makes it easier to adopt innovations and shorten the time to market.

For example, if you are using OpenAPI to define your APIs and implement standardized API error responses, it is then much easier for both internal and external integrators to consume your APIs. Internal teams can deliver products and features faster, while external developers are more willing to integrate with your API.

Another advantage is when new trends and technologies emerge. Like AI agents and Model Context Protocol, for example. The specification mandates the use of OAuth to secure the MCP server. This means that companies that already use OAuth will be able to implement MCP servers more easily and deliver them faster.

Companies that do not yet use the OAuth security standard to protect their applications and APIs will need much more time and effort to work with MCP. In this case, using one well-established standard makes it easier to integrate another.

Even when there are no novelties on the horizon, you still benefit from using standards. Popular standards spark community support, which makes your life easier.

Ecosystem Support

Popular standards gain organic support from the community. People create tools that facilitate working with standardized systems. For example, if you use OpenAPI, you can then utilize products that automatically create documentation pages or generate SDKs to integrate with your API.

Systems that use OAuth can be easily integrated with applications through the use of OAuth libraries. Without these standards, companies would have to build bespoke solutions every time they needed a feature.

When deciding to use a standard, you might not even know what its adoption will eventually enable. For example, in the space of AI agents and MCP, companies that already implemented GraphQL as a standard for APIs can now leverage solutions like Apollo's MCP server for GraphQL to set up an MCP server in no time. Again, using the standard, allowed for easier and quicker innovation thanks to tools provided by the community. This wouldn't be possible without implementing standards.

Always Use Standards

Whenever possible, utilize a standard for your architecture or implementation. Following standards is beneficial to your organization, even if it takes time to understand it and its ecosystem. You will quickly see the returns from such an investment — whether in support from the community with patches or tools, wider adoption of your product, or ease in onboarding new employees.

Standards make your solution future-ready, simplifying replacements, integrations and innovations. Bespoke solutions can rarely match these benefits.

At Curity we wholeheartedly believe in standards. We participate in the works of standards bodies like the OpenID foundation, and we make sure that our flagship product — the Curity Identity Server — follows as many of them as possible.

Exploring the Future of API Security and Identity at Platform Summit 2025

Curity — Wed, 24 Sep 2025 00:00:00 GMT

Every year, Platform Summit gathers the global API community to explore the most pressing challenges and opportunities shaping the world of APIs and the digital world as a whole. In 2025, these conversations feel more critical than ever. APIs are powering all the essential services across finance, healthcare, public sector and many other industries, while AI-driven clients and automated processes are transforming the way systems are built, consumed and secured.

At Curity, we see several themes as most critical for the future of API security and identity - and we are excited to share some of those in October.

API Security: a Longstanding Focus

API security has always been at the core of our work, and it is a topic we have consistently championed at Platform Summit. Over time, we have seen the field grow from protecting endpoints with API keys to securing entire digital ecosystems, with identity and authorization playing a central role.

That’s why we’re especially excited about the introduction of the API Security Unconference on Day 0 (October 13) where participants are encouraged to bring their most challenging questions and experiences and to explore them in an open and collaborative way. Curity identity specialists will join as moderators, helping guide the conversation and connect real-world challenges to practical solutions, as well as share their knowledge and expertise. For us, it’s inspiring to see API security take center stage in such a dynamic format, reflecting how essential it has become.

The Rise of Non-Human Identities

Traditionally, APIs were built for human users or business integrations, authenticated and authorized through predictable flows. But today, APIs are increasingly consumed by AI clients, autonomous agents and ephemeral processes that exist only for moments at a time. These non-human identities create new challenges: permissions that linger after their purpose, workloads that operate outside human oversight and risks that can be hard to detect.

Curity’s CTO, Jacob Ideskog, will explore this shift in his talk, Ghosts, Zombies, and Robots: Handing Off Control to the Non-Humans. Using these metaphors, he will examine how OAuth can be adapted to protect privacy, reduce risk and restore control in a world where API actors are often invisible, uncontrollable, or short-lived.

MCP and the AI-to-API Connection

The emergence of the Model Context Protocol (MCP) highlights how AI systems are increasingly using APIs at scale. While MCP leverages OAuth, its unique patterns raise important questions. Is an MCP client just another OAuth client, or does it demand new infrastructure, policies and safeguards?

In MCP Client — Just Another OAuth Client?, Michal Trojanowski will examine how securing MCP differs from traditional client security, offering best practices for consent, refresh tokens and MCP gateways.

Complementing this, Gary Archer will deliver How to Design Secure MCP Deployments, a lightning talk that looks at authorization-first architectures, the threats MCP introduces and practical flows that maximize value while mitigating risk. Together, these sessions will offer both a conceptual and hands-on view of how to secure AI-to-API interactions responsibly.

Identity as a Strategic Lever

As more digital services are built API-first, identity has become the decisive control point. Whoever governs access effectively governs the system itself. With rising geopolitical tension and growing dependence on third-party cloud services, identity management becomes a matter of sovereignty.

Daniel Lindau will speak on this in Identity: The Kill Switch for API-Driven Digital Sovereignty. He will address the systemic risks of outsourcing identity and authorization to external providers, and show how open standards and wallet-based identities offer a path to restoring autonomy at organizational, sector and even national levels.

Looking Ahead

The intersection of AI, APIs and identity brings enormous potential, but also unprecedented challenges.

Platform Summit 2025 provides an important opportunity to explore these topics together. For Curity, it is a chance to contribute to the ongoing conversation about how we can build an internet that remains open, secure, and sovereign in the age of automation.

We look forward to seeing many of you at the Summit this October.

Modernize SAML Web Architectures the Right Way

Gary Archer — Wed, 03 Sep 2025 00:00:00 GMT

Many existing websites use legacy web architectures and outdated security solutions. One example is the Web Browser Profile from the Security Assertion Markup Language (SAML) 2.0 security standard, which was released back in 2005. In this model, websites externalize user authentication to SAML Identity Providers. After logins, websites receive user attributes in SAML assertions and use them to authorize requests from the browser frontend.

However, web architecture has moved on. Modern applications increasingly rely on APIs to manage data security. The move to APIs significantly changes how organizations should implement both data security and web architectures. Many companies are now working on SAML to OAuth migration and web modernization projects, replacing legacy SAML web architecture with more scalable and secure models. But what does an optimal solution look like?

Web modernization is also an area of much confusion for developers. There is a large amount of technology marketing about the best ways to develop web applications. Almost none of this marketing explains how web applications should manage data security and API integrations. In this article, I demystify some web jargon and show how the web and API sides of the architecture should interact to create a unified, secure architecture.

Modernization Requirements

Modernizing a web architecture means rethinking how technology, hosting, security, and integration patterns work together. It’s not just about updating frameworks — it’s about aligning with modern API-first architectures and strong identity practices.

Web Technology Requirements

For new apps, developers often choose a single page application (SPA) technology stack such as React or Angular. Instead of using SAML assertions, developers build solutions using the most up-to-date security standards, centered on the OAuth 2.0 Authorization Framework. The browser-based application receives an access token (AT) to send to APIs and a refresh token (RT) with which to silently renew it.

Although this technology update adds modernization, developers may follow insecure practices. Using tokens in the browser is considered less secure than the SAML solution. In some cases, the new app may fail security reviews and be unable to go live. Browser security is a hot topic for security reviewers, so any web modernization should first consider security modernization. You should also consider the crucial impact hosting has on the security and web architecture.

Hosting Requirements

Some older architectures, like SAML, had dependencies on legacy infrastructure. For example, you might need to store user accounts in Active Directory and use Windows Servers. Static web content does not contain secured assets, so it can use newer hosting technologies, like content delivery networks (CDN). For APIs and data, cloud native hosting usually provides the best technical control.

CDNs improve web performance by deploying static content to hundreds of locations so that the latency of requests is the same globally. Cloud native enables you to deploy APIs and data anywhere, perform phased modernizations, or take control over difficult requirements like data sovereignty, where you store user data in each user’s home region. These capabilities are often key goals when designing zero-trust, API-centric architectures.

Security Requirements

In 2025, your data security architecture should protect against many threats that can impact APIs, frontend applications, and users. You achieve the best protection when you apply the OAuth authorization framework while also following best practices.

For new web applications, pay particular attention to the latest security best practices from the OAuth 2.0 for Browser-Based Applications document. The main browser threat is cross-site scripting (XSS), a serious vulnerability that can expose sensitive data in many ways. For best protection, use the following approaches:

Prevent and contain XSS exploits.
Keep OAuth tokens out of the browser.
Use hardened HTTP-only cookies as short-lived API message credentials.
Prevent untrusted web origins from sending cookies to APIs.

You can perform a phased upgrade from SAML to OAuth with an identity and access management (IAM) system that supports both protocols. Start by repointing SAML apps to the new IAM system so that they continue to run as previously. At a suitable time, upgrade each SAML app to OAuth. This phased SAML-to-OAuth web modernization approach enables organizations to modernize their legacy web architectures without downtime.

Integration Requirements

Web development should be centered on the customer experience. There should be no need for web developers to run backend infrastructure that manages data security. Also, choose technologies that keep code bases modular, to support techniques like splitting large web applications into micro-frontends.

Another point to consider is that APIs are now the unit of reuse. Older practices like embedding webviews that render sensitive data into mobile apps or external web domains are no longer considered secure in the modern era, since browsers will not allow cookie sharing across domains. To scale UI architectures, organizations will need to develop views multiple times, in both web and mobile applications.

Web Architecture Styles

Unfortunately, many web modernizations produce suboptimal results. Developers make choices based on the latest technology stacks and their marketing. Online articles encourage the use of pre-rendering, client-side rendering, or server-side rendering, with little to no mention of data security. So let’s take a closer look at each of these styles from an API integration viewpoint.

Pre-Rendering

Organizations often have some frontend content that renders public data. For this content, you can use the architectural style of a blog or news site. Since all data is public, you can use technologies like NEXT.js to pre-render fixed content to HTML bundles without the need for the browser frontend to call APIs.

Pre-rendering is usually the optimal choice for unsecured web content. Deployments only need to upload HTML bundles to a CDN. The UI structure becomes HTML at deployment time, and the content is the same for all users. Pre-rendering performs well and can result in good search engine optimization (SEO) performance.

Client-Side Rendering

Both mobile applications and SPAs can use client-side rendering. To do so, an app must initiate user authentication and get an API message credential. The app then calls APIs to get data and update its view model. UI elements are then created from the model. The following Swift code snippet demonstrates the approach for a mobile application.

return VStack {

if model.data != nil {

List(model.data!.transactions, id: \.id) { item in

TransactionItemView(transaction: item)

}

The UI structure for sensitive data is unavailable until the frontend receives an API response and updates its model. You cannot pre-render the data since it varies by user, and it is not secure to pre-render sensitive data. Client-side rendering can work identically for web and mobile apps, which helps when you need to implement the same views on multiple platforms.

However, some suggest that web applications should instead use server-side rendering (SSR). Let’s look at how SSR works to serve HTML containing sensitive data to the browser at runtime.

Server-Side Rendering

In the days of SAML, it was common to use SSR for secured data. To see an example, check out the SAML 2.0 example website. The web host uses SSR to combine HTML with sensitive data.

<ul class='list-group'>

<% for (const item in model.transactions) { %>

<li class="list-group-item">Description: <%= item.description %></li>

<% } %>

</ul>

In OAuth you should aim to use short-lived cookies in requests from the browser to backend endpoints, so that if a cookie is somehow intercepted, an exploit only lasts for a short time. With client-side rendering, JavaScript frontend code can handle expired cookies and perform a refresh operation. With server-side rendering, the web host has to return an HTML response if a cookie expires, which is difficult for the frontend to handle with good usability.

When you use SSR for sensitive data, you do not get the SEO benefits that pre-rendering provides, since internet searches cannot reach secured views. More generally, the fact that the web host and HTML responses use sensitive data adds complexity and unwelcome side effects.

Hidden Complexity

The SAML example website uses a runtime that enables cookie-based web sessions, server-side redirects, and server postbacks. A session store maintains the web state during these operations. For production deployments, the session store needs clustering and persistent storage. Many CDNs are unlikely to support running web backends with these dependencies.

Many OAuth website technology stacks continue to use this type of complex backend. In fact, complexity may increase when you integrate OAuth and APIs. The web backend needs to implement an OAuth code flow, translate cookies to tokens, route requests to APIs, process backend error and expiry responses, and write backend logs. Therefore, server-side rendering requires web frontend specialists to implement many backend data security concerns.

Often, web developers start with a website solution that implements security and then evolve their setup into a hybrid app. The main frontend might be a single-page application like a React App. However, the developer must also run and maintain a complex web backend for all future development. Over time, this overhead adversely affects the time to market.

Modern Web Security Design

A key design principle for building an optimal web architecture in 2025 is to separate concerns. In the API era, you only need cookies to transport access tokens to APIs, and any session-related data should be stored on the API side of the architecture. Since cookies are an API message credential that transports access tokens to APIs, you should think of them as an API concern, not a web concern.

Separated Web Deployments

You can combine OAuth web security best practices with the client-side rendering of a modern web technology stack if you use a backend for frontend (BFF) that runs on the API side of the architecture. You then use utility APIs to manage secure cookies. Doing so externalizes backend data protection, and all of its complexities, from the web side of the architecture.

The token handler pattern separates concerns to provide a web security design for the modern era. Web developers only need a lightweight static content host and can focus on a frontend app that interacts with APIs. Deployed APIs include an OAuth Agent that gets tokens and issues cookies to the browser. An OAuth Proxy runs in the API gateway to apply web-specific protections during API requests.'

For some example frontend security code, see the SPA using Token Handler code example. This demonstrates a modern low-code approach where frontend developers do not run any backend infrastructure. The token handler pattern elevates the security of a browser-based application to the same level as a correctly implemented OAuth-secured website. In fact, it can exceed the security of older SAML websites.

type: embedded-entry-inline id: 11suq0Nt7AUmqhXRYmTaLy

Hardened Browser Security

Many older website technology stacks do not support the latest protections or may make it easy to misconfigure security settings. For example, they may use long-lived session cookies that increase the security impact of a stolen cookie header.

By contrast, modern implementations, especially those designed by security experts, can stay aligned with evolving browser standards. For example, if you migrate SAML apps to the Curity Identity Server, you can upgrade to OAuth by deploying the Curity Token Handler as a BFF. This enables a hardened setup that surpasses the security posture of most traditional websites:

SameSite and CORS protections restrict cookie access to an SPA’s precise origin.
A modern cookie encryption algorithm ensures confidentiality and integrity.
Short-lived cookies (e.g., 15 minutes) reduce the impact of cookie theft.
Pushed Authorization Requests (PAR) prevent browser tampering of OAuth requests.
JWT client assertions provide strong backend OAuth client credentials.

User Consent Best Practices in the Age of AI Agents

Michal Trojanowski — Wed, 20 Aug 2025 00:00:00 GMT

Every day we use systems, applications, and websites for all sorts of purposes — work, personal, entertainment. Many systems are interconnected, where you might use one application to aggregate data and another to modify data.

Think of an application that books a restaurant table that can access your calendar to add a reminder about the booking. Whenever you delegate access from one application to another — especially when they come from different vendors — you want to remain in full control of what the delegate will be able to do in the remote system.

This is a mechanism that we call consent; you give explicit consent as to what an application will be able to do in your name. With the rising popularity of autonomous agents, large language model-powered (LLM-powered) applications that can perform actions on other applications, the need for consent management for AI agents becomes even more important than ever.

What is User Consent and How Does It Empower Users?

In the context of applications and digital systems, consent is the explicit granting of privileges to an application. When a user wants one application to be able to access their data or act on their behalf in another application, they need to acknowledge:

What application is asking to be granted access?
To what application will the access be granted?
What data will the asking application be able to read?
What data will the asking application be able to modify?
For how long will the asking application have this access?

Collecting explicit user consent happens when the two applications in question come from different vendors, what we call “third-party applications” (less commonly, it can also happen when the applications come from the same vendor but are governed by different terms and conditions). When a mobile application from company A wants to access a backend API of that company, it will normally not ask for explicit consent.

The user already granted consent to how the company processes their data when they created an account with company A. When the application wants to access APIs that belong to another company, however, the user should have explicit control over this.

When the user is supposed to grant access, they are presented with a consent screen that should contain all the relevant information needed to make an informed decision. It is a tricky balancing act — the screen should not be cluttered with too much information nor be too vague.

The user should be able to easily identify what application is asking for access and what it will do with their data. Below is an example of a well-designed consent screen used by GitHub:

Clear information on the consent screen also helps prevent impersonation attacks, where a malicious application pretends to be a legitimate one. Furthermore, it allows the user to ensure that they give an application the minimum amount of privileges that it needs to perform its intended tasks.

Very often, consent is asked for only once for a given application. Once you give the application access to a given set of privileges, you will not have to do it again, unless the application wants to change the set of permissions. This means that organizations should allow users to manage the consents they’ve given.

You should be able to browse which applications you granted access to and revoke it if needed, like when you no longer use the application or you have a suspicion that access to that application was compromised.

Enter AI Agents

AI agents are hailed as the next step in the evolution of AI applications. LLM-based applications offer a natural-language interface to query the model for information. They allow you to freely converse with the chatbot. These applications gain the ability to perform actual tasks, like placing orders or bookings, sending emails, or filling in and submitting forms. To achieve that, agents use their ability to invoke preprogrammed “tools.”

There are different approaches to how a tool is implemented in an AI application, but a popular approach means calling an API to read or modify data. As the AI application is calling an API, it means that it becomes that API’s client, with the usual client attributes - it needs credentials to call the API on the user’s behalf.

One of the most popular approaches for applications to gain access to APIs is to use OAuth and access tokens. OAuth is an established standard that supports granting least-privilege access to limit what the application is able to do at the API. OAuth flows, used to obtain tokens, also support the collection of granular user consent for autonomous agents. Applications use scopes to get credentials with limited capabilities, and users can use that information to decide whether to grant or deny access to their data.

This approach can be used in pretty much the same way when working with AI agents.

Consent in the Context of AI Agents

From a purely technical perspective, an AI agent is just another client that requires access to the API — it needs to obtain access tokens to be able to perform actions on the API. However, agents have some important differences from the applications that we are used to operating. When you use a “regular” application, most of the time, it is you who is actually operating it. You click on buttons, enter data into form fields, and select options.

Even if the application or system has parts that are automated or run in the background, you are pretty confident of the actions that will be undertaken — if you click a button that says “move all files,” you don’t expect the application to start sending emails. When you introduce an AI agent, however, you add a sort of intermediary that is capable of some autonomy.

This means that the agent can decide to perform some actions because it “thinks” it needs to do it to fulfill the task that you originally asked it to do. You might not have total control of the actions that the agent will perform. And sometimes, unfortunately, the actions can meander into an unexpected territory, either because the agent “hallucinated” what it needed to do, or it was accidentally or deliberately tricked through prompt injection to take some dubious actions. Because of this, modern user consent for AI agents must guarantee that users retain full control over any AI-driven action.

This is why you should approach the topic of consent a bit differently when it comes to agents. Firstly, you should treat all agents like third-party applications. This means that the user should give explicit consent whenever delegating access to an AI agent. It allows the user to stay informed of what actions the agent will be able to perform and for how long. This ensures proper user control over AI agent actions and prevents unintended behavior.

The Need for Fine-Grained Permissions

Secondly, the consent should be even more fine-grained when it comes to the privileges the agent receives. Ideally, the agent should receive only the permissions it needs to perform the concrete action that it currently plans to perform — if the agent decided that it needs to check the content of emails and properly label them, then the access token should not allow the agent to send or delete emails. This means that backend systems and APIs should be prepared to operate with a granular approach to authorization.

Time-Limited and Transaction-Based Consent

Finally, you want the consent to always be time-limited, unlike with regular applications. The consent should automatically expire so that the agent is not able to unexpectedly gain access to a system after some time. Even better, the consent should not be persisted and given on a per-transaction basis—the user should be prompted for consent every time the agent asks for a new set of tokens.

Balancing Usability With Security

Following such an approach can mean that the user will have to give their consent numerous times during one session with an agent or even during the processing of a request. This becomes a delicate but important balancing act - the user should not be overwhelmed with the consents, as it raises the risk of blindly approving everything. At the same time, the user should not be limited to giving consent only once, with overprivileged access.

Best Practices for Granting AI Agents Access to APIs

The best practices below outline how you, as a user, should behave when interacting with AI agents. However, to be able to act this way, AI applications vendors and API vendors must ensure that they implement their systems in a way that allows users to adhere to these recommendations. These recommendations describe how users should behave, but serve as a guideline to vendors.

Always Limit the API Privileges of AI Agents

You should employ the rule of least privilege — give the agent the minimum set of permissions to perform the task at hand. This way, you limit any abuse the agent could perform. It’s better to grant the agent permissions numerous times, increasing the privilege if required, than allowing the agent to have over-privileged access to APIs.

Make Sure the User Consent Expires

Ensure that the consent you grant to an agent expires. Ideally, the consent should be valid only for the time of the current request or session. This means that you will have to consent every time the agent needs a new set of tokens to call the API. Note that asking for consent is unrelated to any user session you might have with the token provider.

You shouldn’t have to reauthenticate every time you see the consent screen. Vendors should allow you to choose how long you are granting the consent. For longer-running jobs, or when you know that the agent will constantly work in the background, you might want to grant a longer-living consent.

Use Reconsent Before High Privilege Operations

In some cases, the AI agent may receive an initial access token and then need to perform a higher privilege API operation that is outside the original user’s consent. APIs can deny access and trigger step-up authentication where the user must again grant consent. The AI agent can then be issued an access token with a higher privilege scope that the API accepts, ensuring ongoing consent management for AI-driven actions.

Customize User Consents

Vendors should allow you to tailor the contents of the consent. In some cases, consent can mean that the user grants access but places additional conditions. When the user consents to a scope, claims associated with that scope get issued to access tokens. Some claims can originate from user input, such as values the user inputs into a custom consent form. The following form shows an example where the user consents to a level of access but with a user-defined limit on a transaction and the time of access that an AI agent can use.

Allow Revocation of Long-Lived Consents

If you assign the agent long-lasting access, then make sure that the vendor allows you to manage the consent after granting it. You should be able to revoke the consent at any time, like if you no longer plan to use the agent or if you learn that the agent has been breached or is otherwise faulty. Revoking consent will, in effect, invalidate any refresh tokens, as the agent will not be able to use them to get new access tokens. Ideally, revoking consent should also revoke any active access tokens.

Conclusion

In current systems, the consent screen tends to be lacking — either it is too vague or too detailed, or it does not give the user the necessary options. With the rising popularity of AI agents, it becomes more important than ever to properly acquire the user’s consent — what they allow the agent to do in their name.

This requires careful and informed actions from users, but is only possible if users have the right tools available. Vendors of both backend systems and AI agents should take this into consideration and ensure that their products offer the correct features for the whole ecosystem to remain secure.

Learn more about how Curity helps to secure IAM in the age of AI.

Quantum-safe API Security

Judith Kahrer — Tue, 05 Aug 2025 00:00:00 GMT

How to Prepare APIs for the Post-quantum Future

Quantum computing changes the security assumptions for APIs. With the help of specialized algorithms, quantum computers can speed up calculations and potentially break common cryptographic algorithms. To keep data safe, things need to change. This article discusses controls that you should take to boost an API security architecture and prepare for quantum computing.

Fortunately, several practical steps - including robust token design and proxy configuration - already allow teams to build quantum-resilient APIs today, even before new cryptographic standards are fully deployed.

What is Quantum Computing?

Quantum computing takes advantage of physical properties such as superposition and entanglement. Superposition allows tiny particles to be in multiple energy states at once, while entanglement links particles so their states remain synchronized, even across distance.

While conventional computers operate on “bits” to store information that can either be on (1) or off (0), quantum computers use quantum bits, “qubits”, that can be in multiple states. That is, qubits can be zero, one and anything in between at the same time. Furthermore, the states of qubits can be entangled giving a quantum computer exceptionally much more computing power. As a result, the main benefits of quantum computing are parallelism and processing speed.

Quantum computers are not good at everything; they perform very well for special computations. It turns out that quantum computers are good at breaking crypto, which impacts the techniques used to protect APIs and business data.

What is the Impact of Quantum Computing on API Security?

API security relies heavily on cryptographic algorithms to deliver key security properties such as confidentiality, integrity, authenticity and non-repudiation. These typically rely on mathematical problems that are difficult for traditional computers to solve.

Quantum computers change the current state of the art significantly. They can eventually solve common cryptographic problems in a fraction of time compared to conventional computing (e.g., hours instead of years). Such computers are called Cryptographically Relevant Quantum Computers (CRQC). They basically deprecate many common cryptographic algorithms.

In practical terms, there is a risk that transport encryption such as HTTPS can be decrypted and requests manipulated on the fly, or that unauthorized parties can create valid signatures to undermine any integrity and authenticity. In other words, the availability of CRQC potentially breaks common API security controls and neutralizes any trust in digital communications.

There are still challenges with quantum computing that prevent a big rollout of CRQCs. Quantum computers are error-prone, for example, and can only process a limited amount of data. So far, researchers have only managed to crack RSA with very small keys (such as 80-bit) using quantum computers. However, attackers may already harvest encrypted data for later decryption with CRQC (an attack called “harvest now, decrypt later”), putting data from the past (archived documents), present and future at risk.

Researchers estimate that a quantum computer with less than a million noisy qubits could factor a 2048-bit RSA integer in less than a week. In line with that risk, NIST recommends in its initial public draft deprecating ECDSA, EdDSA and RSA in 2030 and stopping using them after 2035. Similarly, the European Commission recommends member states to transfer to post-quantum cryptography as soon as possible.

What is Post-Quantum Cryptography?

Post-quantum cryptography (PQC) encompasses algorithms whose security properties hold despite the processing power of quantum computers of tomorrow. It means that not even cryptographically relevant quantum computers will be able to break such algorithms, decipher encrypted communication or calculate private keys from public keys. Other names for post-quantum cryptography are quantum-proof, quantum-resilient or quantum-safe cryptography (QSC).

Standardization and guidance is very important when it comes to the selection of cryptographic algorithms. The following list includes algorithms that either the National Institute of Standards and Technology (NIST) or the German Federal Office for Information Security (BSI) calls out to be quantum-safe.

Key Agreement: FrodoKem, ML-KEM

Symmetric Encryption: AES

Hash Functions: SHA2, SHA3

Message Authentication Code: HMAC, CMAC

Signature Schemes: ML-DSA, SLH-DSA

The above list includes new and traditional algorithms because cryptographically relevant quantum computers have a higher impact on asymmetric algorithms than on symmetric ones. If you are already using SHA2, and AES such as AES-GCM, for example, then you may not have to change (much) in certain areas of your API security architecture.

How Does Quantum Computing Affect the Curity Identity Server?

The Curity Identity Server uses cryptography across several key areas. Here’s how it’s affected.

Area	Algorithms (available)	Quantum-Safe	Comment
Configuration	AES	yes
Hashing functions	SHA2 (SHA-256, SHA-512)	yes
TLS 1.3 (Handshake)	ECDSA, EdDSA, RSA	Not yet	Can be solved via a reverse proxy that supports TLS 1.3 with quantum-safe algorithms.
TLS 1.3 (Encryption)	AES-GCM	yes
Access Tokens	N/A	yes	External clients receive access and refresh tokens with an unguessable and quantum-safe opaque access token format.
Token Signatures	RSA, ECDSA, EdDSA	Not yet	Mostly used in the internal network, where APIs receive JWT access tokens. Future product versions will support quantum-safe signature algorithms.
Symmetric Signatures	HMAC-SHA	yes
Symmetric encryption	AES	yes

The above table lists two current vulnerabilities: TLS and token signatures. TLS is typically out of hand of the Curity Identity Server as the TLS communication terminates at an API gateway.

a proxy. It means that you don’t have to rely on Curity to solve the problem but can address it independently via the proxy. This leaves token signatures as the only open issue. With the correct architecture, you don’t even have to bother with that.

Phantom Tokens: A Practical, Quantum-Safe Token Strategy

Curity has been advocating the phantom token approach as a best practice for years. Typically we explain the privacy and architecture benefits. But it turns out that phantom tokens are also the most effective and immediately implementable strategy for quantum-safe access tokens.

The phantom token approach is simple to understand:

The authorization server issues opaque, random tokens (not JWTs).
Clients receive and use these non-parsable tokens.
At runtime, the API gateway introspects the token and exchanges it for a signed JWT inside the trusted network.

Opaque access tokens are quantum-safe tokens. They are random strings that the authorization server associates with some data. The only way to determine whether an opaque access token is valid, is via the authorization server using a protocol called introspection. A cryptographically relevant quantum computer cannot craft a valid, opaque token to pass validity checks.

With opaque tokens, a quantum computer must guess the correct value. It may, at best, be quicker to generate new random values than conventional computers, but it still needs to try each guess to check whether it found a valid token that gives access. This is no different from the current threat of brute forcing.

You should address the threat of brute force independently from the quantum computing risks. What is more, since brute force is not a new risk, you most likely already have controls in place. For example, you may already use mechanisms such as rate limiting and cooldowns to restrict requests with invalid access tokens.

By simply changing to opaque access tokens and applying the phantom token approach, you can reduce the API risks of quantum computing to those of brute force attacks. There is no need to support new, complex algorithms for access tokens that you return to external clients. Once quantum-safe algorithms are available, you can also update the internal network to use them without changing your deployment architecture. The phantom token approach is therefore future-proof.

Conclusion

Cryptographically relevant quantum computers (CRQC) appear scary because of their impact on the current ecosystem. Some solutions require a switch to post-quantum algorithms. For example, to mitigate the risk of harvest-now-decrypt-later threats, change to TLS 1.3 with quantum-safe algorithms in your reverse proxy or API gateway. Some proxy vendors already support quantum-safe TLS.

When it comes to access tokens, you can use the phantom token approach to achieve a post-quantum solution without quantum-safe algorithms. Sometimes, the simplest solutions are the best and most robust. The phantom token approach is one of them. The Curity Identity Server supports the phantom token pattern out of the box - letting you build secure, scalable, and quantum-resilient API architectures today.

5 Ways Curity Identity Server Solves Modern Identity Challenges

Stefan Nilsson — Wed, 16 Jul 2025 00:00:00 GMT

Identity is no longer a backend concern. It’s at the heart of digital security, user experience, and compliance. As organizations scale across cloud environments, adapt to shifting regulations, and serve increasingly diverse users, the need for a flexible and future-ready identity management solution has never been greater.

That’s where the Curity Identity Server comes in. Designed for real-world complexity, Curity offers a powerful solution that meets the needs of modern identity teams. From its adaptable architecture to its robust authentication capabilities and deployment flexibility, the Curity Identity Server empowers organizations to build secure, scalable identity infrastructure without compromising on customer experience.

In this article, I’ll share five key reasons why the Curity Identity Server stands out—and how it helps identity teams solve everyday challenges.

Key takeaways

Identity is central to security, compliance, and user experience
Organizations face recurring challenges in managing identity
Curity Identity Server provides practical, standards-based solutions

1. Flexible Architecture Built for Complex Environments

Today’s identity environments aren’t simple. Most organizations manage a mix of on-premise systems, cloud-native apps, and third-party services across multiple regions. The Curity Identity Server is designed for this complexity.

Its modular architecture, based on separation of concerns, allows teams to configure and extend functionality without reengineering their stack. Whether you’re rolling out multi-factor authentication across services or integrating legacy apps into a modern flow, Curity provides the tools to do it securely.

The server also supports microservices and event-driven systems, making it easy to embed identity services wherever needed. For security teams, that means fewer workarounds. For developers, it means faster, smoother integration. Together, these capabilities help maintain an effective identity lifecycle.

Key benefits:

Works across hybrid, multi-cloud, and legacy environments
Integrates with internal systems and third-party APIs
Reduces complexity while giving more control over authentication logic

2. Advanced Authentication Flows That Adapt to Real-World Use Cases

Authentication is rarely one-size-fits-all. Users, devices, and security contexts vary—and the authentication experience should reflect that.

The Curity Identity Server enables advanced, adaptable authentication flows that match real-world requirements without becoming unmanageable. At its core is user journey orchestration, which lets teams design chained and conditional authentication flows.

You can easily combine methods such as passwordless authentication, multi-factor authentication (MFA), and identity federation into a single, seamless user journey. Flows can also adapt dynamically to risk signals, user context, or application needs.

Examples include:

Triggering extra authentication for sensitive actions, like wire transfers
Using WebAuthn for strong security, while keeping fallbacks for older systems

With Curity, you balance security and user experience—without writing custom code or duplicating setup across apps.

Key benefits:

Chain and customize authentication using built-in or custom authenticators
Adjust flows based on user context, device, or risk level
Implement modern methods like Passkeys, WebAuthn, social login, or e-IDs
Keep your setup flexible and future-ready with reusable building blocks

3. Deployment Freedom: Cloud-Native, On-Prem, or Hybrid

Every organization has unique infrastructure needs. Some are fully cloud-native, others rely on critical on-premise systems, and many use hybrid models.

The Curity Identity Server is built with modern deployment practices in mind. It runs natively in Kubernetes and supports containerized environments out of the box, making it a natural fit for cloud-native DevOps teams. It’s equally capable in traditional on-premise setups, supporting secure, high-performance deployments in data centers and private clouds. This flexibility means identity doesn’t become a blocker as your infrastructure evolves.

Key benefits:

Deploy in AWS, Azure, GCP, on-prem, or any environment
Support hybrid and multi-cloud setups seamlessly
Enable high availability and scaling with modern orchestration tools
Align identity with your DevOps strategy

This flexibility ensures identity adapts to your infrastructure—not the other way around. That means less technical debt, fewer compromises, and smoother paths to your goals.

type: embedded-entry-inline id: 3sSzK0qauViBBz3eJRSXhU

4. Data Sovereignty and Regional Compliance

As privacy laws tighten, identity systems must secure access and respect where data is stored and processed. The Curity Identity Server supports data sovereignty, helping organizations meet regional compliance requirements while staying scalable.

Curity makes it easy to deploy identity services in specific regions, so they can run closer to your users and their data. This helps you meet privacy regulations like GDPR, CCPA, and other laws that require sensitive data to stay within certain geographic areas. Whether you're operating in the EU, North America, or across multiple regions, Curity gives you the control to meet local compliance needs without added complexity.

In addition to the option of regional deployment, the Curity Identity Server supports fine-grained policy controls for authentication, data handling, and consent. You can configure flows to meet local compliance needs, audit user consent actions, and enforce data minimization by ensuring only necessary information is processed.

Key benefits:

Deploy services in specific regions to meet data laws
Align authentication and processing policies with regulations
Support compliance without architectural compromises

5. Seamless Integration and Developer-Friendly Operations

Identity must integrate easily with existing systems and workflows. The Curity Identity Server is designed for this, helping teams connect identity and access control without adding complexity.

Advanced configuration features let teams manage identity settings through version control, treating them like infrastructure-as-code. This supports DevOps and GitOps workflows, improves consistency, and reduces manual errors.

The Curity Identity Server also supports a wide range of standard protocols, including OAuth, OpenID Connect, and SCIM. This ensures compatibility with internal applications, third-party services, and access management tools. Clear documentation, flexible tooling, and templated patterns help teams move quickly without compromising security.

Key benefits:

Integrates with existing systems and CI/CD pipelines
Supports automation and infrastructure-as-code practices
Works with apps and services through open standards
Speeds up secure delivery of identity features

Conclusion

As identity becomes more central to digital security, user experience, and regulatory compliance, organizations need a solution that doesn’t force trade-offs between control, scalability, and flexibility.

The Curity Identity Server delivers:

Flexible architecture for complex environments
Advanced authentication for real-world needs
Deployment freedom across cloud, on-prem, and hybrid setups
Strong support for data sovereignty and compliance
Seamless integration that fits DevOps practices

Curious how Curity could support your identity strategy? Reach out to our team or book a meeting to see how the Curity Identity Server can help you build a secure, scalable, future-ready identity infrastructure.

Redefining IAM for Customers and Partners

Curity — Tue, 01 Jul 2025 00:00:00 GMT

The traditional B2C/B2B identity model no longer fits today’s digital landscape. The 2025 Gartner® report Innovation Insight for Customer and Partner Identity and Access Management contains new insights. This shift is crucial to effectively manage customer (CIAM) and partner (PIAM) identities.

So what does this shift mean in practice? Here are the top takeaways from the Gartner report and what they mean for your IAM strategy.

Redefine B2C and B2B to no longer represent user constituencies but instead describe collections of IAM functionality: one targeted at supporting individuals (B2C) and one targeted at supporting organizations.
CIAM tools manage identity, authentication, and authorization for customer identity use cases and will typically require a combination of B2C and functionality.
Uses for PIAM technologies include partner and vendor collaboration, including distributors, dealers, brokers, and supply chain activities.
These AM use cases have both overlapping and discrete drivers: CIAM’s focus is user experience, privacy, and security; PIAM’s focus is secure and controlled access for external business entities and partners.

Recommendations

If you’re updating or overhauling your IAM strategy, these are the steps Gartner recommends for IAM leaders:

Modify the definition of functionalities known as “B2C” and “B2B” in CIAM and PIAM projects. Success can be achieved through redefining these terms in CIAM and PIAM use cases as AM services for individuals (B2C) and AM services for organizations (B2B).
Build a solid foundation for CIAM and PIAM projects by investigating and understanding the unique requirements for both use cases and addressing each as a unique and discrete initiative in your IAM program.
For PIAM, plan early for identity data and identity provider (IdP) integration strategies, both from a self-service (B2C) and federation (B2B) perspective.
For CIAM, plan early for integration with adjacent tools, such as DXPs, CPM tools, and identity verification (IDV) tools.
Balance user experience and security. It is tempting to go “all in” and protect all attack surfaces in CIAM and PIAM initiatives as much as possible. However, adding overly strict ATO prevention controls can cause friction and compromise the UX, ultimately frustrating existing consumers, prospects, and partners.

By following these steps, we believe organizations can better support identity-driven use cases across all sectors.

Market Snapshot

As identity needs grow, so does the market response. As per the report, “CIAM has a market penetration of a little over 40%, and the technology is in the early mainstream stage of maturity.” Meanwhile, PIAM is just gaining momentum; most implementations are still custom-built, but new vendors are entering the space with purpose-built tools.

This trend reflects a broader industry shift away from building in-house IAM platforms toward purchasing specialized, integrated solutions, reducing costs while improving security and user experience.

Conclusion

The bottom line? Identity today is more complex and more strategic than ever. The Gartner Innovation Insight for Customer and Partner Identity and Access Management report makes it clear that effective IAM today means moving past rigid B2C/B2B labels and embracing flexible, user-focused strategies. By tailoring identity services for individuals and organizations, businesses can streamline access, reduce risk, and support both growth and compliance. Dig into the full report here.

Gartner, Innovation Insight for Customer and Partner Identity and Access Management, Michael Kelley, Abhyuday Data, Akif Khan, Nathan Harris, 28 April 2025