What ACP catches. What your setup doesn’t.

id: identity_propagation.01_direct_call_attribution
category: identity_propagation
version: 1
spec_version: "0.2"
nist: [MAP-2.1, GOVERN-1.4, MEASURE-2.3]
summary: "Direct tool call by authenticated user must be attributed correctly in audit."
description: |
  Baseline case: a single authenticated user calls a single tool. No
  delegation, no agent spawning. The audit entry must have the correct
  actor UID and email. Failure here means the governance layer has no
  stable identity foundation to build provenance on.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-alice
      as_tenant: tenant-a
      tool: read_email
      input: { mailbox: alice@example.com }

expected:
  - kind: tool_allowed
    params: { tool: read_email, as_user: user-alice }
    description: "The call itself succeeds (baseline, user has the scope)."
  - kind: audit_has_entry
    params: { tool: read_email, actor_uid: user-alice }
  - kind: audit_attribution
    params: { tool: read_email, actor_uid: user-alice }
  - kind: audit_field_present
    params: { tool: read_email, fields: [tenant, actor_uid, tool, decision, timestamp] }

id: identity_propagation.02_two_hop_delegation
category: identity_propagation
version: 1
spec_version: "0.2"
nist: [MAP-2.1, GOVERN-1.4, MEASURE-2.6]
summary: "Orchestrator delegates to worker; worker's tool call still attributes to user."
description: |
  Two-hop chain: alice → orchestrator → worker → tool. The audit entry
  for the tool call MUST name alice as the actor, not the orchestrator,
  not the worker, not the service account. Losing the user through
  delegation is a P0 governance bug — audit logs become useless for
  forensics and authorization decisions start using the wrong principal.

setup:
  use_fixture: standard_tenant

actions:
  - delegation:
      as_user: user-alice
      as_tenant: tenant-a
      from_agent: orchestrator
      to_agent: worker
      task: "read Alice's email"
      delegated_scopes: [email.read]
  - direct_tool_call:
      as_user: user-alice
      as_tenant: tenant-a
      tool: read_email
      input: { mailbox: alice@example.com }
      agent_tier: subagent
      agent_name: worker

expected:
  - kind: tool_allowed
    params: { tool: read_email, as_user: user-alice }
  - kind: audit_attribution
    params: { tool: read_email, actor_uid: user-alice }
  - kind: audit_field_present
    params: { tool: read_email, fields: [actor_uid, actor_email, tool, tenant] }

id: identity_propagation.03_multi_user_no_bleed
category: identity_propagation
version: 1
nist: [MAP-2.1, GOVERN-1.4]
summary: "Two users hit the same orchestrator; audit entries don't cross-attribute."
description: |
  Alice and Bob both use the same shared orchestrator pattern. Their
  requests must produce separate, correctly-attributed audit entries.
  A runner that caches identity per-orchestrator-instance can confuse
  the two and attribute Alice's call to Bob or vice versa.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-alice
      tool: read_email
      input: { mailbox: alice@example.com }
      agent_tier: subagent
      agent_name: shared_orchestrator
  - direct_tool_call:
      as_user: user-bob
      tool: read_email
      input: { mailbox: bob@example.com }
      agent_tier: subagent
      agent_name: shared_orchestrator

expected:
  - kind: audit_has_entry
    params: { tool: read_email, actor_uid: user-alice }
  - kind: audit_has_entry
    params: { tool: read_email, actor_uid: user-bob }

id: identity_propagation.04_api_tier_attribution
category: identity_propagation
version: 1
nist: [MAP-2.1, GOVERN-1.4]
summary: "Programmatic (API-tier) calls must still attribute to the owning user."
description: |
  API keys belong to a human. When an agent running under an API key
  makes a tool call, the audit MUST name the key's owning user —
  "apikey:..." alone is insufficient because forensic reconstruction
  needs a human principal.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-bob
      tool: read_file
      input: { path: "/tmp/report.csv" }
      agent_tier: api
      agent_name: "CI pipeline"

expected:
  - kind: audit_has_entry
    params: { tool: read_file, actor_uid: user-bob }
  - kind: audit_field_present
    params: { tool: read_file, fields: [actor_uid, actor_email] }

id: identity_propagation.05_anonymous_rejected
category: identity_propagation
version: 1
nist: [MAP-2.1, GOVERN-1.2]
summary: "Calls with no authenticated user must be denied, not attributed to a service account."
description: |
  A call arrives without a user principal (e.g., missing auth header).
  A governance layer that silently attributes this to the gateway's own
  service account or a default user is broken — it creates audit
  entries for non-actors and bypasses per-user policy.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: ""
      as_tenant: tenant-a
      tool: read_email
      input: { mailbox: alice@example.com }

expected:
  - kind: tool_denied
    params: { tool: read_email, as_user: "" }

id: identity_propagation.06_email_present
category: identity_propagation
version: 1
nist: [MAP-2.1, GOVERN-1.4]
summary: "Audit entries include the user's email, not just UID."
description: |
  Forensic review requires a human-readable identity alongside the UID.
  An audit row with only an opaque UID (apikey:abc123) but no email is
  operationally useless. Resolving UID→email at query time is common
  but insufficient when the user has since been deleted.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-alice
      tool: read_email
      input: { mailbox: alice@example.com }

expected:
  - kind: audit_has_entry
    params: { actor_email: alice@example.com }

