docs: add SCITT agent action capsule research note

docs/superpowers/plans/2026-09-17-scitt-agent-action-capsule-research-note.md

@@ -0,0 +1,30 @@
+# SCITT Agent Action Capsule Research Note Implementation Plan
+
+> **For agentic workers:** Execute this plan inline with validation checkpoints.
+
+**Goal:** Add and publish a sourced research note on SCITT and Agent Action Capsule for verifiable agent-action provenance in Cloud Foundry.
+
+**Architecture:** Explain SCITT as the transparency and receipt layer, and Agent Action Capsule as an individual Internet-Draft profile for digest-committed action statements and COSE producer envelopes. Map certificate-backed CF workload identity and platform events to provenance records without claiming existing integration.
+
+**Tech Stack:** Markdown, YAML frontmatter, Devbox, Git, GitHub CLI.
+
+---
+
+### Task 1: Write the research note
+
+**Files:**
+- Create: `research/scitt-agent-action-capsule.md`
+
+- [ ] Add frontmatter with title `SCITT and Agent Action Capsule: Verifiable Agent-Action Provenance`, author `Ruben Koster (@rkoster)`, date `2026-09-17`, tags `[observability-governance, authorization, identity, ecosystem-survey]`, `cf_areas: [uaa, capi, diego, loggregator]`, `status: draft`, provisional ratings, and SCITT/Agent Action Capsule/Datatracker sources.
+- [ ] Explain SCITT's transparency-service role and separate it from the Agent Action Capsule statement profile.
+- [ ] Cover capsule canonicalization, digest identity, chain, verdict/refusal records, COSE_Sign1 producer envelopes, signer-independent identity, and Class-1/envelope/receipt verification.
+- [ ] State that SCITT architecture and receipt specifications are RFCs while Agent Action Capsule is an individual Internet-Draft, not an adopted WG document or RFC.
+- [ ] Analyze a CF boundary where a gateway verifies an instance identity certificate, records agent identity and authorization context, emits a capsule, and submits/registers evidence with a transparency service.
+- [ ] Discuss UAA/CAPI/Diego event correlation, Loggregator/audit integration, privacy and redaction, receipt availability, signer authorization, revocation, and non-repudiation.
+- [ ] Add open questions about subject identity, policy evidence, refusal semantics, retention, tenant isolation, and verifier trust.
+
+### Task 2: Validate and publish
+
+- [ ] Run `devbox run validate`, `devbox run test`, and `git diff --check`.
+- [ ] Stage only the note and approved spec/plan, commit `docs: add SCITT agent action capsule research note`, push `research/scitt-agent-action-capsule`, and open a checklist-complete PR targeting `main`.
+- [ ] Verify PR metadata and CI with `gh pr view`.

docs/superpowers/specs/2026-09-17-scitt-agent-action-capsule-research-note-design.md

@@ -0,0 +1,31 @@
+# SCITT Agent Action Capsule Research Note Design
+
+## Goal
+
+Add a sourced research note on using SCITT and the Agent Action Capsule profile to make agent
+actions independently verifiable and auditable in Cloud Foundry environments.
+
+## Scope
+
+The note will explain SCITT's transparency-service architecture and distinguish it from the
+Agent Action Capsule statement profile. It will cover digest-committed capsule identity, COSE
+producer envelopes, chains, verdicts including refusals, Class-1 and envelope/receipt
+verification, and the current Internet-Draft governance status.
+
+The Cloud Foundry analysis will consider instance identity certificates, UAA/CAPI/Diego event
+correlation, authorization evidence, Loggregator integration, receipt storage, privacy, and
+non-repudiation. It will not claim that CF, SCITT, or Agent Action Capsule already integrate.
+
+## Structure and evidence
+
+Create `research/scitt-agent-action-capsule.md` with the required four sections and frontmatter.
+Use the IETF SCITT organization and working-group pages, SCITT architecture/receipts material,
+and the Agent Action Capsule repository, README, specification, registry, and Datatracker
+draft. Explicitly state that Agent Action Capsule is an individual Internet-Draft, not an
+adopted WG document or RFC.
+
+## Validation
+
+Run Devbox validation and tests, inspect whitespace/staged files, commit the note and plan on
+`research/scitt-agent-action-capsule`, push, and open a PR targeting `main` without unrelated
+artifacts.

generated/research-map.html

