DEV Community: Maria Pelagia

API Security: Common Misunderstandings for Business Teams

Maria Pelagia — Tue, 17 Feb 2026 00:00:00 +0000

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.

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.

Identity and Access Management for AI Agents

Maria Pelagia — Thu, 27 Nov 2025 00:00:00 +0000

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!

(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

Maria Pelagia — Mon, 17 Nov 2025 00:00:00 +0000

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.

Modernize SAML Web Architectures the Right Way

Maria Pelagia — Wed, 03 Sep 2025 00:00:00 +0000

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.

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

Maria Pelagia — Wed, 20 Aug 2025 00:00:00 +0000

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.

OAuth: What Everyone Should Know

Maria Pelagia — Wed, 23 Apr 2025 00:00:00 +0000

When you work as intensely with a certain technology as my colleagues and I do, you get a clear picture of how it works and should work. At some point, you realize that you have become an expert in your field; in our case, it’s OAuth. This is also the point where things that are obvious to you are not for others.

Securing API access is part of data security

OAuth enables integrated solutions between users, clients (applications), and APIs. OAuth systems provide the client with an access token with restricted API access. Although there are many guides on OAuth, they are commonly limited to retrieving the access token. As experts, we know there is much more to OAuth than sending the right protocol messages.

We found that there was a gap in the specialist literature around providing organizations with the strategies to integrate OAuth in particular ways so that security facilitates (modern) technologies and meets developer experiences. We realized that to make the internet a safer place, we needed to make our know-how available to the broader community. Slowly but surely, the idea of a book was born.

We decided on the title “Cloud Native Data Security with OAuth.” Some people may think the title is controversial because OAuth is all about securing access, while data security tends to be about securing data storage and encryption. However, this is exactly the pattern that we want to disrupt. You cannot talk about access control and authorization without also considering the data you want to protect. The goal of OAuth is to protect data (authorization) that APIs expose. It focuses on cloud native because it allows us to recommend solutions you can run anywhere.

Authentication is secondary to authorization

In OWASP’s top 10 API security risks list, broken authorization takes the front rank. It means that you need to secure access beyond simply authenticating users because your attackers may already have logged in, e.g., via stolen or compromised credentials.

Of course, securing the authentication process is part of the game. However, authorization is not the primary concern because authorization is about granting the least privileges to (authenticated) users. Newcomers to OAuth often focus on user authentication. Many misunderstand that the heart of OAuth is the content of the access token that should enable APIs to enforce least privilege access.

For data security with OAuth, you should rely on identity attributes when evaluating access control policies. For this, you should map scopes to a certain set of identity data to model the access token. The access token and related data are the source for APIs to enforce access rules. This approach combines token-based with attribute-based access control and provides a good foundation for an API security architecture.

A good access token design is essential for API security. Therefore, we devote a whole chapter to access token design, so that you can scale the use of access tokens to many APIs and clients.

There is more to access tokens than their attributes. The API gateway, for example, plays a vital role in an API security architecture with OAuth, as it provides the public interface of an API. The API gateway can compensate for client-application specifics so that you can implement a unified approach for access controls in API services. Having one way to do things simplifies development and, as a result, reduces vulnerabilities.

Cloud-native technology gives you many choices

The cloud-native aspect of the book focuses on choices like where you store identity data, the components you can use, and where you can operate OAuth. For example, it highlights how to integrate workload identities in an OAuth architecture to strengthen credentials.

The book lists best practices for client applications to address the weakest links in the security chain. It provides guidance and examples on implementing OAuth in browser-based and platform-specific applications (“native applications”), covering desktop and mobile clients.

The cloud native focus enables us to provide code examples that show how to run end-to-end OAuth flows with exactly the same technologies on local computers and cloud deployments. In the last chapter, the book discusses how to fortify authorization with strong authentication to improve assurance in the identity attributes.

In the end, implementing data security with OAuth is all about the attributes — the characteristics you provide to gain access to data. This is very apparent to us, but we found this message was missing in the OAuth-related literature. We filled the gap with Cloud Native Data Security with OAuth so that more people can utilize the building blocks OAuth provides and combine them with cloud-native technology to protect business assets in a secure and scalable way.

API Security Trends 2026

Maria Pelagia — Sun, 12 Jan 2025 00:00:00 +0000

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?!