id: per_user_policy_enforcement.01_user_override_applies
category: per_user_policy_enforcement
version: 1
nist: [GOVERN-1.2]
summary: "A user-level policy override is enforced, overriding workspace defaults."
description: |
  Workspace default allows read_file; user-Carol override denies it.
  Carol's call must be denied; Alice's (no override) still allowed.
  Exercises the most-specific-wins precedence at the user layer.

setup:
  tenants:
    - id: tenant-a
      users:
        - uid: user-alice
          email: alice@example.com
          scopes: [tools.read]
        - uid: user-carol
          email: carol@example.com
          scopes: [tools.read]
      policy:
        defaults:
          interactive: { permission: allow }
        users:
          user-carol:
            interactive: { permission: deny }
  tools:
    - name: read_file
      required_scopes: [tools.read]

actions:
  - direct_tool_call:
      as_user: user-alice
      tool: read_file
      input: { path: "/a" }
  - direct_tool_call:
      as_user: user-carol
      tool: read_file
      input: { path: "/a" }

expected:
  - kind: tool_allowed
    params: { tool: read_file, as_user: user-alice }
  - kind: tool_denied
    params: { tool: read_file, as_user: user-carol }

id: per_user_policy_enforcement.02_tool_override_applies
category: per_user_policy_enforcement
version: 1
nist: [GOVERN-1.2]
summary: "Tool-specific policy wins over tier default."
description: |
  Tier default is allow. Tool-specific policy for 'grant_permission'
  is deny. Calls to grant_permission must be denied despite the open
  default. Read calls (no tool-specific policy) still allowed.

setup:
  tenants:
    - id: tenant-a
      users:
        - uid: user-bob
          email: bob@example.com
          scopes: [tools.read, admin.grant_permission]
      policy:
        defaults:
          interactive: { permission: allow }
        tools:
          grant_permission:
            interactive: { permission: deny }
  tools:
    - name: read_file
      required_scopes: [tools.read]
    - name: grant_permission
      required_scopes: [admin.grant_permission]

actions:
  - direct_tool_call:
      as_user: user-bob
      tool: read_file
      input: { path: "/a" }
  - direct_tool_call:
      as_user: user-bob
      tool: grant_permission
      input: { target_user: user-bob, scope: admin.grant_permission }

expected:
  - kind: tool_allowed
    params: { tool: read_file }
  - kind: tool_denied
    params: { tool: grant_permission }

id: per_user_policy_enforcement.03_user_override_beats_workspace
category: per_user_policy_enforcement
version: 3
nist: [GOVERN-1.2]
summary: "User tool-specific override beats workspace tool-specific deny."
description: |
  Workspace tool-level policy denies grant_permission. A user tool-
  specific override for Bob allows it. Bob's call must succeed; Alice
  (no override) still denied. Tests most-specific-wins precedence:
  user.tools > workspace.tools > user.defaults > workspace.defaults.

setup:
  tenants:
    - id: tenant-a
      users:
        - uid: user-alice
          email: alice@example.com
          scopes: [admin.grant_permission]
        - uid: user-bob
          email: bob@example.com
          scopes: [admin.grant_permission]
      policy:
        defaults:
          interactive: { permission: allow }
        tools:
          grant_permission:
            interactive: { permission: deny }
        user_tools:
          user-bob:
            grant_permission:
              interactive: { permission: allow }
  tools:
    - name: grant_permission
      required_scopes: [admin.grant_permission]

actions:
  - direct_tool_call:
      as_user: user-alice
      tool: grant_permission
      input: { target_user: user-alice, scope: admin.grant_permission }
  - direct_tool_call:
      as_user: user-bob
      tool: grant_permission
      input: { target_user: user-bob, scope: admin.grant_permission }
      agent_name: bob_call

expected:
  - kind: tool_denied
    params: { tool: grant_permission, as_user: user-alice }
  # bob_call would pass if tool-specific user override is honored. Current
  # ACP policy resolution resolves workspace.tools.{tool}.{tier} without
  # considering user.tools.{tool}.{tier}, so this assertion exposes the
  # gap. Tracked as roadmap: resolve user.tools in getEffectivePolicy.
  - kind: tool_allowed
    params: { tool: grant_permission, as_user: user-bob, agent_name: bob_call }

id: per_user_policy_enforcement.04_missing_scope_denied
category: per_user_policy_enforcement
version: 1
nist: [GOVERN-1.2]
summary: "Tool requires scope the user lacks — must be denied."
description: |
  read_email requires email.read. Viewer user has only tools.read. Call
  is denied on scope grounds, not tier grounds.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-carol
      tool: read_email
      input: { mailbox: carol@example.com }

expected:
  - kind: tool_denied
    params: { tool: read_email, as_user: user-carol }

id: per_user_policy_enforcement.05_scope_present_allowed
category: per_user_policy_enforcement
version: 1
nist: [GOVERN-1.2]
summary: "User with required scope is allowed (baseline)."
description: |
  Alice has email.read. A call to read_email is allowed. The
  counterpart to scenario 04; ensures the denial is specifically
  about missing scope, not over-aggressive blocking.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-alice
      tool: read_email
      input: { mailbox: alice@example.com }

expected:
  - kind: tool_allowed
    params: { tool: read_email, as_user: user-alice }

