Lara Trust — Agent Identity Platform
Atlas

The concepts behind the demo

Ten ideas — written for any reader, not just engineers. Every term is explained the first time it appears.

1

Why agents and banks don't naturally fit together

Banks have spent decades building systems designed around one assumption: the person using the account is a human, present, making a conscious decision.

Login systems verify humans. Fraud detection looks for human behavioural patterns. Strong authentication (entering a passcode, approving a push notification) is designed for humans who can read, decide, and confirm.

AI agents break this assumption. An agent is a piece of software acting on someone's behalf. It moves fast, works at any hour, doesn't need to stop and read a warning, and has no intuition about whether something feels wrong. It does what it's been told.

This creates three problems banks haven't had to deal with before:

The agent can be manipulated.
A human might notice a suspicious email and pause. An agent just reads it and acts. Bad actors are already experimenting with hiding instructions inside documents, emails, and websites to make agents do things the customer never intended. This is called prompt injection — and it's a real and growing threat.
The agent can act at scale.
A human making ten payments in five minutes would trigger fraud alerts. An agent doing the same might look different depending on how the system is calibrated. Speed and volume aren't signals of intent for a machine the way they are for a person.
The agent has no legal identity of its own.
When something goes wrong, who is responsible? The customer? The AI company? The app developer? Right now, there are no clear answers — because there's no standard way for a bank to even know what kind of agent it's talking to, who built it, or whether it's behaving the way the customer intended.

Lara Trust addresses all three.

2

Five ways an agent can access a bank

Not all agents are the same. A customer's personal Claude assistant is different from a bank's own embedded AI, which is different from a third-party fintech app the customer connected. Each type carries different trust, different risks, and a different set of questions the bank needs to answer before acting.

The five types are:

Your AI assistant
A customer connects their own AI to the bank. They control what it can do. The bank verifies it and enforces the customer's chosen limits.
Bank-embedded AI
The bank's own AI, running inside its own app. Because the bank built it and operates it, it carries the highest level of trust. It still requires step-up confirmation for unusual actions.
Third-party app
An external company the customer has given access to. Similar to how Open Banking works today for reading data — but extending to actions. The customer consents once; the app acts within that consent.
Delegated access
A named individual or organisation the customer has given specific, limited access to — a financial adviser, accountant, or family member. Time-limited. Scoped. Tied to a verified identity.
Scheduled rules
A standing instruction the customer created. Runs automatically on schedule. No customer present at execution. Consent was given once, when the rule was set up.

Each of these is handled differently in terms of how the agent connects and what trust it's given. But all five go through the same enforcement checks on every request.

3

How authorisation works — the basics

When an agent wants to do something on a customer's behalf, it needs to prove two things: who it is, and what it's allowed to do.

Who it is is handled by an access token — a digital credential, like a signed letter. The token is issued by an identity system (in Lara Trust, this is Authentik — a standard OAuth server). It says: "This is agent X, acting on behalf of customer Y, and it was issued at time Z."

The token contains something called the act claim — a small piece of information that records the agent's own identity separately from the customer's. This matters because a human logging in directly is different from an agent acting on their behalf — and the bank needs to know which situation it's in.

What it's allowed to do is defined by something called a Record of Authority (ROA) — the agent's rulebook. It specifies, for this specific customer and this specific agent: which accounts it can see, which actions it can take, the maximum amounts it can move, which payees are on the approved list, and how long the permission lasts.

The ROA is stored and enforced by the bank — not the agent. The agent doesn't get to decide what it's allowed to do. It makes a request, and the enforcement layer checks the request against the ROA before anything happens.

Why this matters

If the ROA says an agent can move up to £500 and the agent tries to move £50,000, the request is stopped — regardless of what the agent says, regardless of what its token looks like, regardless of whether the instruction came from the customer or from somewhere else entirely.

4

The enforcement layer — what sits between the agent and the bank

