The Neo-Security Architecture in Practice

The Neo-Security Architecture describes the functions for a modular, open-standard-based security architecture for API access. This article provides the technical background that illustrates how these functions work together to implement continuous runtime authorization for APIs which is an essential ingredient when AI agents join the picture. If you are unfamiliar with the main concepts and pillars of the Neo-Security Architecture, see the Neo-Security Architecture overview for an introduction.

This article introduces a comprehensive, technical reference architecture for deploying API security that scales with new requirements such as those arising from AI agents. It follows up with a detailed description of the features like OAuth, Token Exchange, Shared Signals and other novel techniques.

Study the reference architecture and its description to learn about the responsibilities of existing systems and standards for secure API access. Use it as an inspiration, orientation, guideline or vision when implementing runtime authorization for your APIs to stay ahead of risks.

AI-Ready Reference Architecture for API Security

The following diagram showcases the reference architecture, which is centered on API access, to serve any type of API client, including AI agents. The following content explains the security behaviors at each stage.

The reference architecture is grounded in the Neo-Security Architecture and implements continuous runtime access control for both users and machines. This means it allows for adapting access for each request according to internal rules no matter whether the request originates from a user or an autonomous machine. For this, the architecture groups systems into four main layers.

• User Authentication
• Machine Authentication
• Authorization
• Security Governance

User authentication and machine authentication relate to the Identity Management System and Machine Identity Management System pillars of the Neo-Security Architecture, respectively. Both human and machine identities and their related authentication methods are an integral part of authorization.

Authorization includes the Identity Management System, API Management System and Entitlement Management System pillars of the Neo-Security Architecture. It is surrounded by security governance which incorporates the Security Operations System pillar.

The authorization layer feeds into the security governance layer. The security governance layer, on the other hand, feeds back to the authorization layer. This circular dependency enables continuous access control.

Continuous Access Control

Continuous access control means to constantly reevaluate the permissions a user or machine has. To make this possible you need three important capabilities.

• The possibility to detect risks
• The possibility to notify actors with signals
• The possibility to evaluate access decisions when access happens (runtime authorization)

Reevaluating the permissions only makes sense if you consider dynamic parameters for the decision. For example, you can associate risks with identities and their actions. This risk changes based on the involved identities, what you know about them, and their behavior, what they did before and are requesting to do.

Security Signals

The layers can communicate through signals to inform about events that may change the outcome of an access decision and access enforcement. The security governance layer allows you to aggregate signals and other data necessary to determine the risks associated with access requests which is an important part of threat detection. It can then use signals to have other systems adapt their decisions.

Standards

The important standards in this context are the Shared Signals Framework specification and Security Event Token profiles. Security event token profiles unify the signals for certain events and enable interoperability which is central for the security governance layer, its holistic view and integration with the authorization layer.

Signals serve as input for threat detection and continuous authorization. Runtime authorization makes sure to enforce and if necessary reevaluate the decisions on every API request.

Runtime Authorization

Runtime authorization assumes a zero trust architecture. It means that every API request triggers an authorization decision. This section explains what deploying zero trust and runtime authorization implies in terms of OAuth 2.x and access tokens.

Zero Trust Architecture

Zero trust implies that trust is not implicit or assumed but explicitly established. As a consequence, a zero trust architecture is a token-based architecture. This idea is outlined in detail in Zero Trust Architecture is a Token-Based Architecture.

In the token-based architecture, the access token is used to establish the trust explicitly. APIs automatically and by default reject any request that does not carry a valid and trusted access token with the appropriate properties.

Access Token as Identity Carrier

Every access token carries a description of the machine identity next to the user identity where applicable. The machine in this context is a piece of running code that requests access to an API. Examples are user-facing applications like a mobile app, a web app, a browser-based app (single-page application) or an AI agent. In OAuth these machines are called clients.

Phantom Token Flow

Clients receive opaque, by-reference tokens that do not embed any data. A pattern called the Phantom Token pattern allows a gateway to translate by-reference tokens from clients to internal JWTs that APIs can parse and read data from.

With the phantom token pattern, clients are forced to treat the access token as the opaque value that the OAuth framework defines it as, while APIs can benefit from self-contained JWTs. What's more, the opaque access token cannot leak any identity data to the client or any other actor which minimizes privacy-related risks and misuse of the token data.

Short Token Lifetime