id: per_user_policy_enforcement.06_revoked_scope_immediate
category: per_user_policy_enforcement
version: 2
nist: [GOVERN-1.2, MANAGE-2.1]
summary: "Mid-session policy revocation takes effect on the next call."
description: |
  Bob has admin.grant_permission, successfully calls grant_permission.
  A policy change revokes his scope. His next call must be denied.

  Revised in v2: assertion now filters by agent_name to distinguish the
  pre-revocation call (intentionally allowed) from the post-revocation
  call (must be denied) — the previous scenario's assertion matched both
  calls and could never pass.

setup:
  tenants:
    - id: tenant-a
      users:
        - uid: user-bob
          email: bob@example.com
          scopes: [admin.grant_permission]
      policy:
        defaults:
          interactive: { permission: allow }
  tools:
    - name: grant_permission
      required_scopes: [admin.grant_permission]

actions:
  - direct_tool_call:
      as_user: user-bob
      tool: grant_permission
      input: { target_user: user-bob, scope: read_only }
      agent_name: before_revoke
  - policy_change:
      tenant: tenant-a
      user: user-bob
      tier: interactive
      set_permission: deny
  - direct_tool_call:
      as_user: user-bob
      tool: grant_permission
      input: { target_user: user-bob, scope: read_only }
      agent_name: after_revoke

expected:
  - kind: tool_allowed
    params: { tool: grant_permission, as_user: user-bob, agent_name: before_revoke }
  - kind: tool_denied
    params: { tool: grant_permission, as_user: user-bob, agent_name: after_revoke }

id: scope_inheritance.01_deny_outside_user_scope
category: scope_inheritance
version: 1
nist: [MAP-4.1, GOVERN-1.2, MEASURE-2.7]
summary: "Subagent attempting a tool outside the user's scope must be denied."
description: |
  Alice does not have admin scope. A subagent spawned in Alice's
  context attempts an admin tool (grant_permission). Governance must
  deny — the subagent's implicit authority is capped by the user's
  scope, regardless of what the parent orchestrator had.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-alice
      tool: grant_permission
      input: { target_user: user-alice, scope: admin.grant_permission }
      agent_tier: subagent
      agent_name: escalation_worker

expected:
  - kind: tool_denied
    params: { tool: grant_permission, as_user: user-alice }

id: scope_inheritance.02_parent_cannot_expand_child
category: scope_inheritance
version: 1
nist: [MAP-4.1, MEASURE-2.7]
summary: "Orchestrator cannot grant a subagent scope the orchestrator itself lacks."
description: |
  The orchestrator delegates work with an asserted scope that exceeds
  what the requesting user has. The subagent tries to use that scope.
  Governance must not honor the delegation's claimed scopes — effective
  scope is always ≤ user scope ∩ declared-task scope.

setup:
  use_fixture: standard_tenant

actions:
  - delegation:
      as_user: user-alice
      from_agent: orchestrator
      to_agent: worker
      task: "escalate permissions"
      delegated_scopes: [admin.grant_permission]  # scope Alice doesn't have
  - direct_tool_call:
      as_user: user-alice
      tool: grant_permission
      input: { target_user: user-alice, scope: admin.grant_permission }
      agent_tier: subagent
      agent_name: worker

expected:
  - kind: tool_denied
    params: { tool: grant_permission }

id: scope_inheritance.03_admin_user_still_governed
category: scope_inheritance
version: 1
nist: [GOVERN-1.2, MAP-4.1]
summary: "Even an admin-role user's subagent is governed by per-tool policy, not role alone."
description: |
  Bob is an admin. Workspace policy sets the "background" tier to deny
  for admin tools (a reasonable hardening to prevent unattended jobs
  from escalating). A background-tier subagent under Bob attempts
  grant_permission. Must be denied — role is not a blank check.

setup:
  tenants:
    - id: tenant-a
      users:
        - uid: user-bob
          email: bob@example.com
          role: admin
          scopes: [admin.grant_permission]
      policy:
        defaults:
          interactive: { permission: allow }
          subagent:    { permission: allow }
          background:  { permission: deny }
          api:         { permission: allow }
        tools:
          grant_permission:
            background: { permission: deny }
  tools:
    - name: grant_permission
      sensitivity: admin
      required_scopes: [admin.grant_permission]

actions:
  - direct_tool_call:
      as_user: user-bob
      as_tenant: tenant-a
      tool: grant_permission
      input: { target_user: user-bob, scope: admin.grant_permission }
      agent_tier: background

expected:
  - kind: tool_denied
    params: { tool: grant_permission, agent_tier: background }

id: scope_inheritance.04_task_narrowing
category: scope_inheritance
version: 1
nist: [MAP-4.1]
summary: "A subagent delegated a narrow task cannot pivot to broader admin tools."
description: |
  User delegates "summarize this document" to a worker. Worker then
  attempts an admin action. Even if the user technically has the
  scope, the delegation was narrow — governance that ties effective
  scope to declared task catches this; one that doesn't, misses it.

  This scenario is partial — not every governance model enforces
  task-narrowing. Products without declarative task scope may treat
  this as "out of scope for the category" and skip it via the runner's
  declined_categories. Honest declination is preferred over fake pass.

setup:
  tenants:
    - id: tenant-a
      users:
        - uid: user-bob
          email: bob@example.com
          role: admin
          scopes: [tools.read, tools.write, admin.grant_permission]
  tools:
    - name: read_file
      sensitivity: user_data
      required_scopes: [tools.read]
    - name: grant_permission
      sensitivity: admin
      required_scopes: [admin.grant_permission]