In Lara Trust, there's a component called the Border Gateway. It sits between the agent and the bank's actual systems. The agent cannot reach the bank's API directly — every request goes through the Gateway first.

This is a deliberate design choice, and it matters for one specific reason: the agent itself can be compromised.

If enforcement lived inside the agent — if the agent was responsible for checking its own permissions — then a manipulated agent could bypass those checks. An agent told by a fraudulent email to wire money might also be told to ignore its own safety rules.

By making enforcement external — something the agent cannot control or override — the bank maintains a layer of protection that exists regardless of the agent's state.

The Gateway checks every incoming request against three things:

Is the agent authorised?
Does it have a valid token? Is it on the registered list for this customer?
Is the request within policy?
Does it match the ROA — the right account, the right payee, within the right limits?
Does this request need the customer to confirm it first?
Some actions — a large payment to a new recipient, for example — require a fresh confirmation from the customer before they proceed, even if the agent has general permission to make payments.

If any check fails, the request is blocked. The bank API never sees it.

5

Consent — what it actually means for agent access

When people talk about consent in banking, they usually mean a customer clicking "I agree" on a terms page. That's not what consent means here.

For agent access, consent is the mechanism by which a customer tells the bank what an agent is allowed to do — and under what conditions it needs to ask again.

There are two different consent patterns in Lara Trust:

Setup consent
the customer approves a set of permissions once, and the agent can act within those permissions without asking again. This is used for scheduled rules and for routine tasks within a pre-agreed scope. The customer approved the rules; the agent just follows them.
Per-action consent
some actions require the customer to approve them individually, even if the agent has general permission to act. This happens when: the amount is above a certain threshold; the payee is new or not on the approved list; the action is outside the normal pattern for this customer.

When per-action consent is needed, the customer receives a notification — on their phone, in the banking app — with the full context: what the agent is trying to do, how much, to whom, and why confirmation is being asked for. They approve or deny. The agent waits.

This design means the customer stays in control without having to approve every small transaction manually. Routine things happen automatically. Unusual things stop and ask.

6

Know Your Agent — verifying who the agent actually is

Banks spend enormous effort verifying the identity of their customers before they can open an account. This is called Know Your Customer, or KYC.

Agents need something equivalent — a way for the bank to know who built the agent, what it's supposed to do, whether its identity can be verified, and whether it's been used responsibly.

This is called Know Your Agent, or KYA.

In Lara Trust, when a customer connects an agent, the bank checks a publicly available record published by the agent's creator — similar to how a website publishes a security certificate. This record states who built the agent, what it's designed to do, and what level of trust it's been granted by the issuing organisation.

Based on this, the bank assigns the agent a trust tier:

Bank-operated
the bank's own AI. Highest trust, because the bank controls it completely.
Verified commercial
a well-known, commercially available AI (like Claude or ChatGPT) whose publisher has provided verifiable attestation. High trust, customer-controlled.
Third-party registered
a fintech or service provider that has registered with the bank and passed a vetting process. Moderate trust; requires explicit customer consent for each scope.
Delegated
access granted by a customer to a named party. Trust is inherited from that relationship.
Policy-bound
a scheduled rule. The agent executes autonomously, but only within a fixed, pre-approved policy. Lower runtime trust because no human is present.

The trust tier affects what the agent can do by default, what it needs step-up confirmation for, and how quickly the bank will revoke it if something looks wrong.

7

The audit trail — a permanent record of every decision

Every time an agent makes a request — whether the bank approves it or denies it — a record is created.

This record is called an Authorisation Execution Receipt, or AER. It's generated by the enforcement layer (the Border Gateway) — not by the agent itself. This means the agent cannot modify or delete it.

The receipt contains:

  • What was requested
  • Which agent made the request
  • Which customer it was acting for
  • What checks were run and what they found
  • The decision — approved or denied, and why
  • The timestamp
  • A cryptographic signature, so the receipt cannot be altered after the fact
Why this matters for banks