Short access token lifetime ensures you get to reevaluate permissions on a regular basis. This enables just-in-time access as well as zero standing privileges.

Distributed Enforcement

There are various APIs in the backend in the form of AI agents, MCP servers or microservices. Each API needs to enforce access control policies with the help of the access token. As there are many APIs, there are many policy enforcement points.

APIs get help from gateways to enforce policies. In addition, gateways enable unified access control for the APIs they protect which ensures consistent processing rules.

Policy-based authorization helps to manage the complexity by introducing a policy engine. The policy engine allows for administration of central policies. These policies define the decisions for the different policy enforcement points. They allow for updating policies without having to update all policy enforcement points. The important specification here is AuthZEN.

Just Enough Privileges (JEP)

For each access token request, the authorization server can apply signals from the security governance layer for continuous authorization and limit the access an upstream token conveys. It can thus adapt the access token to carry just-enough privileges (JEP) and follow the principle of least privilege. Such access tokens allow for risk mitigation by reducing the impact should the access token leak or an API like a backend misbehave.

The important standard in this context is OAuth Token Exchange.

Just-in-time Access

Clients and downstream APIs must request an access token to access resources. Access tokens have a validity time, a time span in which they are considered valid. By adapting the expiration time, access tokens can give access only for the time needed allowing for just-in-time access.

Zero Standing Privileges

A valid access token gives certain privileges on certain APIs, resources and actions. No valid access token means no privileges. This applies to any client or downstream API. Consequently, OAuth allows for implementing zero standing privileges for API access. Access tokens expire and with them the privileges for access, leaving no standing privileges behind.

Standards

The important standards for runtime authorization are listed in the following table.

OAuth Token Exchange allows for maintaining identity and authorization information from incoming tokens. This is a useful capability for conveying delegation chains and also for cross-app access.

Cross-App Access

Cross-app access (XAA) occurs when identities reside in one domain and clients access APIs in different trust domains. For example, users may log in with their corporate account and need to access APIs from partners or SaaS products.

Federated API access requires applications (or APIs) to get access tokens from a remote organization’s authorization server, which acts as the authority for APIs. For XAA integrations to successfully interoperate, participating organizations must use an authorization server that supports emerging security standards.

Traditionally, federation bridged trust and allowed for SSO across domains. Federation has implications for the user experience because it requires a browser to send SSO cookies and follow HTTP redirects. What's more, it does not work for AI agents or other background tasks.

AI agents are integrated in various applications where there is no browser or user present. The ID-JAG (Identity Assertion JWT Authorization Grant) draft solves SSO and cross-app access for AI agents. It defines a flow where the client exchanges an identity assertion such as an ID token from a login for a JWT-based authorization grant. The client can use that grant to request an access token from another domain. The flow is completely discreet for the user.

Other terms for cross-app access are API access across trust domains or SSO for AI agents. The following table shows the primary standards for cross-app access.

Discover Authorization Details

OAuth requires configuration on the authorization server and each client for clients to be able to retrieve access tokens. Traditionally, client developers need to figure out authorization requirements out of band, like which authorization server and scopes to use to access an API. With AI agents there is a demand to enable automatic discovery and automatic onboarding. The MCP authorization specification showcases what such a flow can look like.

The following table lists the important standards for discovering authorization details.

Machine Authentication

Machine authentication ties into what is commonly known as Non-human Identity Management. It defines the means of authentication for workloads like gateways, AI agents, MCP servers and APIs.

The reference architecture highlights that machine authentication is more than just configuring a client ID and secret. It may, for example, also imply a registry or vault. The most relevant part for machine authentication for workloads is the workload identity system.

A workload identity system ideally attests workloads. As a bare minimum, it assigns workload identities and issues workload credentials (such as a Workload Identity Token, WIT). These credentials can be bound to a key or they can be bearer credentials. The type of credential defines which authentication methods are applicable for a workload.

In OAuth, workloads use their workload identity and credential when authenticating to the authorization server, for example, as part of a token exchange flow. If workloads prove control over a private key as part of their authentication method, the authorization server can also bind the access token to that key. The most prominent example for this behavior is mutual TLS with certificate-bound access tokens. Technically, the idea works for any asymmetric client authentication method.

A traditional workload credential is an X.509 certificate, and JWT-based credentials gain popularity for workload federation. The following table provides a brief overview of client authentication methods in OAuth beyond the classical client ID and secret.