@@ -23,6 +23,7 @@ <h2 class="section-heading">Focus use cases</h2><div class="card-actions"><butto
 <button id="primitive-attested-workload-authority" class="primitive-select" type="button" data-primitive="attested-workload-authority" aria-pressed="false"><span class="primitive-title">Attested Workload Authority and Mediated Tool Access</span><span>Exchange platform-attested workload identity for scoped authority while credentials and outbound tool access remain mediated by the platform.</span><span class="strategic-decision"><strong>Strategic decision:</strong> Decide whether CF should become the portable trust and policy layer between agent workloads and the tools they invoke.</span></button>
 <details class="primitive-details"><summary>Gap, experiments, and evidence</summary><dl><dt>Current CF gap</dt><dd>CF issues workload identity certificates but does not exchange them for scoped tool authority, keep third-party credentials out of workloads, mediate off-platform access, or record delegation-aware audit events.</dd><dt>Candidate POC</dt><dd>Exchange a Diego instance identity certificate for a short-lived scoped token, invoke one allowed tool through a credential proxy and egress mediator, deny another, and emit attributable audit events.</dd><dt>Candidate RFC scope</dt><dd>Define workload token exchange, authority and delegation claims, credential brokering, outbound mediation and policy enforcement, audit events, revocation, and integration boundaries for UAA, routing, and service brokers.</dd></dl><div class="primitive-links"><section><h4>Core</h4><ul><li><a href="https://github.com/cloudfoundry/agentic-runtime-notes/blob/main/ideas/agent-identity-and-tool-authorization.md">Agent identity and tool authorization — the platform as the agent&#x27;s identity provider</a></li><li><a href="https://github.com/cloudfoundry/agentic-runtime-notes/blob/main/ideas/credential-less-agent-processes.md">Credential-less agent processes</a></li><li><a href="https://github.com/cloudfoundry/agentic-runtime-notes/blob/main/ideas/localhost-only-egress-for-agents.md">Localhost-only egress for agent workloads</a></li><li><a href="https://github.com/cloudfoundry/agentic-runtime-notes/blob/main/research/open-agent-auth.md">Open Agent Auth — IETF Agent Operation Authorization</a></li><li><a href="https://github.com/cloudfoundry/agentic-runtime-notes/blob/main/research/toolhive.md">ToolHive — Secure Runtime and Gateway for MCP Servers</a></li><li><a href="https://github.com/cloudfoundry/agentic-runtime-notes/blob/main/research/mcp-protocol.md">Model Context Protocol (MCP) — Agent-to-Tool Interoperability</a></li></ul></section><section><h4>Supporting</h4><ul><li><a href="https://github.com/cloudfoundry/agentic-runtime-notes/blob/main/research/aws-agents.md">AWS Strands Agents &amp; Bedrock AgentCore — Framework and Managed Runtime</a></li><li><a href="https://github.com/cloudfoundry/agentic-runtime-notes/blob/main/research/vertex-agent-engine.md">Vertex AI Agent Engine (Gemini Enterprise Agent Platform) — Google&#x27;s Managed Agent Runtime</a></li><li><a href="https://github.com/cloudfoundry/agentic-runtime-notes/blob/main/research/anthropic-managed-agents.md">Anthropic Managed Agents — Remote Hands Architecture</a></li><li><a href="https://github.com/cloudfoundry/agentic-runtime-notes/blob/main/research/azure-hosted-agents.md">Azure Foundry — Hosted Agents Model</a></li><li><a href="https://github.com/cloudfoundry/agentic-runtime-notes/blob/main/research/cloudflare-agents.md">Cloudflare Agents SDK — Agents as Durable Objects (V8-Isolate Isolation)</a></li><li><a href="https://github.com/cloudfoundry/agentic-runtime-notes/blob/main/research/opentelemetry-genai.md">OpenTelemetry Semantic Conventions for GenAI</a></li></ul></section></div></details></article><article class="primitive-card" style="--primitive-accent:#8eb8ff">
 <button id="primitive-session-scoped-isolated-execution" class="primitive-select" type="button" data-primitive="session-scoped-isolated-execution" aria-pressed="false"><span class="primitive-title">Session-Scoped Isolated Execution</span><span>Create resumable, session-scoped execution from reusable staged environments, mutable workspaces, selectable isolation, and controlled networking.</span><span class="strategic-decision"><strong>Strategic decision:</strong> Decide whether CF should expose session execution as a composition of existing package, build, droplet, task, volume, networking, and isolation capabilities.</span></button>
