From 4e99ff09ef32542a83f5cc3ad00678026794143e Mon Sep 17 00:00:00 2001 From: rkoster Date: Fri, 18 Sep 2026 12:59:01 +0200 Subject: [PATCH 1/3] docs: define Agent Baseline research note --- ...-18-agent-baseline-research-note-design.md | 29 +++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 docs/superpowers/specs/2026-09-18-agent-baseline-research-note-design.md diff --git a/docs/superpowers/specs/2026-09-18-agent-baseline-research-note-design.md b/docs/superpowers/specs/2026-09-18-agent-baseline-research-note-design.md new file mode 100644 index 0000000..a3eaa55 --- /dev/null +++ b/docs/superpowers/specs/2026-09-18-agent-baseline-research-note-design.md @@ -0,0 +1,29 @@ +# Agent Baseline Research Note Design + +## Goal + +Add a sourced research note on Agent Baseline as an open draft security framework for enterprise +AI agents. + +## Scope + +The note will explain the six outcomes: Discover, Constrain, Authorize, Observe, Validate, and +Respond, along with the 35 controls and evidence-oriented framing. It will treat the project as +a working draft for public comment, not a finalized standard. + +The Cloud Foundry analysis will map the outcomes to CAPI/Diego inventory and lifecycle, UAA and +workload identity, sandbox/network policy, authorization, Loggregator/audit, build and release +validation, revocation, quarantine, and incident response. It will identify where CF supplies +primitives and where agent-specific controls remain missing. + +## Structure and evidence + +Create `research/agent-baseline.md` with the required four sections and frontmatter. Use the +Agent Baseline website, controls, white paper, source repository, and public-comment status. +Clearly distinguish framework requirements from existing CF capabilities and label mappings as +analysis or open questions. + +## Validation + +Run Devbox validation and tests, inspect whitespace/staged files, commit the note and plan on +`research/agent-baseline`, push, and open a PR targeting `main` without unrelated artifacts. From f682780349001e74e0cc7b099f5b69116c013295 Mon Sep 17 00:00:00 2001 From: rkoster Date: Fri, 18 Sep 2026 12:59:44 +0200 Subject: [PATCH 2/3] docs: add Agent Baseline research note --- ...2026-09-18-agent-baseline-research-note.md | 27 +++++ research/agent-baseline.md | 106 ++++++++++++++++++ 2 files changed, 133 insertions(+) create mode 100644 docs/superpowers/plans/2026-09-18-agent-baseline-research-note.md create mode 100644 research/agent-baseline.md diff --git a/docs/superpowers/plans/2026-09-18-agent-baseline-research-note.md b/docs/superpowers/plans/2026-09-18-agent-baseline-research-note.md new file mode 100644 index 0000000..4d0a0bf --- /dev/null +++ b/docs/superpowers/plans/2026-09-18-agent-baseline-research-note.md @@ -0,0 +1,27 @@ +# Agent Baseline Research Note Implementation Plan + +> **For agentic workers:** Execute this plan inline with validation checkpoints. + +**Goal:** Add and publish a sourced research note on Agent Baseline's six security outcomes and 35 controls. + +**Architecture:** Present Agent Baseline as an outcome/control/evidence framework, then map Discover, Constrain, Authorize, Observe, Validate, and Respond to CF platform primitives and agent-specific gaps. + +**Tech Stack:** Markdown, YAML frontmatter, Devbox, Git, GitHub CLI. + +--- + +### Task 1: Write `research/agent-baseline.md` + +- [ ] Add frontmatter with title `Agent Baseline: Six Security Outcomes for Enterprise AI Agents`, author `Ruben Koster (@rkoster)`, date `2026-09-18`, tags `[authorization, sandboxing, observability-governance, ecosystem-survey]`, `cf_areas: [uaa, capi, diego, loggregator]`, `status: draft`, provisional ratings, and Agent Baseline website/source/white-paper links. +- [ ] Explain the threat model: runtime-programmable agents with access to data, tools, and systems, where mistaken or malicious instructions can cause actions before human intervention. +- [ ] Describe all six outcomes and the evidence-oriented nature of the 35 controls. +- [ ] Map Discover and Constrain to CF inventory, lifecycle, isolation, networking, and credential capabilities. +- [ ] Map Authorize and Observe to UAA/workload identity, policy, action attribution, Loggregator, and audit/provenance. +- [ ] Map Validate and Respond to build/release admission, evaluation, drift checks, revocation, quarantine, evidence preservation, and incident response. +- [ ] State that Agent Baseline is a working draft for public comment, not a finalized standard, and add open questions about control ownership, evidence, tenancy, and platform gaps. + +### 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 Agent Baseline research note`, push `research/agent-baseline`, and open a checklist-complete PR targeting `main`. +- [ ] Verify PR metadata and CI with `gh pr view`. diff --git a/research/agent-baseline.md b/research/agent-baseline.md new file mode 100644 index 0000000..7a0bced --- /dev/null +++ b/research/agent-baseline.md @@ -0,0 +1,106 @@ +--- +title: "Agent Baseline: Six Security Outcomes for Enterprise AI Agents" +author: Ruben Koster (@rkoster) +date: 2026-09-18 +tags: [authorization, sandboxing, observability-governance, ecosystem-survey] +cf_areas: [uaa, capi, diego, loggregator] +status: draft +ratings: + platform-impact: + value: 89 + note: "The baseline turns broad agent security concerns into discoverable outcomes, controls, and evidence that a platform could operationalize." + maturity: + value: 48 + note: "Agent Baseline is explicitly a working draft open for public comment rather than a finalized standard." + novelty: + value: 68 + note: "The six-outcome structure connects identity, runtime constraints, authorization, evidence, validation, and response into one agent-specific framework." + actionability: + value: 86 + note: "The controls provide a practical checklist for mapping existing CF primitives to missing agent-specific security capabilities." +sources: + - https://agentbaseline.org/ + - https://agentbaseline.org/controls + - https://agentbaseline.org/whitepaper.pdf + - https://github.com/agentbaseline/agentbaseline +--- + +## Summary + +Agent Baseline is an open-source draft framework describing six security outcomes an enterprise +must achieve to run AI agents: Discover, Constrain, Authorize, Observe, Validate, and Respond. +It contains 35 controls that state required capabilities and evidence rather than prescribing a +single product architecture. For Cloud Foundry, the baseline is a useful assessment lens for +identifying which platform primitives already exist and which agent-specific inventory, policy, +provenance, evaluation, and response capabilities remain to be built. + +## Key findings + +- **The framework starts from a distinct agent threat model.** Agents are runtime-programmable + through natural-language instructions, can access real data and tools, and may act with + limited human supervision. Existing application and infrastructure security remains necessary + but does not fully answer what an agent is allowed to do or how its actions are evidenced. +- **Discover establishes inventory and accountability.** The baseline requires an accurate view + of agents and dependencies, including components, owners, operating status, and effective + access. A platform cannot constrain or respond to an agent it cannot identify or inventory. +- **Constrain limits the execution surface.** Controls address the agent's components, runtime, + data, capabilities, environments, and network reach. This aligns with sandboxing, service + bindings, egress policy, and least-privilege runtime configuration. +- **Authorize binds action to context.** Authorization is not just a user or workload identity; + it connects identity, task, target, authority, resource, action, and time. This supports + scoped agent delegation and limits authority by purpose rather than granting a broad token. +- **Observe requires correlated evidence.** The baseline asks operators to connect intent, + identity, task, policy, tool use, action, and outcome. Plain process logs are insufficient when + an agent chains model calls, tools, subagents, and external effects. +- **Validate governs admission and change.** Agents and their components should be evaluated + before use, after material changes, and at intervals appropriate to risk. This includes + implementation, configuration, tool, model, and runtime changes rather than only a one-time + application deployment check. +- **Respond makes stopping and evidence preservation explicit.** The framework includes stop, + revoke, quarantine, scope-impact, evidence-preservation, and determination-of-impact + capabilities. Response is a runtime control, not only an incident-management document. +- **The controls are evidence-oriented.** Agent Baseline describes what an enterprise must be + able to demonstrate, allowing different implementations to satisfy the same outcome. This + makes it suitable for platform capability mapping and assurance discussions, but leaves + evidence formats and ownership to adopters. +- **The status is intentionally provisional.** The website describes the baseline as a working + draft for community review and invites implementation feedback. It should be treated as a + structured proposal, not a finalized compliance standard. + +## CF relevance + +Cloud Foundry already provides pieces of the baseline. CAPI can inventory applications and +owners; Diego manages process lifecycle and desired state; UAA and instance identity provide +identity primitives; networking and service bindings constrain access; and Loggregator provides +operational event streams. Those primitives can support parts of Discover, Constrain, +Authorize, and Observe, but they do not automatically describe agent intent, tool authority, +model/component provenance, or delegated task scope. + +The baseline suggests an agent security layer above ordinary CF applications. That layer could +register agent components and effective access, issue task- and resource-scoped authority, +enforce sandbox and egress policy, correlate model/tool/action events, and trigger revocation or +quarantine. CAPI and Diego events could feed inventory and response workflows, while UAA or a +delegation broker could supply identity. Loggregator would need correlation conventions for agent, +task, tool, policy, and outcome identifiers. + +Validate and Respond are the clearest gaps. CF buildpacks and deployment pipelines can validate +artifacts, but agent-specific evaluation, prompt/tool policy, model changes, runtime drift, +kill/revoke/quarantine, and evidence preservation require additional services or conventions. +The baseline is therefore useful less as a product to install than as a checklist for deciding +which capabilities belong in the CF platform, a brokered agent service, or application teams. + +## Open questions + +- Which Agent Baseline controls can CF satisfy with existing CAPI, Diego, UAA, networking, + service bindings, and Loggregator, and which require new platform services? +- What is the authoritative inventory of agent versions, models, prompts, tools, permissions, + owners, and effective access across orgs and spaces? +- How should task-scoped authority and delegated agent identity be represented and revoked? +- Which evidence should be retained for an agent action, and how should it correlate intent, + policy, tool calls, resources, outcomes, and human approvals without storing sensitive content? +- Where should agent evaluation and revalidation run: build pipelines, admission controllers, + runtime gateways, or an external assurance service? +- What is the minimum response path for stopping a running agent, removing authority, + quarantining its workspace, preserving evidence, and determining impact? +- Should CF adopt the baseline as guidance, map it into platform service-level objectives, or use + it to evaluate independently deployed agent platforms? From 2538a6abcc9e4b508a3719778fd229c6f4c940f7 Mon Sep 17 00:00:00 2001 From: rkoster Date: Sat, 19 Sep 2026 16:27:29 +0200 Subject: [PATCH 3/3] docs: update generated research map --- generated/research-map.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/generated/research-map.html b/generated/research-map.html index bbe5f21..3a3531c 100644 --- a/generated/research-map.html +++ b/generated/research-map.html @@ -23,9 +23,9 @@

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

-
Gap, experiments, and evidence
Current CF gap
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.

Core

Supporting

ResearchIdea

Platform Impact x Maturity

Emerging < Maturity > EstablishedLocal concern < Platform Impact > Platform-wide concern
Unplaced notes (0)
  • All notes are placed.
+
Gap, experiments, and evidence
Current CF gap
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.

Core

Supporting

ResearchIdea

Platform Impact x Maturity

Emerging < Maturity > EstablishedLocal concern < Platform Impact > Platform-wide concern
Unplaced notes (0)
  • All notes are placed.
 -