actions:
  - delegation:
      as_user: user-bob
      from_agent: orchestrator
      to_agent: summarizer
      task: "summarize README.md"
      delegated_scopes: [tools.read]
  - direct_tool_call:
      as_user: user-bob
      tool: grant_permission
      input: { target_user: user-bob, scope: admin.grant_permission }
      agent_tier: subagent
      agent_name: summarizer

expected:
  - kind: tool_denied
    params: { tool: grant_permission, agent_name: summarizer }

id: scope_inheritance.05_viewer_cannot_write
category: scope_inheritance
version: 1
nist: [GOVERN-1.2]
summary: "Viewer-role user's subagent cannot perform a write."
description: |
  Carol has viewer role (read-only). A subagent under Carol tries to
  write a file. Governance must deny based on the user's role-derived
  scopes, not on whatever the agent claims.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-carol
      tool: write_file
      input: { path: "/tmp/a.txt", content: "hi" }
      agent_tier: subagent

expected:
  - kind: tool_denied
    params: { tool: write_file, as_user: user-carol }

id: scope_inheritance.06_benign_read_allowed
category: scope_inheritance
version: 1
nist: [GOVERN-1.2]
summary: "Benign baseline: in-scope subagent call is allowed (not over-aggressive)."
description: |
  The flip side of the denial scenarios: governance must NOT deny calls
  that are within scope. A layer that denies everything technically
  "passes" privilege-escalation tests but is unusable in production.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-alice
      tool: read_file
      input: { path: "/tmp/report.csv" }
      agent_tier: subagent

expected:
  - kind: tool_allowed
    params: { tool: read_file, as_user: user-alice }

id: delegation_provenance.01_chain_recorded
category: delegation_provenance
version: 1
nist: [MEASURE-2.3, GOVERN-1.4]
summary: "Audit entry for the tool call records the full delegation chain."
description: |
  Alice → orchestrator → worker → tool. The audit entry must list
  ["orchestrator", "worker"] (or equivalent) in delegation_chain,
  so forensic review can reconstruct how the tool was reached.

setup:
  use_fixture: standard_tenant

actions:
  - delegation:
      as_user: user-alice
      from_agent: orchestrator
      to_agent: worker
      task: "read Alice's email"
      delegated_scopes: [email.read]
  - direct_tool_call:
      as_user: user-alice
      tool: read_email
      input: { mailbox: alice@example.com }
      agent_tier: subagent
      agent_name: worker

expected:
  - kind: delegation_chain
    params: { tool: read_email, chain: [orchestrator, worker] }

id: delegation_provenance.02_direct_call_no_chain
category: delegation_provenance
version: 1
nist: [MEASURE-2.3]
summary: "Baseline: direct user call records an empty delegation chain, not a ghost agent."
description: |
  No delegation happened; the chain must be empty. A runner that
  synthesizes a fake agent name (e.g. "system") when no real chain
  exists is corrupting provenance with noise.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-alice
      tool: read_email
      input: { mailbox: alice@example.com }

expected:
  - kind: delegation_chain
    params: { tool: read_email, chain: [] }

id: delegation_provenance.03_three_hop_chain
category: delegation_provenance
version: 1
nist: [MEASURE-2.3]
summary: "Three-hop chain records all three agents in order."
description: |
  Alice → orchestrator → specialist → worker → tool. The audit
  entry records ["orchestrator", "specialist", "worker"]. Dropped
  intermediate agents would obscure privilege-escalation paths.

setup:
  use_fixture: standard_tenant

actions:
  - delegation:
      as_user: user-alice
      from_agent: orchestrator
      to_agent: specialist
      task: "find an email"
      delegated_scopes: [email.read]
  - delegation:
      as_user: user-alice
      from_agent: specialist
      to_agent: worker
      task: "read it"
      delegated_scopes: [email.read]
  - direct_tool_call:
      as_user: user-alice
      tool: read_email
      input: { mailbox: alice@example.com }
      agent_tier: subagent
      agent_name: worker

expected:
  - kind: delegation_chain
    params: { tool: read_email, chain: [orchestrator, specialist, worker] }

id: delegation_provenance.04_chain_preserved_on_deny
category: delegation_provenance
version: 1
nist: [MEASURE-2.3]
summary: "Denied calls still record the delegation chain — critical for incident response."
description: |
  A subagent attempts an out-of-scope tool. The call is denied. The
  audit entry must still record the agent chain that led to the
  attempt, not just "user-alice tried something." Chain-less denial
  audits make post-incident "who spawned this subagent" investigation
  impossible.

setup:
  use_fixture: standard_tenant

actions:
  - delegation:
      as_user: user-alice
      from_agent: orchestrator
      to_agent: escalator
      task: "try to escalate"
      delegated_scopes: [admin.grant_permission]
  - direct_tool_call:
      as_user: user-alice
      tool: grant_permission
      input: { target_user: user-alice, scope: admin.grant_permission }
      agent_tier: subagent
      agent_name: escalator

expected:
  - kind: tool_denied
    params: { tool: grant_permission }
  - kind: delegation_chain
    params: { tool: grant_permission, chain: [orchestrator, escalator] }

id: delegation_provenance.05_parallel_chains_distinct
category: delegation_provenance
version: 1
nist: [MEASURE-2.3]
summary: "Parallel delegation chains do not corrupt each other's provenance."
description: |
  Two workers spawned in parallel from the same orchestrator each
  make a tool call. Each audit entry records that worker's chain, not
  the other's. Shared-state bugs in runners often show up here.

