# Evidence memo: generic governance toolkits and reusable controls for agent and non-agent workloads

**Evidence date:** September 15, 2026  
**Audience:** CAF-v2 build/adopt decision makers  
**Scope:** Reusable foundations for policy, identity, authorization, supply-chain integrity, secrets, isolation, telemetry, compliance, provenance, and human approval. These products are not evaluated as “AI safety” systems; they are evaluated as controls that can govern an agent, ordinary service, CI job, or human-operated workflow.

## Executive finding

There is no single general-purpose, open governance toolkit that supplies identity, policy administration and decisions, enforcement, isolated execution, evidence, compliance mapping, and human approval. The practical build/adopt path is a **composable control plane** built from mature generic components, with a thin CAF-specific layer that carries agent/task context and binds those components together.

A credible default stack is:

1. **Human identity:** an existing enterprise identity provider, or self-hosted Keycloak.
2. **Workload identity:** SPIFFE identities issued by SPIRE; exchange or federate them into cloud IAM.
3. **Decision services:** OPA for arbitrary contextual rules, plus OpenFGA or SpiceDB only when relationship-based permissions are a first-class requirement.
4. **Enforcement:** wrappers at the tool/API boundary and Kubernetes admission; Kyverno is the simpler Kubernetes-native choice, while Gatekeeper reuses Rego/OPA.
5. **Artifact trust:** SLSA and in-toto attestations signed and verified with Sigstore; verify at deployment and before loading agent tools, models, plugins, or images.
6. **Secrets:** OpenBao or Infisical as a self-hostable control plane, or a cloud secret manager; External Secrets Operator is only a delivery bridge.
7. **Execution isolation:** gVisor for compatibility and density, Kata Containers or Firecracker when a VM boundary is warranted. Add Tetragon for kernel-level enforcement or Falco for detection.
8. **Evidence:** OpenTelemetry as the vendor-neutral transport, a security event store/SIEM for retention and investigation, OpenLineage for run/data lineage, and GUAC or Grafeas for artifact metadata.
9. **Compliance:** OSCAL as the exchange model, Compliance Trestle for compliance-as-code, and a commercial GRC system when business workflow, control ownership, and auditor collaboration matter.
10. **Approvals:** Temporal for durable code-defined orchestration or Flowable for BPMN/CMMN/DMN and human-task semantics. GitHub environment approvals are useful but narrowly scoped to deployment jobs.

The architecture should preserve one correlation envelope across all layers: **human principal, workload identity, delegated task, policy/version, requested action, resource, decision, approval, artifact digest, runtime, and resulting evidence**. Generic components can carry these fields, but CAF must define and enforce the cross-component contract.

## What counts as a toolkit

This memo uses three labels:

- **Toolkit / platform:** A deployable control plane or coherent suite with multiple lifecycle functions, administration, APIs/integrations, and operational state. Examples: SPIRE, Sigstore, OpenBao, Wazuh, DataHub, Flowable. A toolkit still covers only one governance domain.
- **Engine:** A reusable decision or execution kernel that deliberately relies on external policy administration, enforcement points, identity, workflow, or evidence storage. Examples: OPA, Cedar, OpenFGA, gVisor, Temporal.
- **Partial component / standard:** One necessary building block—language, specification, admission controller, collector, delivery bridge, scanner, graph, or runtime. Examples: SLSA, External Secrets Operator, OpenTelemetry, OpenLineage. Calling these “governance platforms” would overstate their scope.

A product earns the toolkit label here because of deployable breadth within its domain, not because it can govern an agent end to end. **None of the entries below is a complete agent governance stack.**

## Comparison matrix

Licenses below describe the referenced open-source repository or specification, not a vendor’s enterprise add-ons or hosted service. “Self-hosted” means the cited code can be operated by the adopter. GitHub stars are included only as a directional ecosystem signal and were observed on September 15, 2026; they are not a security or fitness score.

### 1. Policy engines, authorization, and identity

