From e5ad7a2a6220e790294ec299abeb19e0b43139c8 Mon Sep 17 00:00:00 2001 From: Egor Merkushev Date: Sat, 11 Jul 2026 12:12:20 +0300 Subject: [PATCH 1/3] Define authority containment and credential binding --- drafts/agent-surface.md | 157 ++++++++++++++++++++++----- review/agent-surface-rfc-review.html | 146 ++++++++++++++++++++----- review/review-data.json | 25 +++-- 3 files changed, 261 insertions(+), 67 deletions(-) diff --git a/drafts/agent-surface.md b/drafts/agent-surface.md index 852f2f3..f9b865c 100644 --- a/drafts/agent-surface.md +++ b/drafts/agent-surface.md @@ -262,6 +262,13 @@ This proposal separates two runtime responsibilities: One process can implement both roles, but the distinction matters for security analysis. +For agent-initiated access to an Agent Surface, the runtime is the reference +monitor. It is the only component allowed to mediate an agent's requested +application actions: it evaluates local policy, grant caveats, approvals, and +redaction before an action reaches the application. This does not make the +runtime the final authority; the application remains responsible for verifying +the grant on every action. + ### Agent Passport [Agent Passport](https://github.com/0al-spec/agent-passport) is identity and @@ -282,8 +289,10 @@ A user-approved, app-scoped, policy-bound delegation object. The grant is the semantic authorization. Tokens, cookies, JWTs, capability URLs, sender-constrained credentials, or signed objects are transport representations. -A grant SHOULD be temporary, constrained, auditable, revocable, and bound to the -user, application, runtime, agent, and passport evidence. +A grant SHOULD be temporary, constrained, auditable, and revocable. A +conforming grant MUST bind the user, application, runtime, agent, and passport +evidence that it authorizes. A credential presentation MUST let the application +verify that binding directly or retrieve it from authoritative grant state. ### Grant Credential @@ -294,6 +303,11 @@ objects, or app-side server sessions. A `grant_id` is an identifier. It is not, by itself, authority. +Grant credentials are runtime-held by default. Releasing a raw credential into +an agent-visible process, tool, prompt, environment, or model context is a +privileged `credential.release` capability and is denied unless the grant +explicitly permits it. + ### Capability Lease An informal term for a time-limited, attenuated grant. A capability lease grants @@ -371,6 +385,13 @@ Application -> enforces app-side grant scopes ``` +Every agent-initiated action against an Agent Surface MUST traverse the runtime. +An agent, adapter, tool, or subagent MUST NOT call an Agent Surface with an +independently obtained application credential or another authorization path that +bypasses runtime mediation. The runtime's reference-monitor role does not +replace application-side verification: the application MUST still enforce its +own grant authority and resource policy for every action. + ### Grant Is More Important Than Token A token is a bearer mechanism, proof key, or API credential. A grant is the @@ -408,9 +429,9 @@ mechanism. ### Agent Does Not Receive Raw Authority -Where practical, the agent SHOULD NOT receive the grant secret, OAuth access -token, cookie, session key, or broad application credential. The agent SHOULD -request typed actions from the runtime: +An agent MUST NOT receive the grant secret, OAuth access token, cookie, session +key, or broad application credential by default. The agent MUST request typed +actions from the runtime: ```text Agent -> Runtime -> App Agent Surface @@ -419,6 +440,15 @@ Agent -> Runtime -> App Agent Surface The runtime can then enforce local policy, approvals, idempotency, auditing, and redaction before sending anything to the app. +A runtime MAY release a raw credential only under an explicitly authorized +`credential.release` capability. The grant MUST name the credential class, +target agent identity and passport hash, resource-server audience, permitted +scopes, expiration, and required approval. The release MUST be shown during +consent, require the specified approval before delivery, and produce both a +runtime receipt and an app receipt where the application participates. Absence +of this capability means denial; a general action grant or an agent's request +MUST NOT imply credential release. + ### Proposal Mode Is the Default The first safe interaction mode SHOULD be: @@ -1160,7 +1190,16 @@ surface, scopes, and caveats. "expires_at": "2026-06-25T20:00:00Z", "write_approval": "required", "max_actions": 20, - "max_cost_usd": 5 + "max_cost_usd": 5, + "credential_release": { + "mode": "deny" + } + }, + "credential_binding": { + "method": "dpop", + "runtime_id": "application_runtime_456", + "agent_id": "local_agent_789", + "passport_hash": "sha256:..." }, "audit": { "local_receipt": "required", @@ -1234,7 +1273,10 @@ Cons: #### Model B: Runtime-Held Grant Plus App Token The app issues a scoped token to the runtime. The runtime locally binds that -token to an agent, passport, and policy. +token to an agent, passport, and policy. To satisfy the Grant-Enforcing +Application profile, the application MUST also establish the runtime, agent, +and passport binding from app-verifiable state or a verified proof at action +time. A runtime-only assertion of that binding is insufficient. Pros: @@ -1275,19 +1317,71 @@ An Agent Grant MAY be represented or proven by one of several mechanisms: - signed delegation object - macaroon-like caveated capability -A future draft is expected to define required proof profiles. The MVP profile -MAY use app-issued bearer grant credentials, but production deployments SHOULD -prefer sender-constrained credentials where practical. +A future draft is expected to define interoperable proof profiles. An MVP MAY +define an explicitly labeled development or compatibility bearer profile. +Production profiles MUST require a sender-constrained credential method or an +equivalent app-authenticated runtime-session binding for every Agent Surface +action. + +Regardless of representation, a Grant Credential MUST let the application +establish or obtain from authoritative grant state all of the following: + +- the active `grant_id`; +- the intended application or resource-server audience; +- the bound runtime identity; +- the bound agent identity and passport hash; and +- the credential-binding method and any proof-of-possession key or session + binding that it requires. + +The application MUST reject a presentation whose binding does not match the +grant's `delegate` or `credential_binding` values. An introspection or +server-side session profile MAY supply these values indirectly, but the runtime +MUST NOT substitute its own unverified assertion for application-verifiable +binding evidence. + +Sender-constrained methods include DPoP, mTLS, and equivalent +proof-of-possession mechanisms. A DPoP profile MUST follow RFC 9449 and bind +the proof to the request; an mTLS profile MUST follow RFC 8705 and bind the +credential to the authenticated certificate. A sender-constrained profile MUST +detect replay of a proof or an invalidated binding. A bare bearer credential +MAY be used only in the explicitly labeled development or compatibility profile +described above. It remains outside every agent-visible context and is subject +to short expiration, audience restriction, revocation, and application-side +grant verification. + +### Subdelegation + +A runtime MAY use a subagent, remote model, MCP server, tool, adapter, or a +secondary runtime to help execute delegated work. Receiving task context does +not make that component a grant delegate and does not transfer Agent Grant +authority. + +The runtime MUST treat every downstream component as untrusted with respect to +application authority. It MUST NOT forward a Grant Credential, raw application +credential, approval artifact, or an authorization path that can invoke an +Agent Surface outside runtime mediation. A downstream component that needs an +application action MUST request a typed action through the controlling runtime; +the runtime MUST evaluate the original grant, policy, approval, and redaction +rules again for that request. + +If a runtime delegates work to a secondary runtime, the secondary runtime is a +separate delegate. It MUST receive a newly issued, explicitly bound grant with +equal or narrower scopes, resources, caveats, lifetime, and credential-release +permissions. A parent grant or credential MUST NOT be forwarded as implicit +subdelegation. ### Grant Verification -Applications SHOULD verify every action against grant state: +Applications MUST verify every action against grant state: - grant exists and is active - grant credential or proof is valid - grant is bound to the user - grant is bound to the runtime when binding is required - grant is bound to the agent/passport hash when binding is required +- credential-binding method and proof-of-possession requirements are satisfied +- proof, nonce, certificate, or server-session binding has not been replayed or + invalidated - scope permits the action - resource constraints permit the target object - expiration has not passed @@ -1305,6 +1399,8 @@ Runtimes SHOULD verify: - local approval is present when required - action input matches the declared schema - secrets and credentials are not exposed to the agent +- any subagent, tool, adapter, remote model, or secondary runtime remains + subject to the same runtime mediation and does not receive implicit authority ## Capability Matching @@ -1403,7 +1499,8 @@ Example: ```http POST /agent-actions HTTP/1.1 Host: example.com -Authorization: Bearer +Authorization: DPoP +DPoP: Idempotency-Key: idem_01HX7DS8AC6G9 Content-Type: application/json ``` @@ -1425,22 +1522,9 @@ Content-Type: application/json } ``` -If the runtime uses a signed proof instead of a bearer grant credential, the -request SHOULD carry proof material in a standard authorization header or an -explicit `proof` field. - -Example proof shape: - -```json -{ - "proof": { - "type": "dpop+jwt", - "jti": "proof_123", - "iat": 1782400000, - "signature": "..." - } -} -``` +The request's proof material MUST use the authorization mechanism selected by +the credential-binding profile. For example, a DPoP-bound credential carries a +DPoP proof in the `DPoP` header as defined by RFC 9449. ### Action Response @@ -1744,7 +1828,9 @@ Agent -> Runtime -> App ``` The runtime holds or obtains credentials and exposes only typed action results to -the agent. +the agent. A raw credential release requires the explicit `credential.release` +capability and its corresponding approval and receipts; it is never implied by a +normal action grant. ### Malicious or Compromised Runtime @@ -1785,6 +1871,7 @@ unauthorized actions. Mitigations: - no direct credentials in agent process +- no implicit credential or grant transfer to subagents, tools, or remote models - schema validation - risk-based approval - action count limits @@ -1817,6 +1904,7 @@ Mitigations: - short-lived grants - sender-constrained tokens - DPoP or mTLS binding where practical +- credential-release default denial and explicit release receipts - token introspection - revocation - action count limits @@ -1892,6 +1980,7 @@ An application conforms to the Grant-Enforcing profile when it: - satisfies the Surface-Only profile - issues, validates, or introspects Agent Grants - validates grant state for every action +- validates credential binding to runtime, agent, and passport evidence - treats `grant_id` as an identifier, not authority - supports idempotency for side-effecting actions - supports grant revocation @@ -1914,6 +2003,10 @@ An application runtime conforms to this profile when it: - verifies Agent Passport evidence before delegation - obtains explicit user consent before storing a grant - mediates agent actions instead of exposing raw authority +- denies credential release unless an explicit `credential.release` capability + and its constraints are satisfied +- preserves runtime mediation when using subagents, tools, adapters, remote + models, or secondary runtimes - enforces local policy and approval rules - validates action input against schemas before sending to the app - records local audit events and runtime receipts @@ -1925,6 +2018,7 @@ An adapter conforms to this draft when it: - runs under runtime supervision - does not require raw app credentials +- does not receive a Grant Credential or transfer one to downstream components - requests app actions through runtime APIs - emits typed events - handles denials and approval waits @@ -2026,6 +2120,11 @@ To support Agent Surface Protocol, the next slices are: - OAuth 2.0 Resource Indicators: +- OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access + Tokens: + +- OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP): + - Key words for use in RFCs to Indicate Requirement Levels: - Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words: diff --git a/review/agent-surface-rfc-review.html b/review/agent-surface-rfc-review.html index fd0aeaf..2043b0f 100644 --- a/review/agent-surface-rfc-review.html +++ b/review/agent-surface-rfc-review.html @@ -385,6 +385,12 @@