When a customer disputes a transaction — "I never authorised that" — the bank can show exactly what happened. Which agent made the request. What it claimed to be authorised to do. What the enforcement layer checked. What it decided, and when.

When a regulator asks for evidence of appropriate controls on AI decision-making, the AER log is that evidence — already structured, already signed, already complete.

The record exists regardless of outcome. Every allow. Every deny. Every step-up request. All of it.

8

The regulatory picture — existing rules, applied

The UK position on agentic AI in financial services is not "new regulation is coming" — it's existing frameworks being pointed at a new kind of actor. That's a more demanding standard than it sounds: there's no grace period while a bespoke agent-AI rulebook gets written, because regulators have said they don't intend to write one. The infrastructure Lara Trust demonstrates is what answering under the existing frameworks looks like in practice.

PSD2 and Strong Customer Authentication (SCA)
Europe's payment regulation already requires banks to verify customer intent for certain transactions — typically anything above €30, or payments to new recipients. When an agent initiates a payment, the question becomes: does the agent's pre-approval from the customer count as strong authentication? The answer, under current interpretations, is often no. Banks will need to document how agent-initiated payments satisfy SCA requirements — or build step-up flows that do.
The EU AI Act
The AI Act, which came into force in 2024, classifies certain AI uses in financial services as high-risk. High-risk AI systems must have human oversight, maintain audit logs, and demonstrate that their decisions can be explained. An agent making payment decisions on behalf of a customer is a strong candidate for this classification. The AER receipt trail in Lara Trust is exactly the kind of audit log the Act requires.
FCA guidance on AI in financial services
The UK's Financial Conduct Authority has been clear that AI systems in regulated activities must be explainable, auditable, and subject to appropriate controls. An agent that can move money without a clear record of why it was authorised to do so — and a clear way to stop it — would not meet this standard.
IMF: Know Your Agent
The International Monetary Fund published analysis in 2026 calling for KYA requirements in payment systems — specifically the ability to verify and register AI agents that initiate financial transactions. The KYA layer in Lara Trust is a direct implementation of what that looks like.
HM Treasury Financial Services AI Adoption Plan
HM Treasury accepted the independent AI Champions' recommendations in 2026. The direction is adoption-enabling rather than restrictive — which shifts the burden onto firms to demonstrate control, rather than onto regulators to prohibit use cases upfront.
The accountability question, under SM&CR
UK regulators have signalled they will apply existing frameworks rather than write agent-specific rules. Under the Senior Managers and Certification Regime, that means a named individual is accountable for what an autonomous agent does on a customer's account. This makes an agent_owner-style claim, and the receipt trail that resolves to it, an audit answer rather than an architectural nicety.
Consumer Duty
An agent acting on a customer's behalf that produces a poor outcome is still the firm's outcome — the Duty doesn't carve out an exception for "the AI did it". Explainability of the authorisation decision, not just the model's output, is what the Duty reaches: not just what the agent said, but why the bank let it act.

Banks that build agent infrastructure now — identity, authorisation, enforcement, audit — will be ahead of the regulatory curve. Banks that don't will be retrofitting controls onto systems that weren't designed for them, under time pressure, in response to incidents rather than in anticipation of them.

9

The standards underneath this

What you see in this demo rests on a stack of emerging specifications — some finalised, some in active draft, some competing. This is not a mature ecosystem. It is a construction site. That is the point.

The decisions being made in IETF working groups and vendor engineering blogs right now will define how agent identity works in banking for the next decade. Understanding which standards compose, which compete, and which solve different parts of the problem is what separates a PM who can lead this from one who can only follow it.

One distinction matters more than any other on this page: anyone can submit an Internet-Draft. Writing one takes an evening and a text editor — it carries no formal standing on its own. Adoption by a working group is the meaningful signal, because it means a group of implementers has agreed the problem and the approach are worth pursuing together. Several of the most-cited agent identity drafts below have not been adopted by any working group; they are one person's or one vendor's proposal, worth reading, not worth citing as "the standard". Weight them accordingly.