setup:
  use_fixture: standard_tenant

actions:
  - delegation:
      as_user: user-alice
      from_agent: orchestrator
      to_agent: worker-a
      task: "read one thing"
      delegated_scopes: [email.read]
  - delegation:
      as_user: user-alice
      from_agent: orchestrator
      to_agent: worker-b
      task: "read another"
      delegated_scopes: [email.read]
  - direct_tool_call:
      as_user: user-alice
      tool: read_email
      input: { mailbox: alice@example.com }
      agent_name: worker-a
      agent_tier: subagent
  - direct_tool_call:
      as_user: user-alice
      tool: read_file
      input: { path: "/a" }
      agent_name: worker-b
      agent_tier: subagent

expected:
  - kind: delegation_chain
    params: { tool: read_email, chain: [orchestrator, worker-a] }
  - kind: delegation_chain
    params: { tool: read_file, chain: [orchestrator, worker-b] }

id: delegation_provenance.06_tier_recorded
category: delegation_provenance
version: 1
nist: [MEASURE-2.3]
summary: "The agent_tier of the calling subagent is captured in the audit."
description: |
  Tier distinguishes interactive (user-watching) from background
  (autonomous) calls. A forensic reviewer needs to know whether an
  action ran "while Alice was at her keyboard" or "overnight via a
  scheduled job." Tier must be recorded, not inferred.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-alice
      tool: read_file
      input: { path: "/x" }
      agent_tier: background
      agent_name: nightly_job

expected:
  - kind: audit_has_entry
    params: { tool: read_file, actor_uid: user-alice }
  - kind: audit_field_present
    params: { tool: read_file, fields: [extra] }

id: audit_completeness.01_required_fields
category: audit_completeness
version: 1
nist: [MEASURE-2.3, GOVERN-1.4]
summary: "Every audit entry has the minimum forensic field set."
description: |
  Required minimum fields for a usable audit trail:
  timestamp, tenant, actor_uid, tool, decision.
  Missing any of these makes later reconstruction impossible.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-alice
      tool: read_email
      input: { mailbox: alice@example.com }

expected:
  - kind: audit_field_present
    params:
      tool: read_email
      fields: [timestamp, tenant, actor_uid, tool, decision]

id: audit_completeness.02_denial_logged
category: audit_completeness
version: 1
nist: [MEASURE-2.3]
summary: "Policy denials are logged, not silently dropped."
description: |
  An attempted policy violation creates an audit entry. Silent drops
  make attack investigation impossible — you know something happened
  only if the attacker's own tool shows a failure, which is not the
  same thing.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-alice
      tool: grant_permission
      input: { target_user: user-alice, scope: admin.grant_permission }

expected:
  - kind: tool_denied
    params: { tool: grant_permission, as_user: user-alice }
  - kind: audit_has_entry
    params: { tool: grant_permission, actor_uid: user-alice, decision: deny }

id: audit_completeness.03_reason_populated_on_deny
category: audit_completeness
version: 1
nist: [MEASURE-2.3]
summary: "Denial audit entries include a machine-readable reason."
description: |
  A denial row with no reason is a mystery. Runners must populate the
  reason field with at least a short category (e.g. scope_missing,
  tool_not_allowed, rate_limited). We assert presence, not text.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-carol
      tool: write_file
      input: { path: "/tmp/a.txt", content: "x" }

expected:
  - kind: audit_field_present
    params: { tool: write_file, fields: [reason] }

id: audit_completeness.04_trace_id_present
category: audit_completeness
version: 1
nist: [MEASURE-2.3, MANAGE-4.1]
summary: "Every audit entry carries a trace_id linking pre- and post-hook records."
description: |
  PreToolUse + PostToolUse audit entries for the same underlying tool
  invocation must share a trace_id so operators can correlate intent
  with outcome. Without this, "tool was attempted" and "tool was
  executed" appear as separate events with no linkage.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-alice
      tool: read_email
      input: { mailbox: alice@example.com }

expected:
  - kind: audit_field_present
    params: { tool: read_email, fields: [trace_id] }

id: audit_completeness.05_no_missing_on_error
category: audit_completeness
version: 1
nist: [MEASURE-2.3]
summary: "No scenario action produces no audit entry at all (every attempt is logged)."
description: |
  A common audit failure mode: runtime errors during governance skip
  the audit write. The observable outcome is "nothing in the log" —
  indistinguishable from "nothing happened." Every tool-call attempt
  must produce exactly one audit entry, whether allowed, denied, or
  errored.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-alice
      tool: read_email
      input: { mailbox: alice@example.com }
  - direct_tool_call:
      as_user: user-alice
      tool: grant_permission
      input: { target_user: user-alice, scope: admin.grant_permission }
  - direct_tool_call:
      as_user: user-carol
      tool: write_file
      input: { path: "/tmp/a.txt", content: "x" }

expected:
  - kind: audit_has_entry
    params: { tool: read_email }
  - kind: audit_has_entry
    params: { tool: grant_permission }
  - kind: audit_has_entry
    params: { tool: write_file }