User Authentication

User authentication verifies a user identity in a request. In OAuth, the authorization server typically triggers authentication as part of a code flow. This flow requires the user to be present and operate the client. The Client-Initiated Backchannel Authentication (CIBA) protocol provides an alternative that allows for out-of-band authentications and approvals where the user does not operate the client.

Secure Access for AI Agents

This section highlights the components and interfaces in the authorization layer that are distinct and important for AI agents.

Authorization Server

The authorization server is the core of the authorization layer. Simply put, it issues access tokens. However it performs many steps and checks behind the scenes before it returns and issues an access token. This is where its power lies. The following list highlights the important tasks the authorization server performs.

• Authenticates users and machines.
• Sends to and consumes signals from the security governance layer.
• Applies coarse-grained and dynamic policies based on the signals.
• Issues access tokens.
• Maintains identity and authorization data across hops.

Since the authorization server is so central, it needs support of many standards to enable the reference architecture. See supported standards for an overview.

AI Agent Gateway

The AI agent gateway is a workload with a workload identity that translates an incoming access token from an internet client into an internal JWT. For web clients, the gateway can use a token handler to translate HTTP-only cookies to an internal JWT. AI agents can then validate the JWT access token before performing operations like calling LLMs or other agents.

If required, the agent gateway can initiate its own requests to the LLM to calculate where to route requests. The AI agent gateway then figures out to which AI agent it needs to forward the request. At this point the AI agent gateway may request the user to step up authorization if that is what it requires to fulfill the intent.

AI Agents

AI agents are software that utilize LLMs to figure out the commands and requests they need to run to solve an intent. They derive the intent from a textual description of a problem, a task or a goal. AI agents can be third-party applications that act as clients or backend applications that are comparable to APIs. In the latter, a request first reaches an AI agent gateway or orchestrator that ensures unified access control for upstream AI agents.

AI agents are workloads with workload identities that validate access tokens according to best practices just as any other API. This includes basic validation like expiration time and signature, and also scopes and audience.

AI agents use token exchange to retrieve access tokens for upstream calls, like those to MCP servers. This allows the authorization server to add agent-specific attributes to access tokens, like the agent’s role or set limits on the amount of a particular resource (e.g. money) that the agent can operate upon. Token exchange also maintains identity data from the original token and reflects the delegation chain in the new access token.

MCP Servers

MCP servers are APIs for the MCP protocol. They sit behind an MCP gateway that ensures unified access control for upstream MCP servers.

The MCP gateway is a workload with a workload identity that translates an incoming access token from an internet client into an internal JWT. For web clients, the gateway can use a token handler to translate HTTP-only cookies to an internal JWT. This allows any upstream MCP server to operate on the self-contained JWT for optimized processing. In addition, it performs coarse-grained access control.

MCP servers are workloads with workload identities that validate access tokens according to best practices just as any other API. They validate basic properties like the expiration time and signature, and also the scope and audience. They may perform fine-grained authorization if applicable.

MCP servers use token exchange to retrieve new access tokens. This allows for maintaining identity data and the delegation chain in upstream calls.

APIs

APIs or microservices are the final point that hold the protected resources. An API gateway protects the microservices and enables unified access control by translating incoming tokens to internal JWTs if required. For web clients, for example, the API gateway can use a token handler to translate HTTP-only cookies to an internal JWT.

The API gateway applies coarse-grained access control like rejecting requests with invalid tokens. It may also request audience-restricted access tokens for the upstream APIs if required.

APIs validate access tokens according to best practices, like verifying expiration time, signatures, scopes and audience. APIs also enforce fine-grained access control based on the identity data in the access token. They may integrate with the policy engine for that.

Conclusion

The reference architecture uses two mechanisms that make access control continuous rather than static:

• Token exchange, so that the authorization server continually acts as an authority, to provide authorization context tailored to each resource server
• Shared signals that connect the authorization layer with the governance layer so that observed risks immediately affect future authorization decisions

You may not need to adopt all components in the architecture. Because it's modular and based on open standards, you can introduce security controls step by step. For example, you could start with the phantom token pattern at your gateways, then add token exchange for upstream calls, then add shared signals for continuous authorization. Each step reduces risk on its own and builds toward runtime authorization across your entire API landscape.

Published: 2026-11-05

Curity