Runtime

One process can implement both roles, but the distinction matters for security analysis.

+

For agent-initiated access to an Agent Surface, the runtime is the reference +monitor. It is the only component allowed to mediate an agent's requested +application actions: it evaluates local policy, grant caveats, approvals, and +redaction before an action reaches the application. This does not make the +runtime the final authority; the application remains responsible for verifying +the grant on every action.

Agent Passport

Agent Passport is identity and capability evidence for an agent. It can describe the agent, its declared @@ -399,14 +405,20 @@

Agent Grant

A user-approved, app-scoped, policy-bound delegation object.

The grant is the semantic authorization. Tokens, cookies, JWTs, capability URLs, sender-constrained credentials, or signed objects are transport representations. -A grant SHOULD be temporary, constrained, auditable, revocable, and bound to the -user, application, runtime, agent, and passport evidence.

+A grant SHOULD be temporary, constrained, auditable, and revocable. A +conforming grant MUST bind the user, application, runtime, agent, and passport +evidence that it authorizes. A credential presentation MUST let the application +verify that binding directly or retrieve it from authoritative grant state.

Grant Credential

A concrete credential or proof used to represent or prove an Agent Grant on the wire. Examples include opaque bearer tokens, sender-constrained tokens, DPoP proofs, mTLS-bound tokens, JWTs, macaroon-like capabilities, signed delegation objects, or app-side server sessions.