+
  function escapeHtml(value){return String(value).replace(/[&<>"']/g,character=>({'&':'&amp;','<':'&lt;','>':'&gt;','"':'&quot;',"'":'&#39;'}[character]))}
  function noteMatchesSelection(noteId){const matchesUseCase=!selectedUseCase||useCaseMemberships[noteId]?.[selectedUseCase];const matchesPrimitive=!selectedPrimitive||primitiveMemberships[noteId]?.[selectedPrimitive];return Boolean(matchesUseCase&&matchesPrimitive)}
  function updateMarkers(){const hasSelection=Boolean(selectedUseCase||selectedPrimitive);document.querySelectorAll('.marker').forEach(m=>{if(m.dataset.noteIds){const noteIds=JSON.parse(m.dataset.noteIds);const matchingCount=hasSelection?noteIds.filter(noteMatchesSelection).length:0;m.textContent=hasSelection?`${matchingCount}/${noteIds.length}`:String(noteIds.length);m.setAttribute('aria-label',hasSelection?`${matchingCount} of ${noteIds.length} matching notes at this position`:`${noteIds.length} notes at this position`);m.classList.toggle('related',matchingCount>0);m.classList.toggle('dimmed',Boolean(hasSelection&&!matchingCount))}else{const related=noteMatchesSelection(m.dataset.id);m.classList.toggle('related',hasSelection&&related);m.classList.toggle('dimmed',hasSelection&&!related)}});const hasMatches=Object.values(plots).some(notes=>notes.some(note=>noteMatchesSelection(note.id)));filterStatus.textContent=selectedUseCase&&selectedPrimitive&&!hasMatches?'No directly linked evidence for this use-case and primitive combination.':''}

research/scitt-agent-action-capsule.md

@@ -0,0 +1,125 @@
+---
+title: "SCITT and Agent Action Capsule: Verifiable Agent-Action Provenance"
+author: Ruben Koster (@rkoster)
+date: 2026-09-17
+tags: [observability-governance, authorization, identity, ecosystem-survey]
+cf_areas: [uaa, capi, diego, loggregator]
+status: draft
+ratings:
+  platform-impact:
+    value: 83
+    note: "Verifiable action records could support governance, incident response, and compliance for agents operating across CF tenants and services."
+  maturity:
+    value: 57
+    note: "SCITT architecture and receipt work is standardized, while Agent Action Capsule remains an individual Internet-Draft profile under active development."
+  novelty:
+    value: 79
+    note: "The capsule profile treats refusals and authorization verdicts as durable evidence and separates content identity from producer signatures."
+  actionability:
+    value: 73
+    note: "CF can prototype provenance at gateways and policy decisions, but identity mapping, privacy, retention, and transparency-service operations remain design work."
+sources:
+  - https://github.com/ietf-scitt
+  - https://datatracker.ietf.org/wg/scitt/about/
+  - https://www.rfc-editor.org/rfc/rfc9943
+  - https://www.rfc-editor.org/rfc/rfc9942
+  - https://github.com/action-state-group/agent-action-capsule
+  - https://raw.githubusercontent.com/action-state-group/agent-action-capsule/main/README.md
+  - https://datatracker.ietf.org/doc/draft-mih-scitt-agent-action-capsule/
+  - https://github.com/action-state-group/agent-action-capsule/blob/main/spec/REGISTRY.md
+---
+
+## Summary
+
+SCITT, Supply Chain Integrity, Transparency, and Trust, defines an architecture for registering
+statements and obtaining verifiable evidence about their inclusion and history in a
+transparency service. Agent Action Capsule is an individual Internet-Draft profile that applies
+that model to recording what an AI agent did, including authorization verdicts and refusals.
+Together they suggest a way for Cloud Foundry to produce independently verifiable provenance
+for agent actions, provided that workload identity, policy context, privacy, and receipt
+handling are designed explicitly.
+
+## Key findings
+
+- **SCITT supplies a transparency boundary, not an agent runtime.** The initiative addresses
+  end-to-end integrity and trust for statements and artifacts. A transparency service can
+  register signed statements and provide receipts that allow later verification of inclusion
+  and history without requiring every verifier to trust the original application database.
+- **Agent Action Capsule is a statement profile.** It defines a digest-committed JSON record of
+  an agent action with signer-independent identity. The profile uses RFC 8785 JSON Canonicalization
+  Scheme and a `capsule_id` derived from the capsule content; changing the signature does not
+  change the capsule identity.
+- **Producer authentication is separate from capsule identity.** One or more independent
+  COSE_Sign1 Producer Envelopes can authenticate the raw capsule ID. This allows verifiers to
+  reason separately about what was recorded and which producer attested to it.
+- **Verdicts include refusals.** The profile records a capsule for every verdict, including a
+  blocked or denied action. A refusal therefore becomes affirmative evidence that a policy gate
+  evaluated and rejected an action rather than an absence of evidence.
+- **Verification has layers.** Capsule Class-1 verification can recompute the content digest
+  from capsule bytes without keys, network access, or a clock. Per-envelope cryptographic
+  verification and caller-defined signer authorization are separate steps, while optional SCITT
+  receipt verification proves transparency-service registration. Merkle data structures belong
+  behind the SCITT registration boundary rather than inside capsule construction.
+- **The standards status must be stated precisely.** The project README identifies SCITT
+  architecture and COSE Receipts as RFC 9943 and RFC 9942. Agent Action Capsule is explicitly
+  described as an individual IETF Internet-Draft, not an adopted SCITT Working Group document
+  and not an RFC.
+- **A capsule can connect authorization to outcome.** A useful action record can include the
+  agent subject, requested action, resource, policy decision, inputs or evidence references,
+  resulting outcome, and links in a chain of related actions. The exact profile vocabulary and
+  registry status remain subject to the draft.
+- **CF identity needs an integration boundary.** A proposed CF design would have a gateway or
+  policy service verify an instance identity certificate, map the verified workload to a stable
+  subject, and include that identity in the capsule. Neither SCITT nor Agent Action Capsule
+  should be assumed to validate CF certificates or know CAPI/Diego identity semantics.
+- **Platform events can enrich provenance.** CAPI and Diego events could correlate application,
+  process, space, binding, deployment, and instance lifecycle with an agent action. Loggregator
+  could provide operational correlation, while the capsule/transparency path supplies a durable
+  verification record. These systems would need clear ownership to avoid conflicting event IDs
+  and incomplete provenance.
+- **Privacy is a first-class constraint.** Agent actions may contain prompts, tool arguments,
+  credentials, personal data, or sensitive results. A capsule should prefer digests and typed
+  references over raw secrets, define redaction and retention policy, and make verifier access
+  tenant-aware.
+
+## CF relevance
+
+Cloud Foundry could emit Agent Action Capsules at policy gateways, agent runtimes, tool brokers,
+or platform API boundaries. For example, a gateway could verify a CF instance identity
+certificate, authenticate the workload as `agent_instance:<id>`, evaluate whether it may invoke
+a tool or mutate a resource, and record an allow or refusal capsule containing the subject,
+resource, policy reference, and outcome. A transparency service could then provide a receipt for
+later audit or independent verification.
+
+This would complement rather than replace Loggregator. Loggregator is useful for operational
+streaming, correlation, and alerting; a SCITT-backed record would be designed for durable,
+cryptographically verifiable provenance. CAPI and Diego events could supply lifecycle context,
+but the system would need to define which component is authoritative for the identity and policy
+facts included in a capsule. Service bindings, tool gateways, and agent controllers could all
+be capsule producers, but their signatures and authorization scopes must be distinguishable.
+
+The design also changes incident-response and compliance workflows. A denied tool invocation
+could be shown as an explicit policy decision, while a successful action could be checked against
+the agent identity, authorization state, and transparency receipt. This is valuable only if
+certificate rotation, revocation, signer authorization, clock/context claims, privacy, and
+retention are handled consistently. CF should avoid recording raw prompts or credentials merely
+to obtain auditability.
+
+## Open questions
+
+- What stable subject should a CF capsule use: app, process instance, instance identity
+  certificate, agent deployment, or a composite identity?
+- Which component verifies instance identity certificates, and how are rotation, revocation,
+  process replacement, and delegated authority represented in the capsule chain?
+- Which authorization policy inputs and evidence references are necessary to make an allow or
+  refusal independently meaningful without storing sensitive request content?
+- Should every tool and platform API action produce a capsule, or should policy gateways emit
+  capsules only for sensitive, delegated, or cross-tenant operations?
+- How should a CF foundation operate or consume a transparency service, and what receipt
+  availability and recovery guarantees are required?
+- How should signer authorization work when multiple gateways, runtimes, and platform services
+  can produce statements for the same agent?
+- How should capsule privacy, retention, deletion requests, tenant isolation, and verifier
+  access interact with immutable transparency records?
+- What is the right relationship between capsule chains, Loggregator correlation IDs, CAPI/Diego
+  event IDs, and distributed traces?