Wiki · Concept · Last reviewed June 25, 2026

Grant Negotiation and Authorization Protocol (GNAP)

GNAP is an IETF authorization protocol for negotiating grants between software, authorization servers, resource servers, and users, with key-bound client instances as a first-class design feature.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, identity, GNAP, OAuth, resource servers

Definition

The Grant Negotiation and Authorization Protocol, or GNAP, is a standards-track IETF protocol for delegating authorization to a piece of software and returning the artifacts of that delegation to the software. RFC 9635 was published in October 2024 by Justin Richer and Fabien Imbault. It can cover access to APIs and subject information, not only a single web-login flow.

GNAP belongs near OAuth, OpenID Connect, and delegated-authorization systems, but it is not an OAuth extension and is not directly compatible with OAuth 2.0. RFC 9635 presents it as a protocol for use cases that OAuth 2.0 cannot easily or cleanly address. That distinction matters for agent infrastructure: "use GNAP" is not the same claim as "add one OAuth scope."

On this site, GNAP is a reference point for AI Agent Identity, Model Context Protocol, and Agent2Agent Protocol. It names an authorization pattern for software that negotiates access, proves possession of keys, receives bounded grants, and may act across several protected resources.

How It Works

A GNAP flow centers on a client instance, an authorization server, a resource server, a resource owner, and an end user. The client instance sends a JSON grant request to the authorization server. The request can describe resource access, subject-information needs, client identification, interaction methods, and the key material the client will use to prove possession.

The authorization server can grant immediately, deny, or require interaction. RFC 9635 describes interaction through redirects, application-specific URIs, user codes, asynchronous authorization, software-only authorization, continuation requests, token management, and revocation. A grant response can return one or more access tokens, labels, expiration information, management handles, and direct subject information.

GNAP treats continuation as a security object. Continuation access tokens are bound to the client instance's key and are not bearer tokens. The client must sign continuation requests with the appropriate key, and the authorization server must validate that signature before continuing the grant.

Agent Context

Agent systems put old authorization questions under new pressure. A browser agent, coding agent, data-analysis agent, or procurement agent may need temporary access to several APIs, under a human's authority, with different rights for different resource servers. A single static service account is often too broad, while a human-login screen for every step may be unusable.

GNAP is interesting because it starts from negotiated delegation rather than treating software as a fixed pre-registered client in every case. RFC 9635 allows a client instance to present information and key material at request time, while the authorization server applies policy. That does not remove registration or trust decisions. It changes where they can be expressed.

For AI agents, the governance question is concrete: which client instance is acting, for which user or resource owner, against which resource server, with what access rights, which key, which expiration, and what revocation path? GNAP gives protocol vocabulary for that evidence trail, but the surrounding institution still has to define the policy.

Security Surface

GNAP does not make delegated software safe by itself. It defines authorization mechanics. The security value comes from how those mechanics are deployed: proof-of-possession for requests, narrow access rights, resource-server validation, short token lifetimes where appropriate, revocation, continuation protection, and clear separation between client, authorization server, and resource server responsibilities.

RFC 9767, published in April 2025, extends GNAP for resource server connections. It defines methods for resource servers to connect with authorization servers, including token validation, resource-set registration, discovery, and downstream token derivation for chained resource-server calls. That matters for agents because tool chains often cross more than one protected service.

The privacy surface is also real. Token contents, introspection responses, subject information, and resource references can expose more about a user, workflow, or institution than the agent needs. A GNAP deployment still needs data minimization, logging boundaries, retention limits, and incident handling.

Governance Pattern

Source Discipline

Use RFC 9635 for GNAP core claims and RFC 9767 for resource-server connection claims. Use the IETF GNAP working-group page for status context and the IANA GNAP registries for registered parameters and values. Use NIST only for the broader fact that agent identity, interoperability, and security evaluation are live standards concerns.

Do not call GNAP "OAuth 3" or imply adoption where a deployment has not named it. A Proposed Standard is a standards artifact, not proof that a particular agent product uses the protocol correctly.

Spiralist Reading

Spiralism reads GNAP as a grammar of delegated agency. The important move is not that software asks for power. The important move is that the request, grant, key, resource, and continuation become explicit objects instead of disappearing inside a helpful interface.

A tool-using agent should not borrow authority as atmosphere. It should carry a visible grant.

Open Questions

Sources

Return to Wiki