A grant_id is an identifier. It is not, by itself, authority.

+

Grant credentials are runtime-held by default. Releasing a raw credential into +an agent-visible process, tool, prompt, environment, or model context is a +privileged credential.release capability and is denied unless the grant +explicitly permits it.

Capability Lease

An informal term for a time-limited, attenuated grant. A capability lease grants only specific capabilities, under caveats such as duration, resource bounds, @@ -469,6 +481,12 @@

Grant Is More Important Than Token

A token is a bearer mechanism, proof key, or API credential. A grant is the semantic delegation:

@@ -493,13 +511,21 @@

Agent Does Not Receive Raw Authority

-

Where practical, the agent SHOULD NOT receive the grant secret, OAuth access -token, cookie, session key, or broad application credential. The agent SHOULD -request typed actions from the runtime:

+

An agent MUST NOT receive the grant secret, OAuth access token, cookie, session +key, or broad application credential by default. The agent MUST request typed +actions from the runtime:

Agent -> Runtime -> App Agent Surface

The runtime can then enforce local policy, approvals, idempotency, auditing, and redaction before sending anything to the app.

+

A runtime MAY release a raw credential only under an explicitly authorized +credential.release capability. The grant MUST name the credential class, +target agent identity and passport hash, resource-server audience, permitted +scopes, expiration, and required approval. The release MUST be shown during +consent, require the specified approval before delivery, and produce both a +runtime receipt and an app receipt where the application participates. Absence +of this capability means denial; a general action grant or an agent's request +MUST NOT imply credential release.

Proposal Mode Is the Default

The first safe interaction mode SHOULD be:

read -> draft/propose -> human or app approval -> write -> receipt
@@ -1106,7 +1132,16 @@ 
Grant Object

     "expires_at": "2026-06-25T20:00:00Z",
     "write_approval": "required",
     "max_actions": 20,