OAuth 2.0 Token Exchange (RFC 8693)
RFC — finalised

The base standard for delegated token exchange. Allows a client to exchange one token for another — used to derive an agent token from a user token. RFC 8693 defines the act (actor) claim in JWTs. Every agent token in Lara Trust carries an act claim documenting which agent is acting on which user's behalf. Where it breaks: RFC 8693 works for single-hop delegation. When an agent delegates to a sub-agent — and that sub-agent delegates further — the single act claim model doesn't scale.

Why it matters for banks: The foundational delegation primitive. Without it, there is no standard way to encode "agent acting for user" in a token.

Status: RFC (finalised, 2020). Widely deployed.

OAuth On-Behalf-Of for AI Agents
draft-oauth-ai-agents-on-behalf-of-user-02
Individual Internet-Draft — no WG adoption

Extends RFC 8693 specifically for AI agent scenarios. Introduces requested_actor (which agent is requesting access) and actor_token (the agent's verifiable identity credential) in the token request. The consent screen can now show: "Claude wants to pay £14.99 to Netflix on behalf of Sarah Chen" — not just "an app wants access."

Why it matters for banks: Without this, the consent screen has no way to surface the agent's identity to the customer. This draft is the foundation for KYA-grade consent UX. Auth0, Okta, and WorkOS have implementation previews aligned to it.

Status: Individual submission, now at -02. No working-group adoption yet — treat implementation previews as bets on the shape, not commitments to this exact text.

Agent Identity Protocol (AIP)
draft-prakash-aip
Individual Internet-Draft — no WG adoption

A verifiable identity credential for AI agents. Analogous to X.509 for machines. An agent publishes a signed identity document at a well-known endpoint (.well-known/aip/). The document includes: agent ID, operator identity, model version, capability manifest, and a cryptographic key. AIP-Delegated extends this for agent-to-agent delegation chains — when Agent A delegates to Agent B, Agent B's credential includes a verifiable reference to Agent A's grant.

Why it matters for banks: AIP is the "KYC for agents" standard. It's what makes Know Your Agent technically implementable rather than a policy aspiration. Lara Trust implements a simplified version of AIP-Core.

Status: Individual submission by Sunil Prakash (independent, not representing a working group). -01 refreshed 19 August 2026, expires 20 February 2027. No production deployments yet.

AgentROA (Route of Authority)
draft-nivalto-agentroa-route-authorization
Individual Internet-Draft — no WG adoption

A cryptographic policy enforcement framework for MCP. Defines the ROA (Record of Authority — what an agent is authorised to do), the AER (Authorisation Execution Receipt — a signed pre-execution commitment), and the ARA (per-hop attestation for multi-agent chains). The key architectural insight: enforcement should be external to the agent's execution context. An agent running in a compromised environment can be prompted to do anything. A Border Gateway enforcing the ROA externally cannot be overridden by a prompt.

Why it matters for banks: This is the principle behind Lara Trust's Border Gateway — and why the £50k prompt injection scenario works as a demo. Lara Trust is a full reference implementation.

Status: Individual submission by Joseph Michalak, Nivalto Inc. — not a working-group document. -01 dated 15 April 2026, and it expires 16 October 2026. Said plainly: unless it is refreshed before then, the draft this Gateway cites will lapse.

A2A (Agent-to-Agent Protocol)
Open specification — not IETF

A protocol for agents to discover, communicate with, and delegate to other agents across organisational boundaries. A2A defines agent cards (published capability manifests), task negotiation (structured request/response between agents), and delegation tokens. Relationship to MCP: MCP is the protocol between an agent and a tool. A2A is the protocol between an agent and another agent. They compose: an orchestrating agent speaks A2A to coordinate sub-agents; each sub-agent speaks MCP to call tools. Originally published by Google in 2025; Google donated the project to the Linux Foundation, where it is now the Agent2Agent Protocol Project.

Why it matters for banks: Multi-agent financial workflows require agents to delegate to specialist sub-agents across model boundaries. A2A is the emerging standard for how that delegation works, and it now has the neutral governance to back that up.

Status: Open specification, v1.0, governed by the Linux Foundation with 150+ participating organisations. In enterprise production use. No IETF standardisation, and none is being sought — this is a Linux Foundation project, not a wire-protocol RFC track.

Biscuit tokens
Open specification — not IETF

An alternative to JWTs for agent delegation chains. Uses a logic-based (Datalog) authorisation language embedded directly in the token. Key innovation: offline attenuation. With JWTs, delegating a narrower scope requires a roundtrip to the authorisation server. With Biscuit, the agent attenuates the token offline — it adds a new logic block that further restricts what the token allows. The sub-agent gets a token that is cryptographically bound to those constraints and cannot be modified to widen them.

Why it matters for banks: Elegant solution for multi-hop delegation without server roundtrips. Production use at Clever Cloud. Worth watching as a JWT successor for agent delegation specifically.

Status: Production use at Clever Cloud. IETF draft in progress. Not yet in mainstream banking toolchains.

GNAP (Grant Negotiation and Authorization Protocol)
RFC 9635 (finalised 2024)
RFC — finalised

The "OAuth successor" designed from scratch with delegation, non-browser clients, and structured access descriptions in mind. Rather than OAuth's implicit assumptions (a human in a browser approving a scope string), GNAP treats every grant as a structured negotiation: the client describes what it needs, the server decides what it will give, the human approves a specific grant — not a scope string. GNAP's structured access descriptions are a much better fit for agent consent than flat OAuth scope strings.

Why it matters for banks: The right answer in 3–5 years; not yet. Zero ecosystem. No major IdP ships GNAP in production. Lara Trust extends OAuth 2.0 pragmatically and is designed to migrate when the ecosystem catches up.

Status: RFC 9635 (finalised). Ecosystem adoption: minimal. Reference server implementations exist.

MCP Authorization — 2026-07-28 specification
Open specification — not IETF

A real enterprise authorization story for MCP. Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents (CIMD) — a client publishes its identity as a document at a stable HTTPS URL instead of registering at runtime. RFC 9207 issuer (iss) validation is now required, closing the authorization-server mix-up hole. Client credentials are bound to the issuer that minted them, so a credential from one authorization server can't be replayed against another. application_type is declared at registration, so desktop and CLI agents get correct localhost redirect handling instead of a workaround. Enterprise Managed Authorization joins the formal extensions framework for centralised policy across an organisation's MCP deployments.

Why it matters for banks: This removes the most common objection to putting agent tooling in front of a bank's systems — "MCP has no real auth story". Said plainly: this prototype's MCP server predates the July spec and still uses Dynamic Client Registration; migrating to CIMD is on the roadmap, not done.

Status: Published 28 July 2026 by the MCP steering group as part of the protocol specification. Not an IETF document — governed by the Model Context Protocol project itself.

OAuth Transaction Authorization Challenge
draft-rosomakho-oauth-txn-challenge-00
Individual Internet-Draft — no WG adoption

A protected resource can refuse a request and return a signed JWT challenge describing the exact operation attempted. The agent relays that challenge to the authorization server unchanged — it cannot forge or alter it. The authorization server decides who is entitled to approve the operation, obtains that approval, and issues a token whose RFC 9396 Rich Authorization Request details are bound to that one transaction. The agent retries with the new token, and the resource checks that the bound details match exactly.

Why it matters for banks: This is the difference between consent the agent asserts and consent the resource can verify. An agent telling you in its own chat window that you approved something is not authorisation, because nothing downstream can check that claim; a signed challenge the resource itself issued is. Said plainly: Lara Trust's Consent Engine implements this pattern in proprietary form, built before this draft existed. Aligning it to the draft's exact challenge/response shape is planned, not yet done.

Status: Submitted 25 June 2026. Authors: Yaroslav Rosomakho (Zscaler), Brian Campbell (Ping Identity), Karl McGuinness, Pieter Kasselman (Defakto Security). No working-group adoption yet.

AuthZEN Access Request and Approval Profile (AARP)
Open specification — not IETF

Standardises the case where a policy decision point can't yet say yes or no because a prerequisite is unmet — a human approval, a fresh consent, an attestation, a risk assessment. Instead of a flat deny, AARP defines how to answer "pending, and here's what would satisfy this".

Why it matters for banks: Every agent authorisation gateway that returns a binary allow/deny, including this one's Border Gateway today, is missing the honest third answer. AARP gives that third answer a standard shape.

Status: Approved by the OpenID Foundation AuthZEN working group, 15 June 2026. This is an OpenID Foundation working-group draft — it is not an IETF document, which is why it carries the open-specification label here rather than the IETF working-group one.

AuthZEN Profile for MCP Tool Authorization (COAZ)
Open specification — not IETF

Maps MCP tool calls into AuthZEN's Subject-Action-Resource-Context model, so policy decision points sitting behind API gateways and service meshes can authorise individual tool calls using the same interop layer as everything else they police.

Why it matters for banks: This is the interoperable version of what the Border Gateway does proprietarily today — mapping a tool call to a policy decision. It may become the standard route others take instead of a bespoke gateway.

Status: Approved by the OpenID Foundation AuthZEN working group, 15 June 2026 — same standing note as AARP: an OpenID Foundation working-group draft, not an IETF one.

OAuth Identity Chaining
draft-ietf-oauth-identity-chaining
IETF working group draft

Combines RFC 8693 token exchange with the RFC 7523 JWT authorization grant so the original requester's identity and authorisation context survives a crossing between trust domains — for example, from a bank's agent into a third-party vendor's system. The companion draft-fletcher-transaction-token-chaining-profile (-02 over summer 2026) adds claims minimisation: internal authorisation context is stripped out before the grant crosses the organisational boundary, so the vendor sees only what it needs.

Why it matters for banks: This is the standards-track answer to multi-hop delegation, which the RFC 8693 act claim alone cannot carry once more than one hop is involved — exactly the gap in this prototype's multi-agent vignette today.

Status: IESG-approved, heading to Proposed Standard — this is a genuine IETF working-group document, one step from finalised.

CAEP Interop Profile 1.0
Open specification — not IETF

Continuous Access Evaluation Profile — a standard shape for propagating real-time revocation events (a session killed, a token invalidated) across every relying party that holds a grant, rather than each one finding out on its own schedule.

Why it matters for banks: Long-lived agent sessions make this non-optional: killing an agent's access in one place is only meaningful if every system it touched hears about it immediately. This prototype's revocation is local today, not propagated.

Status: Recommended for OpenID Final Specification, with public review open through 25 September 2026.

Standards map — how they compose
CONSENT LAYER              IDENTITY LAYER         ENFORCEMENT LAYER
────────────────           ──────────────         ─────────────────
OAuth OBO draft        →   AIP (agent ID)     →   AgentROA (ROA + AER)
RFC 8693 (act)         →   Biscuit (chains)   →   Border Gateway
Txn Challenge draft    →   A2A (multi-agent)      Audit trail
AARP (pending state)       Identity Chaining  →   COAZ (MCP tool authZ)
CAEP (revocation)           (cross-domain)
GNAP (future)

OAuth / GNAP / Txn Challenge / AARP handle the consent and token mechanics.
AIP / Biscuit / Identity Chaining handle the identity and delegation chain.
AgentROA / COAZ / CAEP handle enforcement, audit, and revocation.
These three layers are independently specifiable — no single vendor owns this stack.
The honest assessment

Most of these standards are drafts. Several overlap. Some will be superseded. The ecosystem is moving fast enough that this page will need updating quarterly.

That is not a reason to wait. The banks that engage with these standards now — that have engineers on the mailing lists, PMs who can read a draft and know what it means for their architecture — will define what "agent-safe banking" means. The banks that wait for standards to stabilise will implement whatever the first-movers locked in.

Lara Trust is a bet that the architecture will still be coherent when the dust settles, because it is built around the right principles — external enforcement, verifiable agent identity, structured consent, forensic audit — not around any single draft that might be replaced.

What this prototype does not do
  • The MCP server predates the 28 July 2026 specification and still uses Dynamic Client Registration, not Client ID Metadata Documents.
  • DPoP is implemented but optional, not enforced — a stolen bearer token would still work today.
  • The consent flow is proprietary in shape; it is not yet aligned to the OAuth Transaction Authorization Challenge draft.
  • Multi-hop delegation is demonstrated conceptually. The cross-trust-domain hop is not implemented against the identity chaining draft.
  • Gateway decisions are binary — allow or deny. There is no AARP-style "pending, satisfy X" state yet.
  • Revocation is local to this stack, not propagated via CAEP to other relying parties.
Further reading

Last updated: August 2026. Standards move fast. If something here is stale, open an issue on the repo.

10

What changed — a running log

The standards picture underneath this prototype moves faster than a demo can keep up with. This log is how that gap stays visible instead of quietly going stale — an entry every time a delta-log pass turns up something that changes what's on this page. If something below reads as out of date, that's worth an issue on the repo, not a private correction.

31 August 2026
Closed the three biggest gaps the previous entry called out. The Consent Engine now speaks the OAuth Transaction Authorization Challenge draft for real: the Border Gateway signs a JWT describing the exact operation, the Consent Engine verifies it before showing Sarah anything, and approval returns RFC 9396 authorization_details bound to that one transaction — replayed for a different amount or payee, or reused twice, and the gateway rejects it (there's a test proving both). The Border Gateway's decision is now AuthZEN-shaped: "pending" with a list of unmet prerequisites, not a bare step_up flag — "step_up" stays as an accepted alias so nothing downstream broke mid-migration. DPoP moved from optional to mandatory end to end, which meant actually wiring proof generation into the MCP server and the Claude agent — both had the code sitting unused (or, for the agent, missing outright) — not just flipping a config flag. The MCP server also now serves a Client ID Metadata Document at a stable URL, aligned to the 28 July spec, though Authentik 2024.12 can't yet resolve one as a client_id, so it describes an identity nothing live uses yet. RFC 9207 issuer validation stays honestly unimplemented: audited the whole codebase and there is no authorization_code flow anywhere to attach it to.
29 August 2026
The MCP steering group published a real authorization story on 28 July — CIMD replacing DCR, mandatory issuer validation, issuer-bound credentials — which this prototype does not yet implement. The OAuth Transaction Authorization Challenge draft is the single most important addition: it's the standardised version of this Consent Engine, co-authored by a Ping Identity engineer. Two AuthZEN drafts (AARP and COAZ) give agent gateways a "pending" answer and a standard tool-call authorisation shape, neither of which this Border Gateway has yet. OAuth Identity Chaining cleared IESG review, giving the multi-hop vignette a near-standard route it currently hand-waves. CAEP entered final review, covering the cross-system revocation this stack doesn't yet propagate. Separately, and stated openly rather than corrected quietly: several drafts on this page — the OAuth On-Behalf-Of draft, AIP, and AgentROA — were previously labelled "Active IETF draft" when they are individual submissions with no working-group adoption; that labelling has been fixed, and AgentROA's current draft expires 16 October 2026.
June 2026
Original build shipped: Authentik-issued tokens carrying the RFC 8693 act claim, a Border Gateway enforcing per-agent Records of Authority, signed Authorisation Execution Receipts, and a push-consent engine for step-up approval. The thesis at the time was that external enforcement, verifiable agent identity, structured consent, and forensic audit were the right architectural bet regardless of which individual draft eventually won — a bet this refresh has not needed to change, only extend.