diff --git a/docs/superpowers/plans/2026-09-17-scitt-agent-action-capsule-research-note.md b/docs/superpowers/plans/2026-09-17-scitt-agent-action-capsule-research-note.md new file mode 100644 index 0000000..df20e92 --- /dev/null +++ b/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`. diff --git a/docs/superpowers/specs/2026-09-17-scitt-agent-action-capsule-research-note-design.md b/docs/superpowers/specs/2026-09-17-scitt-agent-action-capsule-research-note-design.md new file mode 100644 index 0000000..9128ebb --- /dev/null +++ b/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. diff --git a/generated/research-map.html b/generated/research-map.html index 0aacdfd..45eec90 100644 --- a/generated/research-map.html +++ b/generated/research-map.html @@ -23,6 +23,7 @@

Focus use cases

Attested Workload Authority and Mediated Tool AccessExchange platform-attested workload identity for scoped authority while credentials and outbound tool access remain mediated by the platform.Strategic decision: Decide whether CF should become the portable trust and policy layer between agent workloads and the tools they invoke.
Gap, experiments, and evidence
Current CF gap
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.
Candidate POC
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.
Candidate RFC scope
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.

Core

Supporting

+ function escapeHtml(value){return String(value).replace(/[&<>"']/g,character=>({'&':'&','<':'<','>':'>','"':'"',"'":'''}[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.':''} diff --git a/research/scitt-agent-action-capsule.md b/research/scitt-agent-action-capsule.md new file mode 100644 index 0000000..36df4cf --- /dev/null +++ b/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:`, 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?