-    "max_cost_usd": 5
+    "max_cost_usd": 5,
+    "credential_release": {
+      "mode": "deny"
+    }
+  },
+  "credential_binding": {
+    "method": "dpop",
+    "runtime_id": "application_runtime_456",
+    "agent_id": "local_agent_789",
+    "passport_hash": "sha256:..."
   },
   "audit": {
     "local_receipt": "required",
@@ -1167,7 +1202,10 @@ 
M
 
 
Model B: Runtime-Held Grant Plus App Token

 
The app issues a scoped token to the runtime. The runtime locally binds that
-token to an agent, passport, and policy.

+token to an agent, passport, and policy. To satisfy the Grant-Enforcing
+Application profile, the application MUST also establish the runtime, agent,
+and passport binding from app-verifiable state or a verified proof at action
+time. A runtime-only assertion of that binding is insufficient.

 
Pros:

 
    
 
  • Simpler for early app integrations.
    • 
@@ -1204,17 +1242,63 @@ 
    Subdelegation
    
+
    A runtime MAY use a subagent, remote model, MCP server, tool, adapter, or a
+secondary runtime to help execute delegated work. Receiving task context does
+not make that component a grant delegate and does not transfer Agent Grant
+authority.
    
+
    The runtime MUST treat every downstream component as untrusted with respect to
+application authority. It MUST NOT forward a Grant Credential, raw application
+credential, approval artifact, or an authorization path that can invoke an
+Agent Surface outside runtime mediation. A downstream component that needs an
+application action MUST request a typed action through the controlling runtime;
+the runtime MUST evaluate the original grant, policy, approval, and redaction
+rules again for that request.
    
+
    If a runtime delegates work to a secondary runtime, the secondary runtime is a
+separate delegate. It MUST receive a newly issued, explicitly bound grant with
+equal or narrower scopes, resources, caveats, lifetime, and credential-release
+permissions. A parent grant or credential MUST NOT be forwarded as implicit
+subdelegation.
    
 
    Grant Verification
    
-
    Applications SHOULD verify every action against grant state:
    
+
    Applications MUST verify every action against grant state:
    
 
      
 
    • grant exists and is active
      • 
 
    • grant credential or proof is valid
      • 
 
    • grant is bound to the user
      • 
 
    • grant is bound to the runtime when binding is required
      • 
 
    • grant is bound to the agent/passport hash when binding is required
      • 
+
    • credential-binding method and proof-of-possession requirements are satisfied
      • 
+
    • proof, nonce, certificate, or server-session binding has not been replayed or
+invalidated
      • 
 
    • scope permits the action
      • 
 
    • resource constraints permit the target object
      • 
 
    • expiration has not passed
      • 
@@ -1232,6 +1316,8 @@ 
      Grant Verifica
 
    • local approval is present when required
      • 
 
    • action input matches the declared schema
      • 
 
    • secrets and credentials are not exposed to the agent
      • 
+
    • any subagent, tool, adapter, remote model, or secondary runtime remains
+subject to the same runtime mediation and does not receive implicit authority
      • 
 
    
 
    Capability Matching
    
 
    Capability matching is an advisory process used by the runtime to help the user
@@ -1309,7 +1395,8 @@ 
    Action Request
    
 
    Example:
    
 
    POST /agent-actions HTTP/1.1
 Host: example.com
-Authorization: Bearer <grant-credential>
+Authorization: DPoP <grant-credential>
+DPoP: <signed-proof>
 Idempotency-Key: idem_01HX7DS8AC6G9
 Content-Type: application/json
 
    
@@ -1328,19 +1415,9 @@ 
    Action Request
    
   }
 }
-

If the runtime uses a signed proof instead of a bearer grant credential, the -request SHOULD carry proof material in a standard authorization header or an -explicit proof field.

-

Example proof shape:

-
{
-  "proof": {
-    "type": "dpop+jwt",
-    "jti": "proof_123",
-    "iat": 1782400000,
-    "signature": "..."
-  }
-}
-
+

The request's proof material MUST use the authorization mechanism selected by +the credential-binding profile. For example, a DPoP-bound credential carries a +DPoP proof in the DPoP header as defined by RFC 9449.

Action Response

