From 25cf2daacf927d48554fbc8f48e95a56f1d976f2 Mon Sep 17 00:00:00 2001 From: Bar Kaduri Date: Mon, 15 Jun 2026 11:09:53 +0300 Subject: [PATCH 1/2] Slim ACS-Core: relax MODIFY, system/ping, wrapped MCP to SHOULD/MAY Lowers the adoption floor for frameworks claiming ACS-Core conformance by relaxing three items within Core to conditional requirements, without removing them from Core or introducing new profiles. The hook taxonomy minimum, dispositions ALLOW/DENY/ASK/DEFER, SessionContext with chain hash and Intent, replay protection, baseline HMAC-SHA256 integrity, and decision-honoring behavior remain MUST. Changes: - Dispositions: ALLOW/DENY/ASK/DEFER stay MUST. MODIFY moves to SHOULD, with composition rules ([..]/specification.md#63-modify-composition-normative) still normative for implementers. Deployments that do not implement MODIFY declare so in the handshake; Guardians MUST NOT return MODIFY to such deployments (DENY with audit substitution). - Liveness `system/ping`: SHOULD-implement. MAY be omitted by deployments where both parties co-locate or rely on transport-level liveness. - Wrapped MCP `protocols/MCP/*`: SHOULD-implement by deployments that govern MCP tool calls. MAY be omitted by deployments that do not use MCP. Support is declared in the handshake. What stays mandatory in Core (the differentiation from a stateless single-call evaluator): SessionContext + chain_hash + Intent option, the 6-hook lifecycle minimum, four dispositions, replay protection, HMAC baseline integrity, and decision honoring. These preserve the runtime governance properties that distinguish ACS from a stateless policy evaluator. Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/spec/conformance.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/spec/conformance.md b/docs/spec/conformance.md index 95ad9f7..9f8c4cd 100644 --- a/docs/spec/conformance.md +++ b/docs/spec/conformance.md @@ -17,13 +17,13 @@ A v0.1.0-conformant deployment MUST implement ACS-Core. ACS-Core comprises: - **Handshake** — `handshake/hello` with ClientHello/ServerHello ([Specification §4](./instrument/specification.md#4-capability-negotiation-handshake)). - **Request/response envelope** — JSON-RPC 2.0 with ACS extensions ([§3](./instrument/specification.md#3-wire-format)). `request_id`, `timestamp`, `acs_version`, `metadata` required on every request. - **Hook taxonomy** — At minimum: `sessionStart`, `userMessage` or `agentTrigger`, `toolCallRequest`, `toolCallResult`, `agentResponse`, `sessionEnd`. Additional hooks (`turnStart`/`turnEnd`, `preCompact`/`postCompact`, `subagentStart`/`subagentStop`, `knowledgeRetrieval`, `memoryContextRetrieval`, `memoryStore`, `skillRegister`/`skillLoad`/`skillUnload`) are normatively defined and SHOULD be implemented when the harness can observe the corresponding event; they are capability-negotiated via the handshake. A deployment whose AgBOM includes `skill` components SHOULD emit the skill lifecycle hooks, so a Guardian is not blind to a composition surface the inventory already exposes. -- **Dispositions** — All five (ALLOW, DENY, MODIFY, ASK, DEFER) with required fields per [§6](./instrument/specification.md#6-disposition-vocabulary). +- **Dispositions** — Four MUST-support: ALLOW, DENY, ASK, DEFER, with required fields per [§6](./instrument/specification.md#6-disposition-vocabulary). MODIFY is SHOULD-support: deployments that implement MODIFY MUST follow the MODIFY composition rules ([§6.3](./instrument/specification.md#63-modify-composition-normative)); deployments that do not implement MODIFY MUST advertise this in the handshake, and a Guardian targeting such a deployment MUST NOT return MODIFY (it substitutes DENY with an audit event recording the substitution). - **SessionContext and Intent**: `session_id`, `chain_hash` (rolling SHA-256), append-only ContextEntry chain, with the Guardian publishing the chain head (`chain_hash`) on responses for content-bearing steps ([§8](./instrument/specification.md#8-sessioncontext-and-intent)). Intent is optional but normative when IBAC is the enforcement paradigm. - **Replay protection** — `request_id` (UUID) and `timestamp` on every request; Guardians MUST reject replays per [§10.3](./instrument/specification.md#103-replay-protection). - **Baseline integrity**: every request and response carries a signature over the canonical envelope ([§10](./instrument/specification.md#10-cryptographic-signatures)). `HMAC-SHA256` with an HKDF-derived per-session key from deployment-provided key material is the baseline; asymmetric and post-quantum algorithms are the ACS-Crypto profile. - **Decision honoring**: the Observed Agent MUST wait for the Guardian's decision up to the negotiated timeout and apply it; on a decision failure (timeout, transport failure, or an error without a decision) it applies the `on_decision_failure` posture (default `proceed`, fail-open) and records every fail-open proceed as an audit event ([§6.4](./instrument/specification.md#64-honoring-decisions-normative)). Handshake failure follows the deployment's startup posture ([§4.1](./instrument/specification.md#41-handshake-failure-normative)). -- **Liveness** — `system/ping` ([§13](./instrument/specification.md#13-liveness-system-methods)). -- **Wrapped MCP** — `protocols/MCP/*` ([Hooks](./instrument/hooks.md#protocolsmcp)). +- **Liveness** — `system/ping` ([§13](./instrument/specification.md#13-liveness-system-methods)) SHOULD be implemented; MAY be omitted by deployments where both parties co-locate or rely on transport-level liveness signals. +- **Wrapped MCP** — `protocols/MCP/*` ([Hooks](./instrument/hooks.md#protocolsmcp)) SHOULD be implemented by deployments that govern MCP tool calls under the Guardian; MAY be omitted by deployments that do not use MCP. Support is declared in the handshake. ACS-Core does NOT require: field-level Provenance objects, Trace event emission, AgBOM, asymmetric or post-quantum signatures, or `request_hash` on ContextEntry (`request_hash` remains SHOULD). It DOES require the baseline signature (§10) and decision honoring (§6.4). ACS-Core deployments validate hook payloads against the base schemas, where `provenance` is OPTIONAL; field-level Provenance is added by the ACS-Provenance profile. From 3ec047f10cc8e78efd7d046c0c8ba5997f1e8335 Mon Sep 17 00:00:00 2001 From: Bar Kaduri Date: Mon, 15 Jun 2026 13:13:55 +0300 Subject: [PATCH 2/2] Promote subagentStart and subagentStop to mandatory in ACS-Core Adds subagent lifecycle hooks to the Core minimum (8 hooks instead of 6). Rationale (Ariel): a sub-agent is itself an Observed Agent under delegated authority. Without subagentStart/subagentStop on the Core floor, a Guardian is blind to cross-agent propagation and to the confused-deputy attack class that delegation enables. ACS already has the schemas, the AgBOM models subagent components, and the wire shape is identical to other steps -- the cost of mandating these is marginal, the cost of leaving them optional is a structural gap in runtime governance. Frameworks without a sub-agent abstraction satisfy this requirement vacuously: the hooks never fire, the framework still declares them as implemented in the handshake. Net Core hook count: 6 -> 8. Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/spec/conformance.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/spec/conformance.md b/docs/spec/conformance.md index 9f8c4cd..11b0e86 100644 --- a/docs/spec/conformance.md +++ b/docs/spec/conformance.md @@ -16,7 +16,7 @@ A v0.1.0-conformant deployment MUST implement ACS-Core. ACS-Core comprises: - **Handshake** — `handshake/hello` with ClientHello/ServerHello ([Specification §4](./instrument/specification.md#4-capability-negotiation-handshake)). - **Request/response envelope** — JSON-RPC 2.0 with ACS extensions ([§3](./instrument/specification.md#3-wire-format)). `request_id`, `timestamp`, `acs_version`, `metadata` required on every request. -- **Hook taxonomy** — At minimum: `sessionStart`, `userMessage` or `agentTrigger`, `toolCallRequest`, `toolCallResult`, `agentResponse`, `sessionEnd`. Additional hooks (`turnStart`/`turnEnd`, `preCompact`/`postCompact`, `subagentStart`/`subagentStop`, `knowledgeRetrieval`, `memoryContextRetrieval`, `memoryStore`, `skillRegister`/`skillLoad`/`skillUnload`) are normatively defined and SHOULD be implemented when the harness can observe the corresponding event; they are capability-negotiated via the handshake. A deployment whose AgBOM includes `skill` components SHOULD emit the skill lifecycle hooks, so a Guardian is not blind to a composition surface the inventory already exposes. +- **Hook taxonomy** — At minimum: `sessionStart`, `userMessage` or `agentTrigger`, `toolCallRequest`, `toolCallResult`, `agentResponse`, `sessionEnd`, `subagentStart`, `subagentStop`. Subagent hooks are mandatory because a sub-agent is itself an Observed Agent under delegated authority; without them, a Guardian is blind to cross-agent propagation (the confused-deputy attack class). Frameworks that do not have a sub-agent abstraction satisfy this requirement vacuously (the hooks never fire). Additional hooks (`turnStart`/`turnEnd`, `preCompact`/`postCompact`, `knowledgeRetrieval`, `memoryContextRetrieval`, `memoryStore`, `skillRegister`/`skillLoad`/`skillUnload`) are normatively defined and SHOULD be implemented when the harness can observe the corresponding event; they are capability-negotiated via the handshake. A deployment whose AgBOM includes `skill` components SHOULD emit the skill lifecycle hooks, so a Guardian is not blind to a composition surface the inventory already exposes. - **Dispositions** — Four MUST-support: ALLOW, DENY, ASK, DEFER, with required fields per [§6](./instrument/specification.md#6-disposition-vocabulary). MODIFY is SHOULD-support: deployments that implement MODIFY MUST follow the MODIFY composition rules ([§6.3](./instrument/specification.md#63-modify-composition-normative)); deployments that do not implement MODIFY MUST advertise this in the handshake, and a Guardian targeting such a deployment MUST NOT return MODIFY (it substitutes DENY with an audit event recording the substitution). - **SessionContext and Intent**: `session_id`, `chain_hash` (rolling SHA-256), append-only ContextEntry chain, with the Guardian publishing the chain head (`chain_hash`) on responses for content-bearing steps ([§8](./instrument/specification.md#8-sessioncontext-and-intent)). Intent is optional but normative when IBAC is the enforcement paradigm. - **Replay protection** — `request_id` (UUID) and `timestamp` on every request; Guardians MUST reject replays per [§10.3](./instrument/specification.md#103-replay-protection).