[OAUTH-WG] Comment on OAuth WG Recharter: Ward-Centric Authorization and Exhaustible Authority as Missing Primitives

Paul Knowles <Paul@secours.ai> Fri, 05 June 2026 01:30 UTC

Return-Path: <Paul@secours.ai>
X-Original-To: oauth@mail2.ietf.org
Delivered-To: oauth@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id F2E1AFB60377 for <oauth@mail2.ietf.org>; Thu, 4 Jun 2026 18:30:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1780623006; bh=KtKX3UOU+HKUAd9BRezP3RR3BpWXi1gGvUkPSudsgcM=; h=From:To:Subject:Date; b=L/oJDs/dTMOzxavRgiia6aUXMaxp2n3Nm0qtLXvxDrwJn/UXhtBwwMVVWmQUaH4/o nROGXpXqrB9Idabo7LA36was6hRrlOJODsXVqh2MjhiC6NbWCkYsBoCjOM9kGP0I3F 4OeomUI7/J6++jPGp45aw9vDF2MQGNxV36G+BjDM=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=secoursio.onmicrosoft.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxmrnBwZ-hFk for <oauth@mail2.ietf.org>; Thu, 4 Jun 2026 18:30:05 -0700 (PDT)
Received: from SN4PR0501CU005.outbound.protection.outlook.com (mail-southcentralusazon11021112.outbound.protection.outlook.com [40.93.194.112]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 5F6DCFB60370 for <oauth@ietf.org>; Thu, 4 Jun 2026 18:30:04 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=W5xiFc7wQwmZ55H3JdcwILjFfVfcSoljCLMWDYjwo490kEm2LGd8B8xfi6fq0YpueUBJ4SIBegDV5XTA57mUDCf98v6xwyDqv/7u+XyMDD1t0trw9EOFUlN81JdG0S/JjSxyAl7ccIy/XC22Z1OshikK9SOHK2ohXR0lirTHkWIyDUO/PCa8KHw8do8Pw1BxuSFAW8eB6ZVPu0TroATK7Rsh3uHqP0/TL2t7s9KEK2RzEm3Zo2hlhE2v613nKflpiHnegHjGFmHEkn0CGeOeJNhPiuzVMu1DA6sTfeiAgluNV85XKA9ijnJYPDzFgOZKBdEeOhWD/B6CDx8YmWx0SQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KtKX3UOU+HKUAd9BRezP3RR3BpWXi1gGvUkPSudsgcM=; b=dSGaFbeY61UFuS25ZPz/T9v82pZkfNdKYZPtb3Uu8Czq0fPZEOms/2PyWIgRyAPaeD99NHeqZNCSEXaO2KWmbFV3t0XTb2qt1drofxiA1qyn7CQ2+Amz0NkNj3eNzhZwtn1d+trsguIv9+LMnBXpU+TI8paHJe1B0AUmgcVCpvBXZ/EMYbBBADo9i42se7xvWT6+LUIpt1xjb0qWrz+wRh/4QC95NnFFSckie8ckziCaDa6aSFxUBWo++/AlnUVpJ9tB7euq9W6DsBLe+rQF7ag4IStE9TFGbFzyxhvLBkt4rvC1vlOSmmkikD2m3MBnadjBMdQrd3SWIKlVs9y2PQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=secours.ai; dmarc=pass action=none header.from=secours.ai; dkim=pass header.d=secours.ai; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secoursio.onmicrosoft.com; s=selector2-secoursio-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KtKX3UOU+HKUAd9BRezP3RR3BpWXi1gGvUkPSudsgcM=; b=mMhxnzHLXaUg6buVVJDGHdkX2XO/Vb8OgXQ6aU/y7Jusfk+sp2BG6zqJSYNpenGA620pO/oCp4ojj8KcB7Y8vlbhy0wtxW9fXTiTQmYBXkAAzhNwoWKGaH1QAQZxVhveMkC0aPWJzmRG2Yy5oWL1nuN99Pq5uaNTYQC9kPTAZGI=
Received: from LV3PR04MB9491.namprd04.prod.outlook.com (2603:10b6:408:285::17) by CYYPR04MB9049.namprd04.prod.outlook.com (2603:10b6:930:bf::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.92.7; Fri, 5 Jun 2026 01:29:55 +0000
Received: from LV3PR04MB9491.namprd04.prod.outlook.com ([fe80::bc9b:79dc:2928:7fb0]) by LV3PR04MB9491.namprd04.prod.outlook.com ([fe80::bc9b:79dc:2928:7fb0%4]) with mapi id 15.21.0092.007; Fri, 5 Jun 2026 01:29:55 +0000
From: Paul Knowles <Paul@secours.ai>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: Comment on OAuth WG Recharter: Ward-Centric Authorization and Exhaustible Authority as Missing Primitives
Thread-Index: AQHc9IlSA1vr7yReU0qytTc9ypSbTg==
Message-ID: <LV3PR04MB9491EF61064820C2EC0FD09FBA112@LV3PR04MB9491.namprd04.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=secours.ai;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: LV3PR04MB9491:EE_|CYYPR04MB9049:EE_
x-ms-office365-filtering-correlation-id: e80306a6-1b8b-4684-ab80-08dec2a1f2ff
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|376014|366016|8096899003|18002099003|38070700021|6133799003|3023799007|56012099006;
x-microsoft-antispam-message-info: YqJSYpGVoU9yca8zZElcwrGD+d9tdwBhSPmDoigwQDrHOz+Msi4OodsPoWCzcbfB8j9zpWhuPj2qe5/AXio5vPBt2vb2yhRUWmAAqBmbNzf1D08xAsOO+xduwIb1lRIivxzVLaBFLE6MjDSrDFASJEilnmrGCHLQw7i2m1zt0FP+Ll5ObfUMnb30AjOQ41r+BRmbjG9vF6oa0DND73Zk/f1gi8U1QgOPfnEh6q+BQkeDujRh3uH2FdIOApzUtfat2knCJFdTbdqHCeKEUSEGg8MSqo4PfGP1TlW6UuPVIOer//y7Ydi3oWu/F4xwi6Mpyveq7Um+vLUVm7TKRBEDo5SVzZX2MBPGkg09KKrvtVv3OHWwMlCB2s2EN5TJk9Iw7mXJqndE4Lmc0o4tLpUAkgqHiWf+K6ywesC/825Ia44lJDrluPTOvYFDd7OXWFZGOnfFBsrGyu8dqJL+DwjHX+KoY4id8h3Fbf8Enkh2mXq5AIcx5v7bZjpNkXIXiTTZ3GnVQQjOIsyn/scpCPDo/cdbx0ZbizerswLf1mJ7rS+CQ4ayil7V01qWgMNlRidOCXCHCzTuDa2utA6C/8ENDOA8jU4mth0l6DI7UxjXtdagjxe4MpDIbV5/CHCK79sUhPcr2zPYhDfhliN0SjVAaW5qivt1grm5NndOpzD12ctVOCUyyRBxbFLFVmtkf5FVS1MU5TtD4a8FLzlutow82niBBdgqGIUtJKDBcu8oDnGzvXJwuwQVjc5KC/gZxrym
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:LV3PR04MB9491.namprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(366016)(8096899003)(18002099003)(38070700021)(6133799003)(3023799007)(56012099006);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: dOOxoMI7xVYruggsZrYP2CJ+LIOIua6iry1hUR4lQ+cEJQK1YZLIQ4VdSI7z32aZYW9ZXYpQYBmrtIlD9I24nvlVPN25PXn6xK9x3/Fv8UTRrNuqG79naAjTvRQGc7ztQXdaV1YM2+u7RZIvigcH4Ji/6J4oynuAumWJKsFI3LIqdtxYNQbZ/EYcnzwPIVgxCMQT9rzk4fAouuTuKwLznv8deU2oWX02i/rsfhBvpllvZWfVG6nsRI301NmonoO+d3swUe7D4uoX06MBCtBtD+w2RFjdQyKQs4aHdT5r6lYKtf7VrSIXBIPLmXZjl0slgzVcjuBOGO0EF8XPxeb/4tY2yqX1eBJ+7kpqVilLyC3V8vP/M/uXMW1xzEAdqC6RkfaSVnGZDYcp4gAN53U/v5TmYx3Sv3HJC56Afz6lRU2jLX2PPxsHIgbqKH3LkzPfzD6KVVgPyQqpii97e4hvVMW+9P4hOEp9a8d/eOhMWaqMagOi5OWSpHD80EMMblxZpFbZd6sjvefTuyf7DMcZFjPEM12G1KnrFwqEmXsg9ORPDU/OVgOr1JBUEQ1kW2E4gntdOlM2/JMSNIQrpKkOtl7cgzasuwz1oQw5Ns0jYNy+Z2TIyD4bMl8atybmSMCoHC9osZOT6A3KYX7XlHIys8lU7Xyioe1HX7ta5ezsZt8pQkGGzouGfUKqwUl/q8EHfqNm8oa96QM+weDvAb0oifme69gdSZ5zFkbyG4cea99n0DrrckQzf5ZEoHls/ko0nhhZk/zUrzMFxohsK5/T3q/YW2uXvzR+FpeaXREyCxlg4cZw88wlsMCkFpwSNWhYoGejCUTk8WYK4kGhtTtaLV/IylJJL09P+k/DVBuznVJR0QoV7AdXEe1YWSrQ9AMGzR4Phk2Ze9zBJU9gXvYfm9TG8/xTMcHbWZxN9NYS/j/GtlyFzXsSzMEtEFMjHONE44zHGXXF+8lUZfV1loSFcvFdEiVZfj8Mry/ACgZF0KXF2wg/JvuBqVkocGfymCeOu7U90UTOixf2a/w/xKy4HFyDfPzlu39fnVwg9evpBQXF4sw/xKXfzCX6ROn/kzd25WfeoV0QKJ+9U3JcPc99Yios9r8S794ZEc32WG7/O57jUKOmhlBm4xOw9s8oCDFr752GvRERRm6VMKs/lQspbX7otHd+r7BLW735zWmWDFaa1aa/bYaLYHq2Yr9FEBqc6RKjJPJfFEu/dBtLIxS/2mz4GCJyEoadnQluhSdqVOx89PlV6y9xnJp2z7LdsrxwcjaRXKLKzgvY7E4GWPl269GI/XQnki6CTsIGdZsSbLXJlnJ0CghLX/xPEIdA7zp5NbanJxOL6NV2crUYb3hGNDuQ3wF2uA+bBaBxGLvrG0Rmp51Jd3c5jG4LhXas89HCxkE9P9OVWe0fg5SaDEDbOHa3cytzdhLWtRp+pOU3uIztUgubcN6NyFQwE99fYpyYzG9T5HivP02kxthqX7u9nC/x0bQH9d+CTNYN+tsVt5au6GMqDLIUJEyv0LkiGqZTLXGdrIyVIgoYoETQXsBg5zKumhOcmkzCbghSfl9o2W0a7zUtWjZsNiwClhcp0R2zXDOg9xDzANxal5TMyG/mJRerqWzhwxDwN5YiKL3jjqy6cHe3q2HjMiBHFNzmSBY3rkRZf6fbYF6py2VBzcYUQAJ9u4JduXwg0LYo6vqBn+A=
Content-Type: multipart/alternative; boundary="_000_LV3PR04MB9491EF61064820C2EC0FD09FBA112LV3PR04MB9491namp_"
MIME-Version: 1.0
X-OriginatorOrg: secours.ai
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LV3PR04MB9491.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e80306a6-1b8b-4684-ab80-08dec2a1f2ff
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2026 01:29:55.5434 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b0f69723-6b91-4e46-9eb7-2bdc6acb52bf
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: XEPMNnvReA0SYinCIES++WVxarekTpB/BlWxgLwjo5fnTTfr4YFF3rJRUM60ARyU
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYYPR04MB9049
X-MailFrom: Paul@secours.ai
X-Mailman-Rule-Hits: nonmember-moderation
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-oauth.ietf.org-0
Message-ID-Hash: NJPGW4TGUZTJYTAESEZYG3MIIVMQQAVM
X-Message-ID-Hash: NJPGW4TGUZTJYTAESEZYG3MIIVMQQAVM
X-Mailman-Approved-At: Sat, 06 Jun 2026 07:28:42 -0700
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [OAUTH-WG] Comment on OAuth WG Recharter: Ward-Centric Authorization and Exhaustible Authority as Missing Primitives
List-Id: OAUTH WG <oauth.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/pidJVk6eKvB22A2XxPr3E-KwQEc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Owner: <mailto:oauth-owner@ietf.org>
List-Post: <mailto:oauth@ietf.org>
List-Subscribe: <mailto:oauth-join@ietf.org>
List-Unsubscribe: <mailto:oauth-leave@ietf.org>
Date: Fri, 05 Jun 2026 05:52:55 -0000
X-Original-Date: Fri, 5 Jun 2026 01:29:55 +0000

Comment on the OAuth Working Group Recharter
Submitted to: oauth@ietf.org | iesg@ietf.org
Date: June 5, 2026
From: Paul Knowles, CEO and Chief Architect, Secours.ai


AUTHOR IDENTIFICATION AND INSTITUTIONAL BASIS

Paul Knowles is the CEO and Chief Architect of Secours.ai and the inventor of the Overlays Capture Architecture (OCA), the data capture architecture selected by the Swiss government as the preferred architecture for the Swiss national e-ID programme. A US preliminary patent for Role-Based Containment (RBC), a Ward-centric governance architecture for autonomous systems, was filed on January 26, 2026. The author is a contributing member of the American Bar Association's Autonomous Systems Governance Working Group (ASG-WG), a joint initiative of the Risk and Trust Management Committee of the Science and Technology Law Section and the Cyber and Technology Committee of the Business Law Section, which is actively examining governance models for autonomous systems including the Ward-centric model described in this comment. The views expressed here are those of the author and do not represent the formal position of the ABA or the ASG-WG.

This comment is submitted in response to the OAuth Working Group recharter proposal currently under IESG review. It identifies a structural gap in the scope of the proposed recharter and requests that the new charter explicitly include exhaustible authority as a primitive to be evaluated alongside token-based delegation.


THE STRUCTURAL GAP IN THE CURRENT SCOPE

The body of individual drafts proposing how human authority delegates to AI agents represents technically serious and rigorous work. The delegation mechanics drafts in the RFC 8693 family address real weaknesses in the current token exchange model: chain splicing, the absence of monotonic attenuation, and the lack of runtime identity for dynamically spawned agents. The audit and compliance drafts, particularly the Kuehlewind cross-layer audit architecture, represent a genuine advance in giving regulators a complete accountability story for agent actions. This comment does not challenge the quality of that work.

It identifies a gap that none of the thirty-two individual drafts currently in the corpus address: the action-time authority question.

Every draft in the current corpus answers a version of the same question: how does authority move from a principal through a delegation chain to an agent? The answers vary in sophistication, from simple token exchange to cryptographically verifiable actor chains to monotonically attenuating capability tokens. But the architectural assumption underlying all of them is identical: authority is granted at the point of admission and persists until it is revoked, expired, or attenuated. This is the standing authority model. It was designed for human-speed principals operating within bounded organisational contexts. It has three structural properties that make it inadequate for autonomous systems operating at machine speed across organisational and jurisdictional boundaries.

First, standing authority accumulates. A token that has been attenuated at each delegation hop is still a standing permission. It persists across multiple actions. It can be exercised repeatedly within its validity window. The attack surface it creates scales with the system's uptime, not with the specific actions the system is authorised to take.

Second, standing authority cannot evaluate present admissibility. A permission granted at step zero of an action chain cannot evaluate whether the conditions that justified that grant still hold at step seven. The token does not know that the Ward's account balance has changed, that a vendor relationship has become legally sensitive, or that a prompt injection payload has entered the chain between initiation and effect. It knows only that the grant has not been revoked.

Third, standing authority produces accountability records rather than legitimacy proofs. The Kuehlewind audit architecture produces four record types -- Interaction, Action, Delegation, and Authorization Transition -- that together give regulators a complete retrospective account of what happened. This is valuable and necessary infrastructure. But it does not satisfy the requirement that the EU AI Act's Articles 12 to 14 impose: action-level records of human authority exercise at the moment of effect, not system-level documentation of oversight design. A peer-reviewed compliance analysis published in April 2026 mapping the AI Act's essential requirements against the current governance tooling market states this explicitly: runtime enforcement tools answer the question of permission but not authority, and the essential requirements of Articles 12 to 14 can only be demonstrated through action-level records of human authority exercise, not through system-level documentation of oversight design. [1]

The gap between what the Kuehlewind architecture provides and what Articles 12 to 14 require is the precise gap that this comment asks the recharter to scope.


THE MISSING PRIMITIVES: WARD, WARRANT, AND WARDEN

The primitives required to close this gap are not novel inventions. They are the application of legal doctrine refined over four centuries in property law, agency law, and trust law to a problem that digital infrastructure has never previously been asked to solve.

The American Bar Association's Autonomous Systems Governance Working Group is formally examining these primitives for legislative and regulatory use. A working glossary has been submitted to the ABA for consideration. The following definitions are grounded in that legal doctrine and are proposed here for consideration by the OAuth WG as foundational vocabulary for the agent authorization problem space.

Ward. The party whose proprietary interest generates the governance chain and who directly bears the consequences of autonomous action. The Ward is the consequence-bearer: the person or entity whose assets are modified, whose payments are processed, whose data is accessed, and whose interests are affected by every action in an agent's execution chain. All authority in a Ward-centric architecture derives from and must remain traceable to the Ward's protected interest. The Ward is the concept that does not appear in any current IETF agent authorization draft, and its absence is the structural explanation for why the standing authority model cannot answer the action-time governance question.

Warrant. A bounded, specific, exhaustible grant of authority to take one specific action, on behalf of a specific Ward, under conditions that obtain at the moment of effect, evaluated at the execution boundary, and consumed immediately upon execution regardless of outcome. A Warrant is not a token with a shorter lifetime. A token persists across multiple actions within its validity window. A Warrant exists only in the interval between admissibility evaluation and execution and ceases to exist the moment the action executes. It cannot be replayed. It cannot be inherited by the next action in the chain. It cannot be exercised by any party other than the Warden on behalf of the Ward at the specific moment for which it was minted. The next action in the chain requires a fresh Warrant, evaluated against current conditions.

The distinction between a Warrant and an attenuated token is not a matter of degree. It is a structural difference in kind. An attenuated token narrows the scope of standing authority. A Warrant eliminates standing authority entirely. The former makes ambient power smaller. The latter makes ambient power impossible.

Warden. The enforcement mechanism that evaluates proposed actions at the execution boundary against the Ward's current interests, issues a Warrant if and only if the proposed action is within the authorised scope of the Ward's protected interest under present conditions, and consumes the Warrant immediately upon execution. The Warden is not a policy engine that intercepts actions after the agent has decided to take them. It is the governance primitive that determines whether an action may produce effect at all.

These three primitives together constitute the Ward-centric governance architecture. They are grounded in property law's concept of the conveyance moment, where validity is evaluated at the instant of transfer rather than retroactively; in agency law's doctrine of ultra vires action, where authority exercised beyond delegated scope is void regardless of the identity of the actor; and in trust law's guardianship standard, where the duty to protect is assessed against the Ward's present condition rather than historically fixed intent.


WHY THIS MATTERS FOR THE RECHARTER SCOPE

The OAuth WG recharter is occurring at the precise moment when the technical vocabulary of agent authorization is hardening. The individual drafts in the current corpus introduce terms, claim names, and define primitives that will shape the working group's output. Three independent drafts are already contesting the name AIP simultaneously, which is a structural indicator of how fast the field is moving and how consequential naming decisions are at this moment.

The Ward-centric vocabulary is not in any of these drafts. If the recharter scope does not explicitly include exhaustible authority as a primitive to be evaluated, the working group will produce specifications built entirely on the standing authority model. Those specifications will create a JSON-LD context with @protected flags on terms that cover adjacent but not equivalent ground to the Ward, Warrant, and Warden concepts. Once that vocabulary is locked in a W3C namespace or an IETF RFC, introducing the Ward-centric primitives requires overcoming the processing errors and compatibility constraints of an established standard rather than contributing to an open conversation.

The consequence is not merely technical. Autonomous systems are being deployed at consumer scale right now. On May 12, 2026, Google announced Gemini Intelligence for Android, a system that executes multi-step action chains across calendar, email, payment, and messaging services on behalf of users with approximately three billion active Android devices globally. The governance model for every action in every chain on every one of those devices is a single confirmation prompt presented before the chain begins. That prompt answers one question: did you initiate this task? It cannot evaluate whether conditions at step zero still hold at step seven of a chain. The Ward-centric architecture closes that gap. The standing authority model cannot.

The OWASP Agentic Security Initiative's Top 10 for Agentic Applications, published in December 2025 and reviewed by representatives from NIST, the European Commission, and the Alan Turing Institute, identifies tool misuse and privilege escalation as the most frequently reported agentic threat category and concludes that mitigation requires controls at the execution layer rather than the model layer. [2] That conclusion is an independent empirical confirmation that the execution boundary governance primitive is the missing layer in the current agent security architecture.


SPECIFIC REQUEST

This comment respectfully requests that the OAuth Working Group recharter explicitly scope the following items for consideration by the new working group.

First, exhaustible authority as a primitive to be evaluated alongside token-based delegation. The recharter scope should acknowledge that the standing authority model, however sophisticated its delegation mechanics, cannot satisfy the action-time governance requirements of autonomous systems and should explicitly charter work on authorization primitives that eliminate rather than manage standing authority.

Second, the Ward as a foundational concept in the agent authorization architecture. The consequence-bearer whose proprietary interest generates the governance chain is currently absent from all agent authorization drafts. No specification that omits the Ward can answer the question of whose interests bound the authority being delegated.

Third, the execution boundary as a governance surface distinct from the admission boundary. Current drafts govern what an agent is permitted to do at the point of admission to a system or service. The execution boundary, where each proposed action must be evaluated against current conditions before it may produce effect, is a different governance surface that requires different primitives.

Fourth, explicit engagement with the EU AI Act's essential requirements under Articles 12 to 14 as a design constraint on the compliance architecture. The Kuehlewind audit architecture is the most sophisticated compliance story in the current corpus. It does not yet close the gap between system-level documentation of oversight design and action-level records of human authority exercise that the EU AI Act requires. The working group should scope this gap explicitly.


REFERENCES

[1] Nannini, L., Smith, A.L., Maggini, M.J., Panai, E., Feliciano, S., Tiulkanov, A., Maran, E., Gealy, J., and Bisconti, P., "AI Agents Under EU Law: A Compliance Architecture for AI Providers." arXiv:2604.04604v1 [cs.CY], April 7, 2026. Section 9(10) identifies the absence of action-level authority governance infrastructure as both a market gap and a compliance gap under Articles 12 to 14 of EU Regulation 2024/1689 (AI Act).

[2] OWASP GenAI Security Project, Agentic Security Initiative. "OWASP Top 10 for Agentic Applications 2026." December 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

[3] American Bar Association, Resolution 604, adopted at the ABA Midyear Meeting, February 6, 2023. Establishes that human authority, oversight, and control must be maintained over AI systems; that organizations must be accountable for legally cognizable harm caused by AI; and that legal responsibility may not be shifted to an algorithm.

[4] Brooks, M., "A smarter, more proactive Android with Gemini Intelligence." Google, The Keyword, May 12, 2026. https://blog.google/products-and-platforms/platforms/android/gemini-intelligence/


CONTACT

Paul Knowles
CEO and Chief Architect, Secours.ai
paul@secours.ai

This comment is submitted as an individual submission. The author welcomes direct engagement from Working Group participants, draft authors, and IESG reviewers on the architectural arguments presented here.