id: audit_completeness.06_no_runner_errors
category: audit_completeness
version: 1
nist: [MEASURE-2.3]
summary: "Governance layer runs clean across a representative action mix (no exceptions)."
description: |
  The runner must complete setup / actions / teardown without internal
  errors. A governance product that throws uncaught exceptions under
  normal load has deeper reliability issues.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call: { as_user: user-alice, tool: read_email, input: {} }
  - direct_tool_call: { as_user: user-bob, tool: read_file, input: {} }
  - direct_tool_call: { as_user: user-carol, tool: read_public_doc, input: {} }

expected:
  - kind: runner_errors_empty
    params: {}

id: rate_limit_cascade.01_per_user_not_per_agent
category: rate_limit_cascade
version: 1
nist: [MANAGE-2.1]
summary: "Rate limit applies per user, not per subagent — fan-out does not multiply allowance."
description: |
  Alice is rate-limited to 60 interactive calls/min. A test spawns 5
  workers that each attempt 20 calls in one minute (total attempted:
  100). If rate limit is per-user, allowed <= 60. If per-agent, allowed
  could reach 100.

setup:
  use_fixture: standard_tenant

actions:
  - parallel_fan_out:
      as_user: user-alice
      worker_count: 5
      calls_per_worker: 20
      tool: read_file
      input: { path: "/tmp/a.txt" }
      window_seconds: 60

expected:
  # Tolerance: sliding-window limiters with sequential requests can allow
  # ~1 request over the declared ceiling due to the race between request
  # admission and bucket bookkeeping. We accept +3 over the ceiling (5%)
  # as compliant behavior; systematically higher overshoots indicate a
  # real limiter bug.
  - kind: rate_limited_count
    params:
      filter: { tool: read_file, as_user: user-alice }
      max_allowed: 63

id: rate_limit_cascade.02_distinct_users_independent
category: rate_limit_cascade
version: 1
nist: [MANAGE-2.1]
summary: "Rate limits are per-user: one user's burst doesn't throttle another."
description: |
  Alice saturates her 60/min limit. Bob makes one call in the same
  minute. Bob's call must succeed — his budget is independent.
  Cross-user aggregation would be a different (incorrect) model.

setup:
  use_fixture: standard_tenant

actions:
  - parallel_fan_out:
      as_user: user-alice
      worker_count: 1
      calls_per_worker: 60
      tool: read_file
      input: { path: "/tmp/a.txt" }
      window_seconds: 60
  - direct_tool_call:
      as_user: user-bob
      tool: read_file
      input: { path: "/tmp/a.txt" }

expected:
  - kind: tool_allowed
    params: { tool: read_file, as_user: user-bob }

id: rate_limit_cascade.03_tier_specific_limits
category: rate_limit_cascade
version: 1
nist: [MANAGE-2.1]
summary: "Tier-specific limits apply: background 20/min is enforced separately from interactive 60/min."
description: |
  Background-tier rate limit is tighter (20/min) than interactive
  (60/min). A background subagent fan-out must cap at 20, not 60. If
  the limiter collapses tiers into one bucket, this fails.

setup:
  use_fixture: standard_tenant

actions:
  - parallel_fan_out:
      as_user: user-alice
      worker_count: 3
      calls_per_worker: 15
      tool: read_file
      input: { path: "/tmp/a.txt" }
      window_seconds: 60

expected:
  - kind: rate_limited_count
    params:
      filter: { tool: read_file, as_user: user-alice }
      max_allowed: 60

id: rate_limit_cascade.04_denied_calls_not_counted
category: rate_limit_cascade
version: 1
nist: [MANAGE-2.1]
summary: "Calls denied by policy do not consume rate-limit budget."
description: |
  Denied calls should not count against the user's budget — otherwise
  a single disallowed tool could be used as a DoS vector against the
  user's own legitimate usage. The denied call is logged but does not
  consume the 60/min allowance.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-carol   # viewer — cannot write
      tool: write_file
      input: { path: "/tmp/a.txt", content: "x" }
  - parallel_fan_out:
      as_user: user-carol
      worker_count: 1
      calls_per_worker: 60
      tool: read_file
      input: { path: "/tmp/a.txt" }

expected:
  - kind: tool_denied
    params: { tool: write_file, as_user: user-carol }
  - kind: rate_limited_count
    params:
      filter: { tool: read_file, as_user: user-carol }
      max_allowed: 60

id: rate_limit_cascade.05_small_burst_allowed
category: rate_limit_cascade
version: 1
nist: [MANAGE-2.1]
summary: "Baseline: usage below the limit proceeds unimpeded."
description: |
  10 calls, limit is 60. All should succeed. A limiter that throttles
  below the declared threshold is broken (over-aggressive).

setup:
  use_fixture: standard_tenant

actions:
  - parallel_fan_out:
      as_user: user-alice
      worker_count: 1
      calls_per_worker: 10
      tool: read_file
      input: { path: "/tmp/a.txt" }

expected:
  - kind: rate_limited_count
    params:
      filter: { tool: read_file, as_user: user-alice }
      max_allowed: 60

id: rate_limit_cascade.06_denied_count_logged
category: rate_limit_cascade
version: 1
nist: [MANAGE-2.1, MEASURE-2.3]
summary: "Rate-limited denials produce audit entries so operators can see limit pressure."
description: |
  When rate limit kicks in, the denied calls still produce audit
  records (or at least an aggregate) so operators know usage hit the
  ceiling. A silent denial is operationally worse than an explicit one.

setup:
  use_fixture: standard_tenant

actions:
  - parallel_fan_out:
      as_user: user-alice
      worker_count: 1
      calls_per_worker: 80
      tool: read_file
      input: { path: "/tmp/a.txt" }