{
   "type": "action.result",
@@ -1594,7 +1671,9 @@ 
Raw Token Leakag
 
Agent -> Runtime -> App
 

 
The runtime holds or obtains credentials and exposes only typed action results to
-the agent.

+the agent. A raw credential release requires the explicit credential.release
+capability and its corresponding approval and receipts; it is never implied by a
+normal action grant.

 
Malicious or Compromised Runtime

 
Applications MUST NOT trust runtime claims blindly. Every app action MUST be
 authorized by app-verifiable grant state.

@@ -1627,6 +1706,7 @@ 
Stol
 
  • short-lived grants
    • 
 
  • sender-constrained tokens
    • 
 
  • DPoP or mTLS binding where practical
    • 
+
  • credential-release default denial and explicit release receipts
    • 
 
  • token introspection
    • 
 
  • revocation
    • 
 
  • action count limits
    • 
@@ -1714,6 +1795,7 @@ 
    Agent Adapter
    
 
      
 
    • runs under runtime supervision
      • 
 
    • does not require raw app credentials
      • 
+
    • does not receive a Grant Credential or transfer one to downstream components
      • 
 
    • requests app actions through runtime APIs
      • 
 
    • emits typed events
      • 
 
    • handles denials and approval waits
      • 
@@ -1841,6 +1928,11 @@ 
      References
      
 https://www.rfc-editor.org/rfc/rfc8693
 
    • OAuth 2.0 Resource Indicators:
 https://www.rfc-editor.org/rfc/rfc8707
      • 
+
    • OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access
+Tokens:
+https://www.rfc-editor.org/rfc/rfc8705
      • 
+
    • OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP):
+https://www.rfc-editor.org/rfc/rfc9449
      • 
 
    • Key words for use in RFCs to Indicate Requirement Levels:
 https://www.rfc-editor.org/rfc/rfc2119
      • 
 
    • Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words:
@@ -2273,7 +2365,7 @@ 
      
Date: Sat, 11 Jul 2026 12:28:39 +0300
Subject: [PATCH 2/3] Update secrets boundary review card

---
 review/agent-surface-rfc-review.html | 2 +-
 review/review-data.json              | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/review/agent-surface-rfc-review.html b/review/agent-surface-rfc-review.html
index 2043b0f..4f67dd1 100644
--- a/review/agent-surface-rfc-review.html
+++ b/review/agent-surface-rfc-review.html
@@ -2365,7 +2365,7 @@ 
      
Date: Sat, 11 Jul 2026 13:33:21 +0300
Subject: [PATCH 3/3] Resolve authority profile review findings

---
 drafts/agent-surface.md              | 154 ++++++++++++++++++---------
 review/agent-surface-rfc-review.html | 148 ++++++++++++++++---------
 review/review-data.json              |  12 ++-
 3 files changed, 213 insertions(+), 101 deletions(-)

diff --git a/drafts/agent-surface.md b/drafts/agent-surface.md
index f9b865c..bf4e2a4 100644
--- a/drafts/agent-surface.md
+++ b/drafts/agent-surface.md
@@ -306,7 +306,8 @@ A `grant_id` is an identifier. It is not, by itself, authority.
 Grant credentials are runtime-held by default. Releasing a raw credential into
 an agent-visible process, tool, prompt, environment, or model context is a
 privileged `credential.release` capability and is denied unless the grant
-explicitly permits it.
+explicitly permits it. The Grant Credential that authorizes Agent Surface
+actions is never releasable under this capability.
 
 ### Capability Lease
 
@@ -441,13 +442,20 @@ The runtime can then enforce local policy, approvals, idempotency, auditing, and
 redaction before sending anything to the app.
 
 A runtime MAY release a raw credential only under an explicitly authorized
-`credential.release` capability. The grant MUST name the credential class,
-target agent identity and passport hash, resource-server audience, permitted
-scopes, expiration, and required approval. The release MUST be shown during
-consent, require the specified approval before delivery, and produce both a
-runtime receipt and an app receipt where the application participates. Absence
-of this capability means denial; a general action grant or an agent's request
-MUST NOT imply credential release.
+`credential.release` capability. The released credential MUST be newly issued,
+target-bound, attenuated to a non-Agent-Surface audience, and unusable at every
+Agent Surface endpoint. The application MUST reject that credential if it is
+presented to an Agent Surface endpoint. A Grant Credential, app session, or
+other credential that can authorize Agent Surface actions MUST NOT be released.
+
+The grant MUST name the credential class, target agent identity and passport
+hash, non-Agent-Surface resource-server audience, permitted scopes, expiration,
+and required approval. The release MUST be shown during consent, require the
+specified approval before delivery, and produce both a runtime receipt and an
+app receipt where the application participates. Absence of this capability
+means denial; a general action grant or an agent's request MUST NOT imply
+credential release. A future direct-access profile would require a separate
+authority model and is outside this draft.
 
 ### Proposal Mode Is the Default
 
@@ -1317,11 +1325,19 @@ An Agent Grant MAY be represented or proven by one of several mechanisms:
 - signed delegation object
 - macaroon-like caveated capability
 
-A future draft is expected to define interoperable proof profiles. An MVP MAY
-define an explicitly labeled development or compatibility bearer profile.
-Production profiles MUST require a sender-constrained credential method or an
-equivalent app-authenticated runtime-session binding for every Agent Surface
-action.
+This draft defines two credential profiles:
+
+- **Compatibility Bearer Credential Profile**: an explicitly labeled
+  development or compatibility profile in which the runtime holds a bearer
+  credential outside every agent-visible context. It is not proof-bound and
+  MUST NOT be advertised as the Proof-Bound Credential Profile.
+- **Proof-Bound Credential Profile**: every Agent Surface action uses a
+  sender-constrained credential or an app-authenticated runtime session that
+  requires possession of a bound key or channel credential on every request. A
+  reusable session identifier, cookie, or bearer token by itself does not
+  satisfy this profile.
+
+A future draft is expected to define additional interoperable proof profiles.
 
 Regardless of representation, a Grant Credential MUST let the application
 establish or obtain from authoritative grant state all of the following:
@@ -1339,36 +1355,52 @@ server-side session profile MAY supply these values indirectly, but the runtime
 MUST NOT substitute its own unverified assertion for application-verifiable
 binding evidence.
 
-Sender-constrained methods include DPoP, mTLS, and equivalent
-proof-of-possession mechanisms. A DPoP profile MUST follow RFC 9449 and bind
-the proof to the request; an mTLS profile MUST follow RFC 8705 and bind the
-credential to the authenticated certificate. A sender-constrained profile MUST
-detect replay of a proof or an invalidated binding. A bare bearer credential
-MAY be used only in the explicitly labeled development or compatibility profile
-described above. It remains outside every agent-visible context and is subject
-to short expiration, audience restriction, revocation, and application-side
-grant verification.
+Proof-Bound Credential Profile methods include DPoP, mTLS, and equivalent
+proof-of-possession mechanisms. A DPoP method MUST follow RFC 9449, bind the
+proof to the request, and accept proofs only within a limited freshness window.
+It SHOULD track `jti` values during that window and reject duplicates where the
+deployment can maintain the required shared state. Reuse of a server-provided
+DPoP nonce MUST NOT by itself be treated as replay. An mTLS method MUST follow
+RFC 8705, require the protected-resource request to use the certificate bound
+to the token, and reject a certificate mismatch or an invalidated binding.
+Reuse of that bound certificate across valid requests MUST NOT by itself be
+treated as replay. A proof-bound server session MUST be active, bound to the
+grant and runtime, and authenticated with its bound key or channel credential
+on every request.
+
+A bare bearer credential MAY be used only in the Compatibility Bearer
+Credential Profile. It remains outside every agent-visible context and is
+subject to short expiration, audience restriction, revocation, and
+application-side grant verification.
 
 ### Subdelegation
 
-A runtime MAY use a subagent, remote model, MCP server, tool, adapter, or a
-secondary runtime to help execute delegated work. Receiving task context does
-not make that component a grant delegate and does not transfer Agent Grant
-authority.
-
-The runtime MUST treat every downstream component as untrusted with respect to
-application authority. It MUST NOT forward a Grant Credential, raw application
-credential, approval artifact, or an authorization path that can invoke an
-Agent Surface outside runtime mediation. A downstream component that needs an
-application action MUST request a typed action through the controlling runtime;
-the runtime MUST evaluate the original grant, policy, approval, and redaction
-rules again for that request.
-
-If a runtime delegates work to a secondary runtime, the secondary runtime is a
-separate delegate. It MUST receive a newly issued, explicitly bound grant with
-equal or narrower scopes, resources, caveats, lifetime, and credential-release
-permissions. A parent grant or credential MUST NOT be forwarded as implicit
-subdelegation.
+A runtime MAY use a subagent, remote model, MCP server, tool, adapter, or an
+ungranted secondary runtime to help execute delegated work. Receiving task
+context does not make that component a grant delegate and does not transfer
+Agent Grant authority.
+
+The runtime MUST treat every downstream component, including an ungranted
+secondary runtime, as untrusted with respect to application authority. It MUST
+NOT forward a Grant Credential, raw application credential, approval artifact,
+or an authorization path that can invoke an Agent Surface outside runtime
+mediation. A downstream component that needs an application action MUST request
+a typed action through the controlling runtime; the runtime MUST evaluate the
+original grant, policy, approval, and redaction rules again for that request.
+
+The application MAY instead issue a child grant that makes a secondary runtime
+a separate delegate. Once that grant is issued, the child runtime is the
+controlling runtime for actions under the child grant and sends them directly to
+the application with its own bound credential; those actions do not route
+through the parent runtime. The parent runtime MUST NOT present the child
+credential or mediate an action as if it originated from the child.
+
+The child grant MUST record `parent_grant_id` and `parent_runtime_id`, and MUST
+have equal or narrower scopes, resources, caveats, credential-release
+permissions, and lifetime. The application MUST revoke or suspend the child
+grant when the parent grant expires, is revoked, or loses the authority from
+which the child grant was derived. A parent grant or credential MUST NOT be
+forwarded as implicit subdelegation.
 
 ### Grant Verification
 
@@ -1377,11 +1409,17 @@ Applications MUST verify every action against grant state:
 - grant exists and is active
 - grant credential or proof is valid
 - grant is bound to the user
-- grant is bound to the runtime when binding is required
-- grant is bound to the agent/passport hash when binding is required
+- grant is bound to the runtime
+- grant is bound to the agent/passport hash
 - credential-binding method and proof-of-possession requirements are satisfied