| Foundation | Type | Evidence and posture | What it contributes | What remains for an agent governance stack |
|---|---|---|---|---|
| [Open Policy Agent (OPA)](https://www.openpolicyagent.org/docs/latest/) ([repo](https://github.com/open-policy-agent/opa)) | Engine | General-purpose policy engine; Apache-2.0; self-hosted/embedded; CNCF graduated; ~12.2k stars | Domain-neutral Rego decisions over structured input; usable in services, gateways, CI/CD, and Kubernetes | No built-in identity issuance, durable approval, execution sandbox, or authoritative evidence store. CAF must supply policy distribution/versioning and enforcement points; [Styra](https://styra.com/enterprise-opa-platform) is a commercial management option. |
| [Cedar](https://docs.cedarpolicy.com/) ([repo](https://github.com/cedar-policy/cedar)) | Engine/language | Authorization language and evaluator; Apache-2.0; self-hosted/embedded; ~1.7k stars | Typed, schema-aware authorization policies with analysis tooling | Narrower than OPA: authorization, not generic compliance or runtime policy. Policy store, administration, enforcement, identity, and audit are separate. [Amazon Verified Permissions](https://aws.amazon.com/verified-permissions/) is the managed Cedar service. |
| [OpenFGA](https://openfga.dev/) ([repo](https://github.com/openfga/openfga)) | Authorization engine | Zanzibar-style fine-grained authorization; Apache-2.0; self-hosted; CNCF incubating; ~5.8k stars | Relationship-based access control (ReBAC), centralized tuples/models, low-latency permission checks | Does not authenticate principals or enforce decisions. Agent delegation, purpose, risk, and budget often need contextual policy in OPA/Cedar in addition to graph relationships. |
| [SpiceDB](https://authzed.com/docs/spicedb/getting-started/discovering-spicedb) ([repo](https://github.com/authzed/spicedb)) | Authorization engine/database | Zanzibar-inspired permissions database; Apache-2.0; self-hosted; ~7.1k stars; [Authzed Serverless/Dedicated](https://authzed.com/products/spicedb-serverless) available | Mature relationship graph and consistency semantics for resource permissions | Same boundary as OpenFGA: no authentication, generic risk policy, approval, or enforcement. Choose one ReBAC engine, not both. |
| [Cerbos](https://www.cerbos.dev/) ([repo](https://github.com/cerbos/cerbos)) | Toolkit, open core | Apache-2.0 policy decision point; self-hosted; ~4.6k stars. Commercial Cerbos Hub adds centralized administration and managed components | Application-focused RBAC/ABAC policy, local decision points, SDKs, testing, and a commercial policy administration plane | Still requires identity, enforcement adapters, workload attestation, approval, and evidence retention. Open-core boundaries must be assessed against required administration features. |
| [Keycloak](https://www.keycloak.org/) ([repo](https://github.com/keycloak/keycloak)) | Identity toolkit | IAM server; Apache-2.0; self-hosted; ~36.8k stars | Human/service authentication, OIDC/OAuth 2.0/SAML, federation, sessions, and fine-grained authorization services | It is not workload attestation, a general policy engine, or an execution sandbox. Avoid treating an agent process as a human user merely because OAuth tokens are available. |
| [SPIFFE specifications](https://spiffe.io/docs/latest/spiffe-about/overview/) + [SPIRE](https://github.com/spiffe/spire) | Standard + workload-identity toolkit | SPIFFE defines open workload-identity standards; SPIRE is Apache-2.0, self-hosted, CNCF graduated; ~2.5k stars | Attestation-based issuance of short-lived X.509/JWT SVIDs, workload API, federation, Kubernetes/VM/bare-metal support | Identifies a workload, not its human delegator, current task, or permissions. Bind the SVID to task/delegation claims and pass both to the authorization layer. |
| [Cloud workload federation: Google WIF](https://docs.cloud.google.com/iam/docs/workload-identity-federation) / [AWS IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/workload-identities.html) | Managed partial components | Proprietary managed cloud services; AWS maps X.509 workload certificates to temporary credentials; Google federates external workload identities | Removes static cloud keys and turns an attested external workload into short-lived cloud credentials | Cloud-specific and not a cross-environment governance plane. Preserve the originating workload and user/task context in logs and session tags/attributes. |

**Selection guidance.** Use OPA when the policy inputs or outputs are not limited to authorization. Use Cedar when schema-aware application authorization and AWS alignment dominate. Add OpenFGA or SpiceDB only for high-cardinality relationship permissions; they complement rather than replace contextual policy. SPIRE answers “which workload is this?”; none of these tools alone answers “who delegated this task, for what purpose, under which approval?”

### 2. Software supply chain and admission

| Foundation | Type | Evidence and posture | What it contributes | What remains |
|---|---|---|---|---|
| [Sigstore](https://docs.sigstore.dev/about/overview/)—[Cosign](https://github.com/sigstore/cosign), Fulcio, [Rekor](https://github.com/sigstore/rekor) | Toolkit | Open-source signing/transparency suite; Cosign and Rekor Apache-2.0; self-hostable; public-good service also operated; Cosign ~6.3k stars | Identity-bound signing, verification, short-lived certificates, transparency records, artifact/SBOM attestations | A signature establishes identity/integrity, not acceptability. Admission policy must state which identities, builders, predicates, and artifact digests are trusted. Private deployments must operate trust roots and logs. |
| [SLSA v1.2](https://slsa.dev/spec/v1.2/) ([license](https://github.com/slsa-framework/slsa/blob/main/LICENSE.md)) | Standard | Supply-chain security and provenance specification; Community Specification License 1.0; not source-code tooling | Common provenance vocabulary and incremental build-security requirements | Does not generate, sign, store, or enforce provenance. Pair with in-toto/Sigstore, CI builders, and admission policy. |
| [in-toto](https://in-toto.io/) ([repo/license](https://github.com/in-toto/in-toto/blob/develop/LICENSE)) | Framework/standard | Supply-chain layout and attestation framework; Apache-2.0 implementation; self-hosted; CNCF graduated; ~1.0k stars | Defines and verifies expected supply-chain steps and signed link metadata; underpins common attestations | Requires integration into build steps, identities/keys, an attestation store, and admission decisions. |
| [Kyverno](https://kyverno.io/docs/introduction/how-kyverno-works/) ([repo](https://github.com/kyverno/kyverno)) | Kubernetes policy toolkit | Kubernetes-native validation, mutation, generation, cleanup, image verification, and reporting; Apache-2.0; self-hosted; CNCF; ~8.1k stars | Broad admission/background policy using Kubernetes-style YAML; can verify images and attestations | Kubernetes-only. It cannot govern direct API/tool calls outside the cluster unless equivalent enforcement is added elsewhere. |
| [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) | Admission component | Kubernetes policy controller with audit and external data; Apache-2.0; self-hosted; ~4.3k stars | Reuses OPA/Rego for admission and audits existing resources | Kubernetes-specific enforcement point, not an OPA management plane or supply-chain system. Image verification and mutation are less integrated than in Kyverno. |
| [Google Binary Authorization](https://cloud.google.com/binary-authorization/docs/overview) | Managed admission service | Proprietary Google Cloud service; deploy-time enforcement and continuous validation for container-image policy | Managed attestation-based admission with Cloud Logging integration | Cloud/platform scope and vendor coupling. It does not cover arbitrary agent tools, packages, prompts, models, or non-Google runtimes without additional gates. |
| [Chainguard policy catalog](https://github.com/chainguard-dev/policy-catalog) / [Enforce](https://chainguard.dev/unchained/chainguard-enforce-is-now-generally-available) | OSS policy content + commercial platform | Reusable policies for Sigstore policy-controller are open; Enforce is commercial | Faster adoption of signed-image/SBOM/vulnerability admission rules and managed policy decisions | Policy content and platform are distinct. Validate catalog assumptions against local risk appetite and preserve attestation evidence outside the vendor UI. |

**Agent composition.** Treat an agent’s container, tool server, plugin, policy bundle, model package, and prompt/config bundle as versioned artifacts. Produce in-toto/SLSA provenance, sign the digest with Sigstore, store the attestation, and require it at admission and again at dynamic tool loading. Kubernetes admission alone cannot see a tool downloaded after a pod starts.

### 3. Secrets and privileged credentials

| Foundation | Type | Evidence and posture | Contribution | What remains |
|---|---|---|---|---|
| [OpenBao](https://openbao.org/) ([repo](https://github.com/openbao/openbao)) | Secrets toolkit | Linux Foundation/OpenSSF community fork; MPL-2.0; self-hosted; ~7.4k stars | Central secret storage, dynamic credentials, PKI, encryption, leases, and revocation | Requires secure bootstrap, HA, unseal/key operations, policy design, and identity integration. Secret access is not business approval; policy must bind task identity and purpose. |
| [Infisical](https://infisical.com/) ([repo/license](https://github.com/Infisical/infisical/blob/main/LICENSE)) | Secrets/PAM toolkit, open core | Core platform MIT and self-hostable; Infisical Cloud is managed in US/EU; commercial features/products also exist | Secrets, certificates, machine identities, privileged access, developer-facing integrations | Verify which required controls are in the MIT core versus paid editions. Still needs workload attestation and least-privilege delivery. |
| [HashiCorp Vault](https://developer.hashicorp.com/vault) ([license terms](https://www.hashicorp.com/en/bsl)) | Source-available toolkit + commercial platform | Current releases use BSL 1.1, which is source-available, not OSI open source; self-managed Community/Enterprise and managed HCP options | Mature secret engines, dynamic credentials, PKI, transit encryption, broad integrations | BSL restricts competitive hosted/embedded offerings and changes to MPL 2.0 four years after publication. Legal review is required for product embedding; OpenBao is the clean open-source alternative. |
| [External Secrets Operator](https://external-secrets.io/) ([repo](https://github.com/external-secrets/external-secrets)) | Partial delivery component | Apache-2.0 Kubernetes operator; self-hosted; ~6.9k stars | Synchronizes values from external secret stores into Kubernetes Secrets | It is not a vault. Materializing secrets into Kubernetes changes the exposure and rotation model; use workload-native retrieval/CSI where exfiltration risk is high. |
| [SOPS](https://github.com/getsops/sops) | Partial file-encryption component | MPL-2.0; client-side; ~23.1k stars | Encrypts selected values in YAML/JSON/ENV files using KMS/PGP/age; useful for GitOps | No dynamic issuance, lease, revocation, runtime access policy, or central audit by itself. |
| [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/features/) and cloud equivalents | Managed secrets service | Proprietary managed service; rotation, IAM, KMS, and cloud audit integration | Low-operations default for cloud-local workloads | Cloud coupling and per-provider policy/evidence silos. Use federation and a common audit envelope to avoid static keys and fragmented attribution. |

### 4. Sandbox and runtime controls

| Foundation | Type | Evidence and posture | Contribution | What remains |
|---|---|---|---|---|
| [gVisor](https://gvisor.dev/docs/) ([repo](https://github.com/google/gvisor)) | Sandbox runtime | Userspace application kernel; Apache-2.0; self-hosted; ~19.3k stars | Stronger container isolation by intercepting/reimplementing the Linux system-call interface; integrates with container tooling | Compatibility/performance testing and resource/network policy are still required. It does not decide whether a requested action is authorized. |
| [Kata Containers](https://katacontainers.io/learn/) ([repo](https://github.com/kata-containers/kata-containers)) | Sandbox runtime toolkit | Lightweight VMs with container UX; Apache-2.0; self-hosted; OpenInfra; ~8.7k stars | Hardware-virtualized workload boundary with container orchestration integration | Higher startup/resource cost than ordinary containers; host, image, network, device, and control-plane security remain. |
| [Firecracker](https://firecracker-microvm.github.io/) ([repo](https://github.com/firecracker-microvm/firecracker)) | Partial runtime/VMM | Minimal microVM VMM; Apache-2.0; self-hosted; ~36.8k stars | Strong, fast VM primitive used for serverless isolation | Not a turnkey multi-tenant sandbox platform: the adopter must build image lifecycle, networking, scheduling, quotas, snapshot hygiene, and guest/host telemetry. |
| [Falco](https://falco.org/docs/) ([repo/license](https://github.com/falcosecurity/falco)) | Runtime detection toolkit | Cloud-native runtime security; Apache-2.0; self-hosted; CNCF graduated; ~9.4k stars | Detects suspicious kernel/application behavior with rules and plugins; sends alerts to downstream systems | Primarily detection/response, not preventative sandboxing or business authorization. Alerts require triage, retention, and response workflow. |
| [Tetragon](https://tetragon.io/docs/overview/) ([repo/license](https://github.com/cilium/tetragon)) | Runtime enforcement/observability component | eBPF-based; Apache-2.0; self-hosted; ~5.0k stars | Kernel-level process/network visibility and runtime enforcement close to the workload | Linux/kernel scope, operational privilege, and policy complexity. It cannot infer task intent; decisions need identity/task context from the upper control plane. |

**Selection guidance.** Isolation and authorization are independent. A denied tool call should never reach the sandbox; an allowed call should still execute inside a constrained runtime. Use process/container controls for routine jobs, gVisor where compatibility permits, and a VM boundary for untrusted code or high-impact credentials. Add network egress policy, read-only/minimal filesystems, resource/time quotas, syscall/device limits, and per-task teardown regardless of runtime.

### 5. Audit, telemetry, GRC, lineage, provenance, and approval

| Foundation | Type | Evidence and posture | Contribution | What remains |
|---|---|---|---|---|
| [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/) / [Collector](https://github.com/open-telemetry/opentelemetry-collector) | Telemetry standard + component | Vendor-neutral traces, metrics, and logs; Collector Apache-2.0; self-hosted; CNCF; ~7.6k stars | Common instrumentation, context propagation, processing, and export; avoids binding governance evidence to one backend | Not an immutable audit log, SIEM, retention policy, or compliance model. Define stable governance attributes and export to controlled storage. |
| [osquery](https://www.osquery.io/) ([repo/license](https://github.com/osquery/osquery/blob/master/LICENSE)) | Host instrumentation component | SQL-based host telemetry; Apache-2.0 OR GPL-2.0-only; self-hosted; ~23.6k stars | Inventory and scheduled queries over OS state for investigation and posture evidence | Collection/query layer only; requires fleet management, analytics, alerting, and retention. |
| [Wazuh](https://wazuh.com/) ([repo/license](https://github.com/wazuh/wazuh/blob/main/LICENSE)) | Security monitoring toolkit | Endpoint agent + manager + search/visualization; GPLv2 with stated OpenSSL exception; self-hosted and [Wazuh Cloud](https://wazuh.com/cloud/); ~16.9k stars | Log analysis, file integrity, vulnerability/configuration assessment, incident response, and compliance dashboards | Broad SIEM/XDR does not automatically produce semantically complete agent audit events; CAF still needs event schemas and end-to-end correlation. |
| [Datadog Audit Trail](https://docs.datadoghq.com/account_management/audit_trail/) / [Splunk audit and SIEM](https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.0/audit-activity-in-splunk-enterprise/auditing-activities-in-a-splunk-platform-instance) | Commercial telemetry/evidence backends | Proprietary hosted or licensed platforms | Enterprise retention, search, dashboards, alerting, and integrations; Datadog documents attribution of some agent-driven events to agent and authorizing user | They observe what is instrumented. Keep an open event contract (for example, OTel) and ensure administrator actions, decision logs, approvals, and evidence-store access are also audited. |
| [OSCAL](https://pages.nist.gov/OSCAL/) ([repo/license](https://github.com/usnistgov/OSCAL/blob/main/LICENSE.md)) | GRC standard | NIST machine-readable XML/JSON/YAML models; worldwide public-domain dedication/CC0; ~1.0k stars | Portable catalogs, profiles, component definitions, system security plans, assessments, and results | A data model, not a control monitor, workflow, or evidence collector. Mapping a control does not prove operating effectiveness. |
| [Compliance Trestle](https://oscal-compass.dev/compliance-trestle/latest/) ([repo](https://github.com/oscal-compass/compliance-trestle)) | Compliance-as-code toolkit | OSCAL authoring/transformation/governance in Git/CI; Apache-2.0; self-hosted; ~0.3k stars | Human-friendly OSCAL management, schema validation, document transformation, and Git review | Passes artifacts to separate enforcement, measurement, and reporting tools; not an enterprise GRC workflow suite. |
| [OpenSCAP](https://www.open-scap.org/tools/openscap-base/) ([repo](https://github.com/OpenSCAP/openscap)) | Compliance scanner/toolkit | SCAP parser/evaluator and scanner; LGPL-2.1; self-hosted; NIST-certified SCAP 1.2 toolkit; ~1.8k stars | Evaluates XCCDF/OVAL content and configuration baselines such as STIGs | Strong for host/configuration checks, not business governance, agent behavior, or cloud/API evidence. |
| [ServiceNow GRC/IRM](https://www.servicenow.com/products/governance-risk-and-compliance.html) | Commercial GRC platform | Proprietary SaaS/platform | Control ownership, risk register, issues/remediation, attestations, workflows, reporting, and enterprise system-of-record integration | Expensive and implementation-heavy; not a low-latency policy/enforcement layer. Feed it normalized evidence rather than putting it in the synchronous action path. |
| [OpenLineage](https://openlineage.io/docs/) + [Marquez](https://github.com/MarquezProject/marquez) | Standard + reference toolkit | OpenLineage and Marquez Apache-2.0; self-hosted; ~2.7k/~2.3k stars | Extensible job/run/dataset lineage events; Marquez collects, aggregates, and visualizes them | Data-processing orientation. Agent tool calls, prompts, approvals, and derived artifacts require custom facets/events and stronger integrity/retention controls. |
| [DataHub](https://docs.datahub.com/docs/introduction) ([repo](https://github.com/datahub-project/datahub)) | Metadata/governance toolkit, open core | Core Apache-2.0; self-hosted; ~12.7k stars; [DataHub Cloud](https://docs.datahub.com/docs/managed-datahub/welcome-acryl) available | Catalog, metadata graph, lineage, discovery, ownership, domains, assertions, and governance workflows | Primarily data/AI asset governance, not action authorization or runtime isolation. Verify open-core versus cloud feature boundaries. |
| [Grafeas](https://github.com/grafeas/grafeas) | Artifact metadata component/API | Apache-2.0; self-hosted reference server; ~1.6k stars | Uniform API and store for artifact metadata used by build, audit, compliance, and policy tools | Metadata system, not attestation trust, policy evaluation, or complete product. Project activity and production fit should be validated for the target scale. |
| [GUAC](https://github.com/guacsec/guac) | Supply-chain knowledge-graph component | Apache-2.0; OpenSSF incubating; active development; self-hosted; ~1.5k stars | Normalizes SBOM, vulnerability, identity, and attestation data into a queryable graph for audit/policy/risk | Explicitly active development; no native human approval or general data lineage. Treat as evidence/analysis, not sole enforcement. |
| [Temporal](https://docs.temporal.io/) ([repo](https://github.com/temporalio/temporal)) | Durable workflow engine | Server MIT; self-hosted; Temporal Cloud available; ~23.1k stars | Durable state, retries, timers, signals, and code-defined long-running workflows; official [human-in-the-loop approval guidance](https://temporal.io/blog/human-in-the-loop-approvals) | Approval UX, identity proofing, separation of duties, policy, and evidence schema are application responsibilities. Workflow history is useful evidence but not automatically an immutable compliance archive. |
| [Flowable](https://www.flowable.com/open-source) ([repo](https://github.com/flowable/flowable-engine)) | Workflow/BPM toolkit | BPMN, CMMN, and DMN engines Apache-2.0; self-hosted; ~9.5k stars; commercial platform adds low-code/UI/operations | Standards-based processes, cases, decisions, and human tasks suit explicit approvals and exceptions | Open-source engine versus enterprise platform boundaries matter. Tool/API enforcement and runtime isolation remain external. |
| [Argo Workflows](https://argoproj.github.io/workflows/) ([repo](https://github.com/argoproj/argo-workflows)) | Kubernetes workflow engine | Container-native DAG/steps; Apache-2.0; self-hosted; CNCF; ~17.0k stars | Reproducible Kubernetes jobs, artifact passing, and CI/ML/data orchestration | Not a business approval system; human tasks, identity/separation-of-duty controls, and non-Kubernetes workflows need extra services. |
| [GitHub Actions environments](https://docs.github.com/en/actions/reference/deployments-and-environments) | Managed approval component | Proprietary GitHub service feature; availability varies by plan/repository visibility | Required reviewers, self-review prevention option, environment secrets, wait/protection rules | Narrowly gates GitHub workflow jobs. It is not a generic runtime approval service and should not become the only record for non-deployment actions. |
| [Collibra Data Lineage](https://productresources.collibra.com/docs/collibra/2026.02/Content/CollibraDataLineage/co_collibra-data-lineage.htm) | Commercial lineage/governance platform | Proprietary, cloud-only lineage product; documents OpenLineage support | Managed technical/business lineage, visualization, stewardship, and broader enterprise data governance | Commercial data-governance scope; agent actions and enforcement still require custom event mapping and separate policy/runtime controls. |

## How the pieces compose

### Request path

1. A human authenticates through the enterprise IdP/Keycloak. The orchestrator records the user, organization, task, purpose, and delegation limits.
2. The agent runtime is attested and receives a short-lived SPIFFE SVID from SPIRE. Cloud federation exchanges it for temporary provider credentials where needed.
3. Before execution, the admission layer verifies the image/tool/model/config digest and its Sigstore/in-toto/SLSA attestations. Kyverno, Gatekeeper, or a cloud admission service enforces the deployment rule.
4. Every consequential tool/API call enters a CAF enforcement point. It combines human delegation, workload SVID, task state, resource, data classification, approval state, and current risk signals.
5. OPA/Cedar decides contextual policy. OpenFGA/SpiceDB supplies relationship permissions if needed. The enforcement point—not the agent—honors deny/allow/obligations.
6. High-risk or irreversible actions create a durable approval task in Temporal/Flowable. On approval, the workflow issues a narrowly scoped, expiring capability rather than a reusable “approved=true” flag.
7. The action executes in gVisor/Kata/Firecracker with network, filesystem, syscall/device, CPU/memory/time, and secret-delivery controls. Tetragon can enforce kernel policy; Falco detects suspicious behavior.
8. The system emits OTel events carrying the common correlation envelope. Security events flow to Wazuh/Splunk/Datadog; data/run lineage flows to OpenLineage/DataHub; artifact evidence flows to GUAC/Grafeas/Rekor.
9. Compliance automation maps technical evidence to OSCAL components/controls through Trestle. A GRC platform owns risks, exceptions, attestations, control owners, and auditor workflow.

### Control-plane boundaries

- **Policy decision is not enforcement.** OPA, Cedar, OpenFGA, and SpiceDB return answers; an API gateway, tool wrapper, admission webhook, secrets broker, or runtime must make the answer unavoidable.
- **Authentication is not delegation.** A valid user token and a valid workload SVID do not prove that this workload may perform this action for this user now.
- **Signing is not approval.** Sigstore proves provenance/integrity facts. Policy decides whether those facts satisfy local requirements.
- **Telemetry is not audit by default.** OTel carries data but does not make it complete, immutable, access-controlled, retained, or legally sufficient.
- **Workflow history is not authorization.** A durable approval must be bound cryptographically or transactionally to the exact action, parameters, digest, expiry, and approver constraints checked at execution.
- **Isolation is not least privilege.** A sandbox can contain compromise while still allowing harmful network/API actions if credentials and egress are broad.
- **Compliance representation is not compliance.** OSCAL/Trestle can structure controls and evidence; control owners and assessors still determine design and operating effectiveness.

## Build/adopt recommendations for CAF-v2

### Adopt rather than rebuild

- OIDC/OAuth/SAML identity; SPIFFE/SPIRE workload identity.
- OPA/Cedar or a Zanzibar-style authorization engine, selected by policy shape.
- Sigstore, in-toto, and SLSA-compatible attestations.
- A mature secrets manager and short-lived cloud federation.
- A proven sandbox/runtime and Kubernetes admission controller.
- OpenTelemetry transport plus an existing SIEM/observability backend.
- OSCAL as the compliance exchange format where NIST/FedRAMP-style evidence matters.
- Temporal/Flowable for durable approvals rather than custom polling/state machines.

### Build the thin integration layer

CAF-specific value lies in the seams that generic products do not standardize:

- a canonical **actor/delegation/task/action/resource/evidence** schema;
- enforcement adapters around agent tools, MCP/tool servers, APIs, shells, file systems, model endpoints, and deployment paths;
- policy obligations such as redact, require approval, constrain parameters, lower a budget, force a sandbox, or attach retention;
- one decision-and-evidence ID propagated through OTel, workflow, authorization, secrets, runtime, lineage, and GRC records;
- approval capabilities bound to exact action parameters and artifact digests;
- evidence integrity, retention, access policy, legal hold, replay, and export;
- lifecycle controls for agent/tool/model registration, versioning, suspension, and revocation.

### Avoid

- Building a new policy language, secrets vault, identity provider, workflow engine, tracing protocol, or VM/container sandbox.
- Selecting a product because it markets “AI governance” when its enforcement surface, identity model, or evidence contract is unclear.
- Treating Kubernetes admission as coverage for runtime-downloaded tools or external SaaS/API actions.
- Treating one SIEM dashboard as proof of complete attribution.
- Combining two general policy engines or two ReBAC stores without a concrete requirement; duplicated sources of truth create inconsistent decisions.

## Decision shortlist

| Need | Low-operations / managed bias | Open, portable / self-hosted bias | Decision trigger |
|---|---|---|---|
| Contextual policy | AWS Verified Permissions when Cedar/AWS fit; Styra for managed OPA | OPA; Cedar embedded where authorization-only | Choose by policy shape, analysis needs, and management-plane requirements. |
| Relationship authorization | Authzed Serverless/Dedicated | SpiceDB or OpenFGA | Only when permissions are naturally a changing relationship graph. |
| Workload identity | Cloud WIF/Roles Anywhere | SPIRE, federated to cloud IAM | SPIRE for multi-environment identity; native federation for cloud-local scope. |
| Admission/supply chain | Google Binary Authorization; Chainguard Enforce | Sigstore + SLSA/in-toto + Kyverno/Gatekeeper | Kyverno for integrated Kubernetes policy/image verification; Gatekeeper for Rego reuse. |
| Secrets | Cloud secret manager, HCP Vault, Infisical Cloud | OpenBao or Infisical core | OpenBao for OSI-open Vault lineage; managed service when operations dominate. |
| Runtime isolation | Managed serverless/microVM service | gVisor, Kata, Firecracker | Increase boundary strength with code untrustworthiness and credential/data impact. |
| Audit/SIEM | Splunk, Datadog, Wazuh Cloud | OTel + Wazuh/osquery | Keep OTel contract regardless of backend. |
| GRC | ServiceNow IRM or existing enterprise GRC | OSCAL + Trestle + OpenSCAP | Commercial platform for owners/workflows/auditors; open stack for portable compliance-as-code. |
| Lineage/provenance | DataHub Cloud, Collibra | OpenLineage/Marquez + GUAC/Grafeas | Separate data/run lineage from software artifact provenance but share IDs. |
| Approval/orchestration | Temporal Cloud, Flowable commercial, existing ServiceNow | Temporal server, Flowable OSS, Argo for K8s jobs | Temporal for code-first durability; Flowable for modeled human/case workflows; Argo only for cluster jobs. |

## Evidence limits

- Product features, hosted-region claims, plan entitlements, and licenses can change. Re-check the exact version and commercial terms during procurement.
- GitHub stars are volatile and measure attention, not production maturity or security.
- “Open core” means the cited core repository is open source; enterprise administration, UI, policy distribution, or support may be proprietary.
- This is an architecture/component review, not a penetration test, legal license opinion, performance benchmark, or total-cost analysis.