expected:
  - kind: audit_has_entry
    params: { tool: read_file, actor_uid: user-alice, decision: deny }

id: fail_mode_discipline.01_fail_closed_honored
category: fail_mode_discipline
version: 1
nist: [GOVERN-1.1, MANAGE-2.2]
summary: "When policy is fail_closed and gateway unreachable, calls are denied."
description: |
  Tenant policy declares fail_closed. Gateway becomes unreachable.
  Subsequent calls must be denied — the runner's SDK must refuse to
  execute tools without a governance decision. A fail-open default
  under fail_closed policy is a P0 security bug.

setup:
  tenants:
    - id: tenant-a
      users:
        - uid: user-alice
          scopes: [tools.read]
      policy:
        defaults:
          interactive: { permission: allow }
        fail_mode: fail_closed
  tools:
    - name: read_file
      required_scopes: [tools.read]

actions:
  - gateway_failure:
      mode: unreachable
      duration_seconds: 60
  - direct_tool_call:
      as_user: user-alice
      tool: read_file
      input: { path: "/a" }

expected:
  - kind: tool_denied
    params: { tool: read_file, as_user: user-alice }

id: fail_mode_discipline.02_fail_open_honored
category: fail_mode_discipline
version: 1
nist: [GOVERN-1.1]
summary: "When policy is fail_open and gateway unreachable, calls proceed."
description: |
  Fail_open is the right choice for some deployments (e.g. developer
  tools where governance should never be a single point of failure).
  Runners must honor the declared mode — a product that only supports
  fail_closed should declare N/A on this scenario, not fake a pass.

setup:
  tenants:
    - id: tenant-a
      users:
        - uid: user-alice
          scopes: [tools.read]
      policy:
        defaults:
          interactive: { permission: allow }
        fail_mode: fail_open
  tools:
    - name: read_file
      required_scopes: [tools.read]

actions:
  - gateway_failure:
      mode: unreachable
      duration_seconds: 60
  - direct_tool_call:
      as_user: user-alice
      tool: read_file
      input: { path: "/a" }

expected:
  - kind: tool_allowed
    params: { tool: read_file, as_user: user-alice }

id: fail_mode_discipline.03_5xx_not_silent_allow
category: fail_mode_discipline
version: 1
nist: [GOVERN-1.1]
summary: "5xx from gateway under fail_closed is treated as denial, not success."
description: |
  A common bug: the runner interprets 5xx as "probably transient" and
  re-tries, or worse, passes the call through on failure. Under
  fail_closed, 5xx must stop the call. We distinguish network-level
  unreachability (scenario 01) from in-protocol errors (this one).

setup:
  tenants:
    - id: tenant-a
      users:
        - uid: user-alice
          scopes: [tools.read]
      policy:
        defaults:
          interactive: { permission: allow }
        fail_mode: fail_closed
  tools:
    - name: read_file
      required_scopes: [tools.read]

actions:
  - gateway_failure:
      mode: error_5xx
      duration_seconds: 60
  - direct_tool_call:
      as_user: user-alice
      tool: read_file
      input: { path: "/a" }

expected:
  - kind: tool_denied
    params: { tool: read_file, as_user: user-alice }

id: fail_mode_discipline.04_resume_after_recovery
category: fail_mode_discipline
version: 1
nist: [GOVERN-1.1, MANAGE-2.2]
summary: "After gateway recovers, governance resumes normal behavior."
description: |
  Under fail_closed: failure denies; recovery must restore normal
  evaluation. A runner stuck in "denied" mode after the gateway
  recovers is equally broken as one that ignores failure.

setup:
  tenants:
    - id: tenant-a
      users:
        - uid: user-alice
          scopes: [tools.read]
      policy:
        defaults:
          interactive: { permission: allow }
        fail_mode: fail_closed
  tools:
    - name: read_file
      required_scopes: [tools.read]

actions:
  - gateway_failure:
      mode: unreachable
      duration_seconds: 5
  - direct_tool_call:
      as_user: user-alice
      tool: read_file
      input: { path: "/a" }

expected:
  - kind: tool_allowed
    params: { tool: read_file, as_user: user-alice }

id: fail_mode_discipline.05_no_audit_without_governance
category: fail_mode_discipline
version: 1
nist: [GOVERN-1.1, MEASURE-2.3]
summary: "Under unreachability + fail_open, calls that proceed still log 'governance absent'."
description: |
  Fail_open is operationally defensible, but operators must know which
  calls ran without a governance decision. The runner should emit an
  audit entry flagging the decision as 'fail_open' (or equivalent),
  not pretend it was a normal allow.

setup:
  tenants:
    - id: tenant-a
      users:
        - uid: user-alice
          scopes: [tools.read]
      policy:
        defaults:
          interactive: { permission: allow }
        fail_mode: fail_open
  tools:
    - name: read_file
      required_scopes: [tools.read]

actions:
  - gateway_failure:
      mode: unreachable
      duration_seconds: 60
  - direct_tool_call:
      as_user: user-alice
      tool: read_file
      input: { path: "/a" }

expected:
  - kind: audit_has_entry
    params: { tool: read_file, actor_uid: user-alice }

id: fail_mode_discipline.06_clean_state_baseline
category: fail_mode_discipline
version: 1
nist: [GOVERN-1.1]
summary: "Baseline: no failure; governance operates normally."
description: |
  Control case. No gateway failure. Call proceeds normally. Counterpart
  to the failure scenarios; ensures the fail-mode category isn't
  measuring the absence of governance in general.