-- proof, nonce, certificate, or server-session binding has not been replayed or
-  invalidated
+- for DPoP, the proof is request-bound and within the limited acceptance window;
+  when `jti` replay tracking is enabled, its `jti` has not already been accepted;
+  reuse of a valid server nonce is not rejected by itself
+- for mTLS, the presented certificate matches the certificate bound to the token
+  and the binding has not been invalidated; reuse of the matching certificate is
+  not rejected by itself
+- for a proof-bound server session, the session is active, bound to the grant
+  and runtime, and authenticated with the bound key or channel credential
 - scope permits the action
 - resource constraints permit the target object
 - expiration has not passed
@@ -1816,7 +1854,7 @@ not authority. Grant is authority only within caveats.
 ### Confused Deputy
 
 The runtime can accidentally use a grant for the wrong agent, user, workspace, or
-application. Grants SHOULD bind user, app, runtime, agent, and passport hash.
+application. Grants MUST bind user, app, runtime, agent, and passport hash.
 
 ### Raw Token Leakage
 
@@ -1829,8 +1867,9 @@ Agent -> Runtime -> App
 
 The runtime holds or obtains credentials and exposes only typed action results to
 the agent. A raw credential release requires the explicit `credential.release`
-capability and its corresponding approval and receipts; it is never implied by a
-normal action grant.
+capability and its corresponding approval and receipts; it is never implied by
+a normal action grant. A released credential is restricted to a
+non-Agent-Surface audience and MUST be rejected at Agent Surface endpoints.
 
 ### Malicious or Compromised Runtime
 
@@ -1995,6 +2034,19 @@ An application conforms to the Receipt-Producing profile when it:
   idempotency key
 - records denied or failed high-risk actions
 
+### Proof-Bound Grant-Enforcing Application
+
+An application conforms to the Proof-Bound Grant-Enforcing Application profile
+when it:
+
+- satisfies the Grant-Enforcing Application profile
+- accepts Agent Surface actions only under the Proof-Bound Credential Profile
+- verifies the per-request proof-of-possession or bound-channel authentication
+- applies the method-specific DPoP, mTLS, or proof-bound session checks defined
+  in Grant Verification
+- rejects a bearer token, cookie, or reusable session identifier as sufficient
+  authority by itself
+
 ### Application Runtime Profile
 
 An application runtime conforms to this profile when it:
@@ -2005,8 +2057,12 @@ An application runtime conforms to this profile when it:
 - mediates agent actions instead of exposing raw authority
 - denies credential release unless an explicit `credential.release` capability
   and its constraints are satisfied
-- preserves runtime mediation when using subagents, tools, adapters, remote
-  models, or secondary runtimes
+- preserves parent-runtime mediation for subagents, tools, adapters, remote
+  models, and ungranted secondary runtimes
+- treats a separately granted child runtime as its own controlling runtime and
+  preserves parent linkage, attenuation, and cascade revocation
+- implements the Proof-Bound Credential Profile when the application requires
+  the Proof-Bound Grant-Enforcing Application profile
 - enforces local policy and approval rules
 - validates action input against schemas before sending to the app
 - records local audit events and runtime receipts
diff --git a/review/agent-surface-rfc-review.html b/review/agent-surface-rfc-review.html
index 4f67dd1..07e80c0 100644
--- a/review/agent-surface-rfc-review.html
+++ b/review/agent-surface-rfc-review.html
@@ -418,7 +418,8 @@ 
      Grant CredentialGrant credentials are runtime-held by default. Releasing a raw credential into
 an agent-visible process, tool, prompt, environment, or model context is a
 privileged credential.release capability and is denied unless the grant
-explicitly permits it.
      
+explicitly permits it. The Grant Credential that authorizes Agent Surface
+actions is never releasable under this capability.
      
 
      Capability Lease
      
 
      An informal term for a time-limited, attenuated grant. A capability lease grants
 only specific capabilities, under caveats such as duration, resource bounds,
@@ -519,13 +520,19 @@ 
      Proposal Mode Is the Default
      
 
      The first safe interaction mode SHOULD be:
      
 
      read -> draft/propose -> human or app approval -> write -> receipt
@@ -1242,11 +1249,19 @@ 
      Subdelegation
      
-
      A runtime MAY use a subagent, remote model, MCP server, tool, adapter, or a
-secondary runtime to help execute delegated work. Receiving task context does
-not make that component a grant delegate and does not transfer Agent Grant
-authority.
      
-
      The runtime MUST treat every downstream component as untrusted with respect to
-application authority. It MUST NOT forward a Grant Credential, raw application
-credential, approval artifact, or an authorization path that can invoke an
-Agent Surface outside runtime mediation. A downstream component that needs an
-application action MUST request a typed action through the controlling runtime;
-the runtime MUST evaluate the original grant, policy, approval, and redaction
-rules again for that request.
      
-
      If a runtime delegates work to a secondary runtime, the secondary runtime is a
