AGNAP is an internal authorization plane between a user or organization and the agent executions acting for it. Downstream services remain unchanged: the vault uses the OAuth token, API key, payment mandate, or other credential they already accept.
The user or organization sets the root agent's permission and the delegation settings. The Authorization Server issues a separate grant bound to the running agent's key. Agents do not share an application token. Child agents receive their own grants, derived from the parent's as described under delegation. The vault remains outside the model and runtime. It checks the grant before it performs an operation.
How it works
Each agent is a GNAP client instance with its own cryptographic key. It requests structured authority from a GNAP Authorization Server (AS) and receives an access token bound to that key. The agent presents the token and a proof over its operation request to the vault: AGNAP's execution boundary and GNAP resource server (RS1).
The vault verifies the token, key proof, operation, arguments, time window, and remaining ceilings. Only then does it use the credential understood by the downstream service. The agent receives the result, never the credential.
When a parent spawns a child, the parent requests the permission that the child
needs. It does not grant that permission. The child becomes a new client
instance with a new key. The runtime provides trusted evidence that this parent
started this child. The Authorization Server derives the final child grant from
the request, the parent grant, the owner's delegation mode and maximum depth,
and the shared task limits. Application code does not construct a second,
parallel tree of authorization sessions to describe the tree the runtime already
owns.
The vault owns the grant state record. Child grants reference the same root
state rather than receiving copied call or spend limits, so concurrent siblings
cannot multiply the task's authority.
Quantitative ceilings such as spend or call counts are conserved across
concurrent siblings by a root grant usage record, not copied into each child.
The vault owns that record, keyed by root grant, limit, partition, and window.
On each call it checks the arguments and reserves against the record
atomically, makes the downstream call once with the referenced credential, and
then settles, releases, or holds. An indeterminate outcome is held and
reconciled, never retried automatically unless the downstream API is
idempotent. The audit record carries the receipt chain and only the result
returns to the agent.
Related work
AGNAP does not claim that gateways, vaults, human approval, or narrowing child
permissions are new ideas. The closest work, and where AGNAP differs:
- Attenuating Agent Tokens (AAT):
offline, holder-derived token chains that narrow tools, arguments, lifetime,
and depth. Revocation and use counting are out of scope, and the tool still
holds the credential.
- Credential Delegation Protocol:
a Delegation Server that vaults credentials and exercises them for a
DPoP-bound token, with strict-subset sub-delegation, chain receipts, and
cascade revocation. Nothing conserves a limit across siblings.
- Delegation Without Trust: measures an
attenuating, workload-bound broker against compromised subagents and replay.
It does not isolate credential custody or enforce shared ceilings.
- AAuth:
gives subagents their own keys under a parent's consent and argues against
GNAP for agents.
- Caracal: the closest implemented
system. It authenticates an Application whose code creates Sessions and
Delegations; AGNAP grants to independently keyed executions with
runtime-proved lineage and conserves ceilings across siblings.
- Amazon Bedrock AgentCore Policy:
checks tool names and arguments outside the agent, with approval, call counts,
and running totals per application-created policy session. The authority unit
is that session, not a keyed runtime process.
- CaMeL and
ScopeGate: enforce outside the model
before effects, but leave open what authority is presented and who holds the
credential.
- AP2:
signed payment mandates the vault could produce or use. Agent-to-agent
delegation is outside its scope.