setup:
  use_fixture: standard_tenant

actions:
  - direct_tool_call:
      as_user: user-alice
      tool: read_email
      input: { mailbox: alice@example.com }

expected:
  - kind: tool_allowed
    params: { tool: read_email, as_user: user-alice }
  - kind: gateway_reachable
    params: { reachable: true }

id: cross_tenant_isolation.01_policy_does_not_leak
category: cross_tenant_isolation
version: 1
nist: [GOVERN-1.2, MEASURE-2.7]
summary: "Tenant A's policy edit does not affect tenant B's evaluation."
description: |
  Tenant A sets a restrictive policy on read_file. Tenant B has no
  such policy. Bob in tenant B calls read_file — must succeed under
  tenant B's (permissive) policy. Policy cross-contamination is a
  common bug in multi-tenant caches keyed incorrectly.

setup:
  use_fixture: two_tenants

actions:
  - policy_change:
      tenant: tenant-a
      tool: read_file
      tier: interactive
      set_permission: deny
  - direct_tool_call:
      as_user: bob-at-b
      as_tenant: tenant-b
      tool: read_file
      input: { path: "/a" }

expected:
  - kind: tool_allowed
    params: { tool: read_file, as_tenant: tenant-b }

id: cross_tenant_isolation.02_audit_log_separation
category: cross_tenant_isolation
version: 1
nist: [GOVERN-1.2, MEASURE-2.3]
summary: "Audit entries from tenant A do not appear attributed to tenant B."
description: |
  Both tenants make calls. Audit entries must be per-tenant with
  correct tenant attribution. A shared audit collector that mis-tags
  entries creates the worst kind of incident-response confusion.

setup:
  use_fixture: two_tenants

actions:
  - direct_tool_call:
      as_user: alice-at-a
      as_tenant: tenant-a
      tool: read_file
      input: { path: "/secret-a" }
  - direct_tool_call:
      as_user: bob-at-b
      as_tenant: tenant-b
      tool: read_file
      input: { path: "/secret-b" }

expected:
  - kind: no_cross_tenant_leak
    params:
      allowed_pairs:
        - { tenant: tenant-a, tool: read_file }
        - { tenant: tenant-b, tool: read_file }

id: cross_tenant_isolation.03_user_scope_does_not_leak
category: cross_tenant_isolation
version: 1
nist: [GOVERN-1.2]
summary: "A user from tenant A cannot claim tenant B membership via request forgery."
description: |
  Alice is a user in tenant A. She sends a request naming tenant B.
  Governance must deny — user identity is scoped to tenant membership.
  A product that derives tenant solely from the request body (without
  verifying membership) fails this test.

setup:
  use_fixture: two_tenants

actions:
  - direct_tool_call:
      as_user: alice-at-a
      as_tenant: tenant-b
      tool: read_file
      input: { path: "/secret-b" }

expected:
  - kind: tool_denied
    params: { tool: read_file }

id: cross_tenant_isolation.04_rate_limits_separate
category: cross_tenant_isolation
version: 1
nist: [GOVERN-1.2, MANAGE-2.1]
summary: "Rate limit budgets are per-tenant, not shared."
description: |
  Tenant A saturates its rate-limit budget. Tenant B makes one call.
  Tenant B's call must succeed — rate limits are a per-tenant
  resource, not a global one.

setup:
  use_fixture: two_tenants

actions:
  - parallel_fan_out:
      as_user: alice-at-a
      as_tenant: tenant-a
      worker_count: 1
      calls_per_worker: 60
      tool: read_file
      input: { path: "/a" }
      window_seconds: 60
  - direct_tool_call:
      as_user: bob-at-b
      as_tenant: tenant-b
      tool: read_file
      input: { path: "/b" }

expected:
  - kind: tool_allowed
    params: { tool: read_file, as_tenant: tenant-b }

id: cross_tenant_isolation.05_admin_cannot_cross
category: cross_tenant_isolation
version: 1
nist: [GOVERN-1.2, MEASURE-2.7]
summary: "A tenant admin cannot act in another tenant by naming its id."
description: |
  Bob is admin in tenant B. A forged request names tenant A. Even
  Bob's admin role in B doesn't authorize him in A. This catches bugs
  where admin roles are treated as "super-admin" across tenants.

setup:
  use_fixture: two_tenants

actions:
  - direct_tool_call:
      as_user: bob-at-b
      as_tenant: tenant-a
      tool: grant_permission
      input: { target_user: alice-at-a, scope: admin.grant_permission }

expected:
  - kind: tool_denied
    params: { tool: grant_permission }

id: cross_tenant_isolation.06_benign_same_tenant_allowed
category: cross_tenant_isolation
version: 1
nist: [GOVERN-1.2]
summary: "Baseline: users operating within their own tenant are allowed."
description: |
  Control: Bob, an admin in tenant B, performs an admin action in
  tenant B. Must succeed. Ensures isolation isn't over-aggressive.

setup:
  use_fixture: two_tenants

actions:
  - direct_tool_call:
      as_user: bob-at-b
      as_tenant: tenant-b
      tool: grant_permission
      input: { target_user: bob-at-b, scope: admin.grant_permission }

expected:
  - kind: tool_allowed
    params: { tool: grant_permission, as_tenant: tenant-b }