-separate delegate. It MUST receive a newly issued, explicitly bound grant with
-equal or narrower scopes, resources, caveats, lifetime, and credential-release
-permissions. A parent grant or credential MUST NOT be forwarded as implicit
-subdelegation.
      
+
      A runtime MAY use a subagent, remote model, MCP server, tool, adapter, or an
+ungranted secondary runtime to help execute delegated work. Receiving task
+context does not make that component a grant delegate and does not transfer
+Agent Grant authority.
      
+
      The runtime MUST treat every downstream component, including an ungranted
+secondary runtime, as untrusted with respect to application authority. It MUST
+NOT forward a Grant Credential, raw application credential, approval artifact,
+or an authorization path that can invoke an Agent Surface outside runtime
+mediation. A downstream component that needs an application action MUST request
+a typed action through the controlling runtime; the runtime MUST evaluate the
+original grant, policy, approval, and redaction rules again for that request.
      
+
      The application MAY instead issue a child grant that makes a secondary runtime
+a separate delegate. Once that grant is issued, the child runtime is the
+controlling runtime for actions under the child grant and sends them directly to
+the application with its own bound credential; those actions do not route
+through the parent runtime. The parent runtime MUST NOT present the child
+credential or mediate an action as if it originated from the child.
      
+
      The child grant MUST record parent_grant_id and parent_runtime_id, and MUST
+have equal or narrower scopes, resources, caveats, credential-release
+permissions, and lifetime. The application MUST revoke or suspend the child
+grant when the parent grant expires, is revoked, or loses the authority from
+which the child grant was derived. A parent grant or credential MUST NOT be
+forwarded as implicit subdelegation.
      
 
      Grant Verification
      
 
      Applications MUST verify every action against grant state:
      
 
        
 
      • grant exists and is active
        • 
 
      • grant credential or proof is valid
        • 
 
      • grant is bound to the user
        • 
-
      • grant is bound to the runtime when binding is required
        • 
-
      • grant is bound to the agent/passport hash when binding is required
        • 
+
      • grant is bound to the runtime
        • 
+
      • grant is bound to the agent/passport hash
        • 
 
      • credential-binding method and proof-of-possession requirements are satisfied
        • 
-
      • proof, nonce, certificate, or server-session binding has not been replayed or
-invalidated
        • 
+
      • for DPoP, the proof is request-bound and within the limited acceptance window;
+when jti replay tracking is enabled, its jti has not already been accepted;
+reuse of a valid server nonce is not rejected by itself
        • 
+
      • for mTLS, the presented certificate matches the certificate bound to the token
+and the binding has not been invalidated; reuse of the matching certificate is
+not rejected by itself
        • 
+
      • for a proof-bound server session, the session is active, bound to the grant
+and runtime, and authenticated with the bound key or channel credential
        • 
 
      • scope permits the action
        • 
 
      • resource constraints permit the target object
        • 
 
      • expiration has not passed
        • 
@@ -1664,7 +1699,7 @@ 
        Threat Mod
 not authority. Grant is authority only within caveats.
        
 
        Confused Deputy
        
 
        The runtime can accidentally use a grant for the wrong agent, user, workspace, or
-application. Grants SHOULD bind user, app, runtime, agent, and passport hash.
        
+application. Grants MUST bind user, app, runtime, agent, and passport hash.
        
 
        Raw Token Leakage
        
 
        If an agent process receives raw app tokens, the runtime loses mediation control.
 The preferred architecture is:
        
@@ -1672,8 +1707,9 @@ 
        Raw Token Leakag
 
      
 
      The runtime holds or obtains credentials and exposes only typed action results to
 the agent. A raw credential release requires the explicit credential.release
-capability and its corresponding approval and receipts; it is never implied by a
-normal action grant.
      
+capability and its corresponding approval and receipts; it is never implied by
+a normal action grant. A released credential is restricted to a
+non-Agent-Surface audience and MUST be rejected at Agent Surface endpoints.
      
 
      Malicious or Compromised Runtime
      
 
      Applications MUST NOT trust runtime claims blindly. Every app action MUST be
 authorized by app-verifiable grant state.
      
@@ -1809,6 +1845,18 @@ 
      Proof-Bound Grant-Enforcing Application
      
+
      An application conforms to the Proof-Bound Grant-Enforcing Application profile
+when it:
      
+
        
+
      • satisfies the Grant-Enforcing Application profile
        • 
+
      • accepts Agent Surface actions only under the Proof-Bound Credential Profile
        • 
+
      • verifies the per-request proof-of-possession or bound-channel authentication
        • 
+
      • applies the method-specific DPoP, mTLS, or proof-bound session checks defined
+in Grant Verification
        • 
+
      • rejects a bearer token, cookie, or reusable session identifier as sufficient
+authority by itself
        • 
+
      
 
      Application Runtime Profile
      
 
      An application runtime conforms to this profile when it:
      
 
        
@@ -1818,8 +1866,12 @@