# Agent Governance Toolkits: Industry Landscape, Microsoft AGT, and CAF v2 Strategy

**Research date:** September 15–16, 2026  
**Audience:** CAF v2 product and architecture decision makers  
**CAF baseline reviewed:** `/home/chunsun/workspace/scratch_workspace/CAF/V2-architecture/caf-v2-prfaq-draft.md`

## Outline

- [Executive conclusion](#executive-conclusion)
- [1. What agent governance contains](#1-what-agent-governance-contains)
- [2. AI-agent-specific products and toolkits](#2-ai-agent-specific-products-and-toolkits)
- [3. Generic governance toolkits and partial components](#3-generic-governance-toolkits-and-partial-components)
- [4. Policy languages and authoring models](#4-policy-languages-and-authoring-models)
- [5. Standards and governance frameworks](#5-standards-and-governance-frameworks)
- [6. Microsoft AGT: technical assessment and industry position](#6-microsoft-agt-technical-assessment-and-industry-position)
- [7. CAF v2: fit, build-versus-reuse, and AGT evaluation](#7-caf-v2-fit-build-versus-reuse-and-agt-evaluation)
- [8. Strategic recommendation](#8-strategic-recommendation)
- [9. Evaluation and procurement checklist](#9-evaluation-and-procurement-checklist)
- [10. Risks and unresolved decisions](#10-risks-and-unresolved-decisions)
- [11. Final decision](#11-final-decision)
- [Selected primary references](#selected-primary-references)

## Executive conclusion

**The agent-governance market has not converged on an industrial standard or a common end-to-end architecture.** Table 2.2 shows fragmentation across nearly every material dimension: agent identity and delegation, policy language, action enforcement, isolation, approval, evidence, compliance, incident response, and deployment model. No reviewed product provides a portable control plane across these layers, and no common policy model or evidence contract allows them to be exchanged without product-specific integration.

Standards and mature components exist, but mainly below or between products: OAuth/OIDC and SPIFFE address parts of identity; Rego, Cedar, and CEL express different classes of policy; MCP and A2A define communication protocols; AuthZEN defines a decision API; OpenTelemetry carries telemetry. None binds human mandate, agent delegation, per-action policy, execution, and audit evidence into one broadly adopted governance system. As a result, current platforms are complementary rather than interchangeable, and adopting one platform's schemas as an application contract creates material lock-in.

This lack of convergence is the report's most important strategic finding. CAF should expect the market to keep changing and preserve replaceability at the identity, policy, runtime, and evidence seams. It should define only the smallest stable CAF contract needed for managed HPC operations, then integrate standards and products behind that boundary.

Microsoft’s open-source [Agent Governance Toolkit (AGT)](https://github.com/microsoft/agent-governance-toolkit) is one of the broadest attempts to standardize governance inside agent applications. Its strongest capability is an embeddable runtime policy decision and enforcement layer: a trusted host invokes the Agent Control Specification (ACS) before lifecycle events such as model and tool calls, then enforces allow, deny, or transform decisions. AGT also provides useful agent identity, delegation, audit, MCP, reliability, and compliance primitives. It does **not** replace enterprise IAM, credential management, hard workload isolation, data governance, a SIEM, GRC, or host enforcement. It is a fast-moving public preview whose completeness depends on non-bypassable integration.

CAF should not become another general-purpose governance suite. CAF’s durable product role is narrower: the compatibility and evidence boundary between replaceable agent runtimes and managed HPC services. CAF should build its runtime-neutral contract, adapter SDK, admission/conformance suite, normalized HPC facades, and application-level evidence schema. It should reuse host-provided policy, identity, credentials, scheduling, isolation, telemetry, retention, and incident response.

AGT is relevant to CAF, but the right first move is a **bounded technical evaluation**, not wholesale adoption. CAF can test ACS as an optional policy-decision implementation behind its own vendor-neutral provider interface and reuse selected AGT concepts or modules. CAF should not adopt AGT’s identity, event, lifecycle, or framework abstractions as its public product contract until version stability, Pi integration coverage, offline/HPC operation, bypass behavior, and cross-language semantics are proven.

The strategic rule is:

> **Build the CAF semantic boundary; adopt mature mechanisms; pilot AGT behind replaceable interfaces.**

## 1. What “agent governance” contains

A complete governance system needs several distinct layers. Conflating them produces weak architecture and inflated vendor comparisons.

| Layer | Governing question | Typical mechanisms |
|---|---|---|
| Organizational governance | Who owns the agent, risk, exception, and control? | Inventory, accountability, risk assessment, GRC, certifications |
| Identity and delegation | Which user, workload, agent, or sub-agent is acting, and for whom? | OIDC/OAuth, workload identity, short-lived credentials, delegation chains |
| Policy decision | Is this exact action allowed in this context? | OPA/Rego, Cedar, relationship authorization, semantic policy |
| Enforcement | Can a denied action still occur through another path? | Tool/API gateway, wrapper, sidecar, credential broker, network/runtime boundary |
| Runtime safety | Is execution contained even after authorization? | Containers, gVisor, microVMs, filesystem/network/resource controls |
| Model and content safety | Is the input/output malicious, sensitive, or misaligned? | Prompt-injection defense, DLP, classifiers, guardrails, model policies |
| Evidence and observability | Can the organization reconstruct request, decision, execution, and result? | Structured events, traces, audit logs, lineage, attestations, SIEM |
| Human control | Which effects require review or approval? | Durable workflows, step-up authorization, separation of duties |
| Assurance and compliance | Do controls map to obligations and operate effectively? | NIST/ISO/EU mappings, evaluations, red-team tests, OSCAL, GRC |
| Incident response | Can operators suspend, revoke, contain, investigate, and recover? | Kill/revoke/quarantine, evidence preservation, SIEM/SOAR, rollback |

No reviewed product proves complete coverage across all layers. An architecture must therefore define its authoritative source and enforcement point for each layer.

## 2. AI-agent-specific products and toolkits

### 2.1 Market map

The market divides into five overlapping groups:

- **Cloud-native agent platforms:** AWS, Google Cloud, Microsoft, Salesforce.
- **Agent identity and authorization:** Microsoft Entra Agent ID, Ping, Descope, Okta, Oasis, Cerbos, Permit.
- **MCP and tool gateways:** Docker, Stacklok ToolHive, Lasso.
- **Runtime AI security:** Cisco, Palo Alto Networks, Check Point/Lakera, Holistic AI, Galileo, NVIDIA.
- **Lifecycle governance and evaluation:** IBM, Credo AI, LangSmith, Phoenix, AgentOps.

The most important market trend is that the tool/API boundary is becoming the practical policy enforcement point. The strongest designs evaluate policy before a tool call and place credentials or network access beyond the agent’s direct control. Runtime isolation remains less common than prompt and traffic inspection. Human approval and complete incident-response workflows remain underdeveloped.

### 2.2 Comparison table

Legend: **S** = explicit central capability; **P** = partial, adjacent, or integration-dependent; **—** = not evidenced as material. **Inv** means inventory/discovery, not authoritative identity. **ID** means identity/delegation. **Act** means pre-action policy. **Iso** means runtime isolation. **Aud** means audit/observability. **App** means human approval. **Eval** means risk/evaluation. **Comp** means compliance/assurance support. **IR** means incident containment/response. **On-prem** uses **Yes** for a fully customer-managed core control plane, **Partial** for hybrid/local data-plane or edition-limited deployment, **No** for vendor-hosted cloud/SaaS only, and **Mixed** when products grouped in one row differ. An on-prem connector, private endpoint, customer VPC, or coverage of on-prem assets does not by itself qualify. **Policy authoring** names the executable language or authoring model; JSON/YAML is identified as configuration unless it carries a defined rule DSL. Ratings summarize public evidence and are not independent validation. Microsoft AGT is included here as the focal open-source comparator; Section 6 provides its deeper assessment.

| Offering | Center of gravity | On-prem | Policy authoring | Inv | ID | Act | Iso | Aud | App | Eval | Comp | IR | Main limitation |
|---|---|---:|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---|
| [AWS Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/) | Managed runtime, gateway, policy | No | Cedar; Dogwood; NL→Cedar | P | S | S | S | S | — | S | P | P | Strongest inside AgentCore/AWS paths |
| [Google Gemini Enterprise Agent Platform](https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern) | Registry, identity, gateway | No | Natural-language semantic constraints | S | S | S | S | S | — | S | S | P | LLM-evaluated constraints are not a deterministic DSL |
| [Microsoft Entra Agent ID](https://learn.microsoft.com/en-us/entra/agent-id/what-is-microsoft-entra-agent-id) | Agent identity and lifecycle | No | Conditional Access UI/Graph objects | S | S | P | — | S | P | S | S | P | Not semantic tool control or isolation |
| [Microsoft Agent Governance Toolkit](https://github.com/microsoft/agent-governance-toolkit) | Embeddable runtime policy/enforcement middleware | Yes | YAML/JSON rule DSL; Rego; Cedar; custom | P | S | S | P | S | P | P | P | P | Public preview; host must provide complete mediation and hard controls |
| [Ping Agent Governance](https://www.pingidentity.com/en/product/agent-governance.html) | Cross-platform agent IGA | No | Workflow/UI controls; no public DSL | S | S | P | — | S | S | S | S | P | Runtime enforcement and policy grammar not public |
| [Cisco Zero Trust for Agentic AI](https://www.cisco.com/site/us/en/solutions/artificial-intelligence/security/securing-agentic-ai/index.html) | Identity, access, behavior | Partial | UI rules; natural-language Policy Studio | S | S | S | — | S | — | S | P | S | Generated internal representation is undisclosed |
| [Palo Alto Prisma AIRS](https://www.paloaltonetworks.com/ai-security/prisma-airs) | AI posture/runtime security | Partial | UI/API profiles; semantic topics | S | P | S | — | S | — | S | P | S | No public general-purpose policy DSL |
| [Holistic AI Guardian Agents](https://www.holisticai.com/guardian-agents) | Monitoring and containment | No | Product rules/workflows; no public DSL | S | P | S | — | S | — | S | S | S | Authoring schema is not publicly documented |
| [Check Point/Lakera](https://docs.lakera.ai/guard) | Discovery and inline AI security | Partial | Structured UI/API detector rules | S | P | S | — | S | — | S | P | S | JSON is configuration, not policy code |
| [IBM watsonx.governance](https://www.ibm.com/products/watsonx-governance) | Risk/compliance lifecycle | Yes | Console workflows and metric thresholds | S | P | P | — | S | P | S | S | P | Lifecycle governance, not inline authorization DSL |
| [Salesforce Trust Layer](https://www.salesforce.com/artificial-intelligence/trusted-ai/) | Platform privacy and trust | No | Policy Builder/templates; managed rules | P | P | P | — | S | P | S | S | P | No public native policy DSL |
| [Descope Agentic Identity Hub](https://docs.descope.com/agentic-identity-hub) | Identity and credential brokering | Partial | Console allow rules and conditions | S | S | S | — | S | P | — | P | P | No public DSL/API for policy management |
| [Docker MCP Enterprise Gateway](https://www.docker.com/products/mcp-enterprise-gateway/) | MCP policy and isolation | Yes | Cedar (`MCP` namespace) | S | S | S | S | S | — | P | S | S | Cedar scope is gateway-routed MCP activity |
| [Stacklok ToolHive](https://github.com/stacklok/toolhive) | OSS MCP gateway/runtime | Yes | Cedar in JSON/YAML/CRDs | S | S | S | S | S | — | P | P | P | Enterprise RBAC resources compile to Cedar |
| [Lasso MCP Security](https://www.lasso.security/use-cases/mcp-security) | MCP security and DLP | Partial | No-code proprietary rules | S | P | S | — | S | — | S | S | S | Public syntax/schema is undocumented |
| [Cerbos](https://www.cerbos.dev/features-benefits-and-use-cases/dynamic-authorization-for-MCP-servers) | Fine-grained authorization | Yes | YAML/JSON policies with CEL | P | P | S | — | S | — | — | S | P | Authorization PDP, not full agent governance |
| [Permit.io](https://www.permit.io/ai-access-control) | Authorization and access requests | Partial | Rego; Cedar; UI; relationship tuples | P | P | S | — | S | S | — | P | P | Local PDP depends on managed control plane |
| [Okta Cross App Access](https://www.okta.com/solutions/cross-app-access/) | Enterprise agent-to-app authorization | No | Console connection/scope allowlists | P | S | P | — | S | P | — | P | P | Downstream resource policy remains external |
| [Oasis Security](https://www.oasis.security/solutions/ai) | Non-human identity posture | No | Proprietary deterministic engine | S | S | P | — | S | — | S | S | S | Public authoring format is undocumented |
| [Credo AI Agent Governor](https://credo.ai/agent-governor) | Governance-as-code harness | Partial | Generated hooks/skills/settings | P | P | S | — | S | — | S | S | P | No public standalone grammar; research preview |
| [Galileo Agent Control](https://agentcontrol.dev/) | OSS runtime guardrails | Yes | Executable JSON control model | — | — | S | — | S | — | S | P | P | Defined rule tree, but no named general DSL |
| [NVIDIA NeMo Guardrails](https://github.com/NVIDIA-NeMo/Guardrails) | Programmable safety rails | Yes | Colang plus YAML and Python actions | — | — | P | — | P | — | S | — | P | Colang is specialized for conversational/event rails |
| [Phoenix](https://github.com/Arize-ai/phoenix), [AgentOps](https://github.com/AgentOps-AI/agentops), [LangSmith](https://langchain.com/langsmith-platform) | Tracing and evaluation | Mixed | Python/JS evaluators; UI automation rules | — | — | — | — | S | — | S | P | P | Mostly evaluation/telemetry, not enforcement policy |

### 2.3 What this means

The on-premise result supports the user's hypothesis. Across 23 comparison rows, seven have verified full customer-managed deployment, seven are partial/hybrid, eight are vendor-hosted only, and one grouped row is mixed. The major cloud-native agent platforms are predominantly **No**; IBM watsonx.governance is the clearest full-software exception. Open-source middleware and gateway projects—Microsoft AGT, ToolHive, Cerbos, Galileo Agent Control, and NeMo Guardrails—have the strongest self-deployment posture. A local connector, enforcement node, private-cloud tenant, or customer-VPC deployment should not be confused with a fully customer-managed governance control plane.

Three distinctions matter for CAF:

1. **Observability is not governance.** A trace explains what instrumentation saw; it does not prevent an unauthorized action.
2. **Policy is not enforcement.** An embedded policy library can be bypassed if the agent has another tool, shell, network, or credential path.
3. **Agent governance is not host security.** Application-level context improves decisions and evidence, but host controls still contain actual processes, files, networks, devices, and jobs.

## 3. Generic governance toolkits and partial components

Generic infrastructure is often more mature than agent-branded products. It should be reused rather than recreated, but it does not automatically carry agent purpose, delegation, or lifecycle context.

### 3.1 Reusable component map

| Need | Strong reusable options | What they provide | What CAF or the host must still provide |
|---|---|---|---|
| Contextual policy | [OPA](https://www.openpolicyagent.org/docs/latest/), [Cedar](https://docs.cedarpolicy.com/) | Deterministic decisions over structured context | Trusted inputs, policy administration, non-bypassable PEP, evidence |
| Relationship authorization | [OpenFGA](https://openfga.dev/), [SpiceDB](https://authzed.com/docs/spicedb/getting-started/discovering-spicedb) | Fine-grained graph permissions | Authentication, purpose/risk policy, enforcement, approval |
| Human identity | Existing enterprise IdP; [Keycloak](https://www.keycloak.org/) | OIDC/OAuth/SAML, federation, sessions | Workload attestation and explicit delegation to an agent task |
| Workload identity | [SPIFFE/SPIRE](https://spiffe.io/docs/latest/spiffe-about/overview/) | Short-lived attested workload credentials | Human sponsor, task mandate, resource/action authorization |
| Artifact trust | [Sigstore](https://docs.sigstore.dev/about/overview/), [in-toto](https://in-toto.io/), [SLSA](https://slsa.dev/spec/v1.2/) | Signatures, provenance, supply-chain attestations | Admission policy and runtime binding to the admitted digest |
| Deployment admission | [Kyverno](https://kyverno.io/docs/introduction/how-kyverno-works/), [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) | Kubernetes validation, mutation, audit | Non-Kubernetes launch paths and runtime tool/API calls |
| Secrets and credentials | [OpenBao](https://openbao.org/), [Infisical](https://infisical.com/), cloud secret managers | Dynamic credentials, leases, revocation, PKI | Task-specific authorization, delivery isolation, approval semantics |
| Runtime isolation | [gVisor](https://gvisor.dev/docs/), [Kata Containers](https://katacontainers.io/learn/), [Firecracker](https://firecracker-microvm.github.io/) | Stronger execution boundaries | Business authorization, HPC placement, operational integration |
| Runtime detection/enforcement | [Falco](https://falco.org/docs/), [Tetragon](https://tetragon.io/docs/overview/) | Kernel/runtime visibility and selected enforcement | Agent intent and application-level tool semantics |
| Telemetry | [OpenTelemetry](https://opentelemetry.io/docs/what-is-opentelemetry/) | Vendor-neutral traces, logs, metrics, propagation | Audit completeness, integrity, retention, access, legal sufficiency |
| Security operations | [Wazuh](https://wazuh.com/), Splunk, Datadog | Search, detection, retention, response integrations | Agent-specific event schema and causal correlation |
| Compliance exchange | [OSCAL](https://pages.nist.gov/OSCAL/), [Compliance Trestle](https://oscal-compass.dev/compliance-trestle/latest/) | Machine-readable controls and assessment artifacts | Actual enforcement, measurements, ownership, assurance decisions |
| Data/run lineage | [OpenLineage](https://openlineage.io/docs/), [DataHub](https://docs.datahub.com/docs/introduction) | Run, dataset, ownership, and metadata relationships | Agent action/approval facets and evidence integrity |
| Artifact knowledge | [GUAC](https://github.com/guacsec/guac), [Grafeas](https://github.com/grafeas/grafeas) | Supply-chain and artifact metadata graphs | Action authorization, human approval, runtime outcome evidence |
| Durable approval | [Temporal](https://docs.temporal.io/), [Flowable](https://www.flowable.com/open-source) | Long-running workflow, timers, signals, human tasks | Approval UX, identity proof, separation of duties, scoped capability |
| HPC scheduling | [Slurm](https://slurm.schedmd.com/rest.html) and site schedulers | Authoritative placement and workload lifecycle | Runtime-neutral agent operation envelope and run/job correlation |

### 3.2 Recommended composition

A practical governance request path is:

1. A human authenticates through the site IdP; the application records user, task, purpose, and delegation limits.
2. The CAF workload receives an attested, short-lived workload identity.
3. The host verifies the image, adapter, policy/configuration, and attestations before launch.
4. Each selected tool or inference request enters a CAF adapter with human, workload, run, call, resource, and task context.
5. A host policy service returns the authoritative decision and obligations.
6. High-impact requests may create a durable approval workflow that issues a narrow, expiring capability bound to the exact action.
7. The action executes under host-controlled container, network, filesystem, resource, credential, and scheduler controls.
8. CAF emits application-level evidence; the host exports, retains, correlates, and investigates it with existing systems.

The missing reusable standard is a cross-component correlation envelope, but CAF should introduce it in layers. The **MVP core** should contain run/call IDs, operation class, decision reference, status, and scheduler or other external references. **Optional opaque host references** may identify a human principal, workload identity, approval, or artifact attestation without making CAF authoritative for them. **Future extensions** may carry richer delegation and assurance context after concrete integrations prove the need. CAF exports application-level evidence; it does not ingest or correlate host telemetry.

### 3.3 Selection, licensing, and deployment details

The following alternatives materially affect portability, operations, or product licensing and should not disappear behind a shortlist.

| Component | Type and license/posture | Deployment choice | Selection trigger or limitation |
|---|---|---|---|
| OPA | Apache-2.0 policy engine; self-hosted/embedded; managed administration available from vendors | Sidecar, service, gateway, admission | Best for arbitrary structured policy; CAF still needs PEPs and policy lifecycle |
| Cedar | Apache-2.0 language/engine; managed through Amazon Verified Permissions or embedded | Embedded or AWS managed | Strong schema-aware authorization; narrower than general Rego policy |
| OpenFGA / SpiceDB | Apache-2.0 ReBAC engines; self-hosted and managed choices | Central permissions service | Add only when permissions are naturally relationship graphs |
| OpenBao | MPL-2.0 self-hosted secrets platform | Site-operated | Open-source Vault lineage; operational HA/key management required |
| HashiCorp Vault | BSL 1.1 current source plus commercial/managed editions | Self-managed or HCP | Mature ecosystem, but embedding/competitive-service use needs legal review |
| External Secrets Operator | Apache-2.0 Kubernetes delivery bridge | Kubernetes operator | Not a vault; materializing Kubernetes Secrets changes exposure |
| SOPS | MPL-2.0 encrypted-file tool | GitOps/client-side | Useful for config files; no dynamic leases, revocation, or runtime audit |
| osquery / Wazuh | Apache/GPL host telemetry and security monitoring | Self-hosted or Wazuh Cloud | Infrastructure evidence; agent semantics still require CAF events |
| OpenSCAP | LGPL scanner/toolkit | Host-side assessment | Strong for configuration baselines, not agent behavior or approvals |
| ServiceNow IRM/GRC | Proprietary enterprise GRC | Managed platform | Use for owners, risks, exceptions, and auditors—not synchronous policy |
| Temporal / Flowable | MIT durable workflow / Apache BPMN-CMMN-DMN engines, with managed/commercial options | Self-hosted or managed | Temporal for code-first durability; Flowable for modeled human tasks |
| Argo Workflows / GitHub environments | Apache Kubernetes workflow / proprietary deployment approval | Cluster or GitHub | Useful narrow workflow gates, not general human-approval governance |
| DataHub / Collibra | Apache open-core / proprietary cloud data governance | Self-hosted/managed or cloud | Data ownership/lineage, not runtime action authorization |
| KServe V2 protocol | Open inference data-plane specification | Model-serving provider interface | Useful optional provider; insufficient as CAF's universal generative contract |

## 4. Policy languages and authoring models

Policy definition is a general software-governance problem, not an AI-agent-specific one. Agent systems make it more visible because tool calls combine identity, delegated purpose, changing context, untrusted content, and potentially irreversible effects. The underlying design question is the same as for API authorization, Kubernetes admission, infrastructure compliance, and enterprise access control: **is policy merely selecting predefined behavior, or must authors express new decision logic?**

### 4.1 JSON/YAML is syntax, not policy semantics

JSON and YAML can carry policies, but neither format defines policy behavior. They do not specify attribute lookup, missing values, type coercion, precedence, conflict resolution, default allow/deny, approval, explanations, or enforcement. Those semantics come from a schema, evaluator, or embedded language.

| Layer | Purpose | Examples | Key boundary |
|---|---|---|---|
| Serialization | Encodes data or an abstract syntax tree | JSON, YAML, Protobuf | Does not define policy meaning |
| Structured policy model | Selects from product-defined checks and effects | allowlists, thresholds, rule records | Flexible only within the predefined schema |
| Expression language | Adds bounded predicates inside a host model | CEL, JMESPath | Host still defines decisions and lifecycle |
| Policy DSL | Defines composable decision logic | Rego, Cedar, Polar, Sentinel | Needs runtime, tooling, and administration |
| Relationship model | Defines graph permissions | OpenFGA, SpiceDB | Specialized for reachability, not arbitrary policy |
| Decision API | Carries requests and decisions | OpenID AuthZEN | Does not prescribe language or enforcement |
| Authoring interface | Captures human intent | UI forms, templates, natural language | Must map to reviewable semantics |

A nested YAML document containing `all`, `any`, `not`, selectors, variables, and effects is already a small DSL represented as YAML. Calling it “configuration” does not eliminate the need to specify and test its language semantics.

### 4.2 When JSON/YAML is enough

Schema-governed JSON/YAML is appropriate when:

- the decision vocabulary is closed, such as tool allowlists, quotas, labels, thresholds, and fixed approval classes;
- rules are shallow and rely on request-local attributes;
- combination is simple and explicit, such as deny-overrides or first-match;
- effects are fixed, usually allow, deny, require approval, redact, route, or log;
- the complete document can be validated before activation; and
- operators benefit more from forms and schema-aware editors than from programming abstractions.

This constrained model can be the right permanent product interface. It lowers learning cost, enables exhaustive validation, bounds performance, simplifies explanation, and permits controlled mapping to multiple backends. It should still include a versioned schema, rejected unknown fields, explicit defaults, policy IDs and versions, deterministic error behavior, unit tests, simulation, and activation history.

### 4.3 When a dedicated language is justified

A dedicated DSL or expression language becomes valuable when authors need several of the following:

- reusable derived facts and modules;
- nested boolean logic, quantification, joins, or collection reasoning;
- graph traversal and inherited permissions;
- explicit conflict, exception, priority, and obligation semantics;
- static type/schema checking across rules;
- partial evaluation or data filtering;
- structured outputs beyond allow/deny;
- independent policy ownership, versioning, distribution, and promotion; or
- analysis such as unreachable-rule detection, coverage, explanation, and impact simulation.

Repeated additions of `all`/`any`/`not`, path expressions, references, macros, priorities, imports, and custom functions are a warning that a “simple” configuration schema has become an accidental language without mature tooling.

### 4.4 Main language families

| Technology | Model and strengths | Best fit | Main tradeoff |
|---|---|---|---|
| [OPA/Rego](https://www.openpolicyagent.org/docs/latest/policy-language/) | General declarative logic over structured data; tests, bundles, explanations, partial evaluation | Heterogeneous authorization, admission, compliance, routing | Learning curve and broad semantic surface |
| [Cedar](https://docs.cedarpolicy.com/) | Authorization-specific principal/action/resource/context model; schemas; default deny; forbid overrides permit | Application and tool authorization needing analyzability | Narrower than Rego for arbitrary transformations |
| [CEL](https://cel.dev/) | Safe, portable, bounded expression language embedded by a host | Predicates within an existing resource/rule model | Not a policy lifecycle or combining system by itself |
| [OpenFGA](https://openfga.dev/docs/modeling/getting-started) / [SpiceDB](https://authzed.com/docs/spicedb/concepts/schema) | Relationship schemas and tuples for graph permissions | Organizations, folders, sharing, delegation, inheritance | Poor fit for arbitrary document/risk policy alone |
| [XACML](https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html) | Standard ABAC model, combining algorithms, obligations, PDP/PEP architecture | Regulated enterprise authorization and interoperability | Verbose and operationally complex |
| [Casbin](https://casbin.org/docs/syntax-for-models/) / [Oso Polar](https://www.osohq.com/docs/reference/polar) | Configurable access-control model or application-oriented authorization DSL | Embedded application authorization | Portability and administration depend on host ecosystem |
| [Kyverno](https://kyverno.io/docs/introduction/how-kyverno-works/) / Kubernetes [ValidatingAdmissionPolicy](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/) | Domain policy resources in YAML, often with CEL/JMESPath expressions | Kubernetes admission, mutation, image and configuration policy | Domain-specific; not runtime tool authorization |
| [DMN/FEEL](https://www.omg.org/dmn/) / rule engines | Decision tables, business rules, and workflows | Business decisions requiring analyst-readable models | Usually heavier than hot-path authorization |

No language is universally best. Rego is the broadest general policy option. Cedar offers a deliberately narrower and strongly analyzable authorization model. CEL is a good intermediate step when structured resources need richer predicates. Relationship engines should be selected for graph-shaped permissions rather than used as universal policy systems.

### 4.5 What the reviewed platforms actually use

The market does not converge on one language:

- **Named policy languages:** AWS AgentCore, Docker MCP Gateway, and ToolHive use Cedar; Permit supports Rego and Cedar; Cerbos combines YAML/JSON policy resources with CEL; NeMo Guardrails uses Colang.
- **Multiple policy backends:** Microsoft AGT has a YAML/JSON rule DSL and supports Rego, Cedar, and custom dispatchers. Its ACS manifest is configuration that binds intervention points to policy executors; it is not itself the full rule language.
- **Structured executable configuration:** Galileo Agent Control has a defined recursive JSON control model. Entra, Descope, Check Point/Lakera, Salesforce, and Okta primarily expose product-owned UI/API rule objects.
- **Natural-language authoring:** Google evaluates natural-language semantic constraints at runtime. Cisco Policy Studio drafts and tunes guardrails from prose. These approaches reduce authoring friction but differ fundamentally from deterministic policy-as-code.
- **Proprietary or undocumented semantics:** Ping, Holistic AI, Lasso, Oasis, and Credo expose policy capabilities without a public executable grammar sufficient for independent analysis.
- **Evaluation rather than enforcement:** Phoenix, AgentOps, and most LangSmith evaluator/automation features use code or UI rules to score and route telemetry. Those mechanisms should not be mislabeled as authorization languages.

This diversity makes the policy request/decision contract more durable than any source language. Product comparisons should ask not only “what syntax?” but also whether policies can be typed, tested, simulated, versioned, reviewed, signed, composed, explained, audited, promoted, and executed offline.

### 4.6 Natural language should be an authoring aid, not the sole authority

Natural language is useful for drafting, search, explanation, and converting organizational requirements into candidate rules. For consequential authorization, the safer pattern is:

1. generate a deterministic intermediate policy;
2. validate it against a schema and supported vocabulary;
3. show the exact diff and explanation to a reviewer;
4. run tests and impact simulation;
5. approve, version, sign, and promote it; and
6. log the policy version and determining rule with each decision.

Direct LLM evaluation of prose can be appropriate for semantic risks that resist crisp rules, such as intent or content classification. It should be bounded by deterministic controls for identity, tool/resource scope, budgets, credentials, and high-impact effects, with explicit handling for model error and uncertainty.

### 4.7 Recommendation for CAF

CAF should **not build a new general policy language**. Its public contract should define a vendor-neutral policy request and decision envelope, including the action context, allow/deny result, reason, policy/version reference, and bounded obligations such as approval or redaction. Backend-specific details should remain namespaced.

For initial CAF profiles:

1. Use schema-governed JSON/YAML for a small common set of HPC guardrails and profile selections.
2. Permit a bounded expression layer only if fixed fields become insufficient; CEL is a strong pattern for this tier.
3. Evaluate Cedar for tool/resource authorization and OPA/Rego for broader heterogeneous host policy behind the same provider interface.
4. Use a relationship engine only if recursive delegation and resource-sharing requirements become graph-shaped.
5. Treat AGT as one replaceable provider that can execute its YAML DSL, Rego, Cedar, or custom policy—not as CAF's canonical language.
6. Require every provider to pass the same conformance tests for default-deny behavior, missing attributes, errors/timeouts, decision explanations, obligations, version evidence, offline deployment, and performance.

The practical choice is therefore **not JSON/YAML versus Rego**. It is a staged architecture: constrained typed configuration for common policy, specialized languages where their semantics fit, and a stable decision interface that prevents CAF from being captured by any one engine.

## 5. Standards and governance frameworks

Standards provide important obligations and interfaces, but they do not form a complete executable agent-governance system.

| Category | Relevant standards/frameworks | Role | Important boundary |
|---|---|---|---|
| AI risk and management | [EU AI Act](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai), [NIST AI RMF](https://www.nist.gov/itl/ai-risk-management-framework), [ISO/IEC 42001](https://www.iso.org/standard/42001) | Legal obligations and management/risk processes | Not runtime policy engines |
| Agent threats | [OWASP Agentic Top 10](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/), [MITRE ATLAS](https://atlas.mitre.org/) | Threat modeling and test coverage | Mapping does not prove control effectiveness |
| Identity/delegation | [OAuth Token Exchange RFC 8693](https://www.rfc-editor.org/rfc/rfc8693), [RAR RFC 9396](https://www.rfc-editor.org/rfc/rfc9396), [GNAP RFC 9635](https://www.rfc-editor.org/rfc/rfc9635), [SPIFFE](https://spiffe.io/) | Mature primitives for token exchange, structured authorization, delegation, workload identity | No universal agent mandate or recursive delegation model |
| PEP/PDP interface | [OpenID AuthZEN 1.0](https://openid.net/specs/authorization-api-1_0.html) | Standard authorization request/decision interface | Leaves policy language, state, identity, and enforcement external |
| Tool protocol | [MCP](https://modelcontextprotocol.io/specification/latest/basic/authorization) | Tool/resource protocol and optional OAuth-based authorization | Does not decide semantic safety or mandate alignment; STDIO differs |
| Agent protocol | [A2A](https://a2a-protocol.org/latest/specification) | Agent discovery, messaging, tasks, streaming | Authorization and recursive trust remain implementation-specific |
| Telemetry/evidence | [OpenTelemetry](https://opentelemetry.io/docs/specs/otel/), [W3C PROV-O](https://www.w3.org/TR/prov-o/), [SCITT drafts](https://www.ietf.org/archive/id/draft-ietf-scitt-architecture-08.html) | Correlation, provenance, emerging signed receipts | No settled portable audit-grade agent action receipt |
| Supply-chain evidence | [in-toto](https://in-toto.io/Statement/v1), [SLSA](https://slsa.dev/spec/v1.2/), [Sigstore](https://docs.sigstore.dev/) | Artifact provenance, signing, verification | Proves artifact facts, not runtime intent or authorization |
| Compliance automation | [NIST SP 800-53](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), [OSCAL](https://pages.nist.gov/OSCAL/) | Control catalogs and machine-readable compliance data | Representation is not enforcement or assurance |

The central standards gap is end-to-end binding among agent identity, human or organizational mandate, recursive delegation, per-action policy, runtime execution, and portable tamper-evident evidence. CAF should not attempt to solve this globally. It should define the smallest HPC-managed-path envelope it needs and map to emerging standards where practical.

## 6. Microsoft AGT: technical assessment and industry position

AGT should be evaluated as one coherent product proposition: an embeddable runtime governance layer with a broad collection of supporting primitives. Its value comes from joining agent-aware policy context to lifecycle interception. Its limits come from the same architecture: the surrounding application and host must make that interception complete and enforce the returned decision.

### 6.1 Core architecture

AGT is best categorized as **embeddable agent-aware policy and enforcement middleware with supporting governance primitives**. Its technical center is ACS:

- The trusted host is the policy enforcement point.
- ACS core evaluation is stateless and deterministic for identical snapshots and externally supplied dispatcher outputs; classifier, endpoint, or LLM annotators remain host-controlled and may be probabilistic.
- The host sends a complete JSON snapshot at a lifecycle intervention point.
- ACS returns a verdict; the host applies it before the side effect.
- Supported policy paths include YAML rules, Rego/OPA, Cedar, and custom dispatchers.
- Intervention points cover startup, input, model calls, tool calls, output, and shutdown.

This is broader than an MCP gateway because it can mediate model and lifecycle events. It is narrower than a complete governance platform because its authority ends where integration or host enforcement ends.

### 6.2 Supporting capabilities

AGT’s repository also includes:

- agent DIDs, sponsor attribution, scoped delegation, revocation, and behavioral trust scores;
- structured audit entries, hash chains, Merkle proofs, CloudEvents, and OpenTelemetry sinks;
- framework adapters and middleware across Python, TypeScript, .NET, Rust, and Go;
- MCP inspection/gateway modules, response filtering, rate and session controls;
- approval metadata and liftable denials;
- reliability/SRE primitives, replay, circuit breakers, and cooperative kill hooks;
- compliance mappings, policy packs, evidence exports, examples, and deployment guidance.

The breadth is real, but not uniform. Python is materially ahead in adapters, CLI, dashboard, replay, compliance workflow, and tests. “Supported framework” can mean anything from deep lifecycle integration to a wrapper or exporter; each path requires coverage and bypass tests. These conclusions are grounded in the commit-pinned [architecture](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/ARCHITECTURE.md), [policy-engine contract](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/policy-engine/README.md), [feature matrix](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/PACKAGE-FEATURE-MATRIX.md), and [limitations](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/LIMITATIONS.md).

### 6.3 Enforcement and security boundary

AGT’s most important limitation is mediation completeness. In-process adapters and sidecars are not transparent security boundaries. The agent or host must route every relevant action through them. A direct shell, API, network, SDK, or native framework path can bypass governance unless the surrounding host denies that alternate path.

The project’s own documentation recommends container or VM isolation for high-security deployments. Default behavior also requires attention: runtime evaluation errors can fail closed, but absent or misinitialized policy may allow actions. A production integration needs startup attestation, default-deny policy, pinned versions, and negative tests against every public action path.

AGT identity is an agent-aware overlay, not a replacement for enterprise identity. Its DIDs, keys, sponsors, capability narrowing, and delegation chains are valuable policy context. Enterprise IdP, workload attestation, KMS, credential issuance, revocation distribution, and authoritative access remain external.

AGT audit structures improve tamper detection, but the [commit-pinned Python implementation](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/agent-governance-python/agent-mesh/src/agentmesh/governance/audit.py) stores the default audit log in memory. Hash chains and Merkle proofs do not prevent deletion, rollback, or recomputation unless roots and events are exported to an independently controlled append-only store.

### 6.4 Maturity

At the reviewed commit [`c63c51e`](https://github.com/microsoft/agent-governance-toolkit/commit/c63c51e881c442fbc060705f7e211f29993f2c1b), AGT was a high-velocity public preview. The dated [repository page](https://github.com/microsoft/agent-governance-toolkit) showed approximately 6.3k stars, 1.1k forks, and 2,617 commits; the tree covered five language families and extensive tests. The commit-pinned [README](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/README.md) labels the project public preview, while [security/version documentation](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/SECURITY.md) and [breaking changes](https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/BREAKING_CHANGES.md) expose the current support and churn risks.

Important adoption risks include:

- fast API and package churn;
- uneven cross-language semantics, including identity-prefix differences;
- formal releases lagging source/tag state at the evidence date;
- stale or inconsistent version-support documentation;
- host obligations changing during ACS extraction;
- cooperative rather than authoritative process termination;
- remote-manifest hardening concerns documented in breaking-change notes;
- public adopter information that is directional rather than independently verified.

The MIT license is permissive, but license suitability does not remove integration, support, or maturity risk.

### 6.5 Industry position

| Industry layer | AGT fit |
|---|---|
| Runtime action policy PDP | **Core strength**: stateless ACS evaluation with multiple policy backends; determinism depends on identical snapshots and dispatcher outputs |
| Framework/runtime PEP | **Core but integration-dependent**: adapters, middleware, sidecar, MCP gateway |
| Agent identity/delegation | **Substantial overlay** requiring enterprise IAM/KMS/workload integration |
| Audit/evidence | **Strong SDK primitives** requiring durable host storage and independent anchoring |
| MCP/tool security | **Strong complementary module** |
| Model/content safety | **Partial**: lifecycle hooks and optional classifiers, not complete model safety |
| Data/RAG governance | **Gap/integration seam** |
| Workload isolation | **Defense-in-depth helpers, not the hard boundary** |
| IAM/PAM/secrets | **Not a replacement** |
| Enterprise GRC/SIEM | **Not a replacement** |
| Managed governance control plane | **Not present as a turnkey multi-tenant service** |

AGT fits between stochastic agent logic and deterministic enterprise controls. It competes most directly with embeddable runtime guardrail and policy projects while complementing enterprise identity, credential, gateway, isolation, observability, and GRC systems. Its correct industry-map position is **agent runtime governance middleware**, not a turnkey end-to-end governance platform.

This position explains both its breadth and its gaps. AGT confirms the broader market finding that an agent application needs a deterministic interception layer, but also demonstrates why that layer cannot govern alone:

- policy effectiveness depends on complete, non-bypassable integration;
- agent identity needs authoritative enterprise identity and credential systems;
- action records need durable external evidence storage;
- runtime policy does not create workload isolation;
- standards mappings do not establish compliance; and
- one middleware layer cannot govern alternate shell, network, computer-use, or downstream workload paths.

The practical implication is to adopt AGT selectively. Its policy, adapter, identity-context, MCP, and evidence patterns can reduce implementation effort, but enterprise and host systems remain authoritative for access, containment, persistence, and response.

## 7. CAF v2: fit, build-versus-reuse, and AGT evaluation

CAF and AGT overlap at the runtime policy/interception seam, but they solve different product problems. CAF provides a stable compatibility and evidence boundary for replaceable agent runtimes on managed HPC. AGT is a candidate implementation within that boundary. Combining the architecture and evaluation decisions makes the dependency choice explicit rather than treating AGT as a parallel product strategy.

### 7.1 CAF product boundary

CAF v2 already draws the right high-level boundary:

- the selected runtime owns reasoning, memory, and context;
- CAF routes designated tool and inference operations through adapters;
- the host supplies policy and hard enforcement;
- CAF emits application-level evidence for the managed path;
- the host owns image admission, identity, credentials, scheduling, mounts, network, resources, telemetry, retention, and incident response.

The dated MVP baseline pins `@earendil-works/pi-coding-agent@0.83.0`. That exact pin supports reproducibility for the first profile; it is not a permanent product dependency.

This makes CAF an **agent-runtime compatibility and evidence layer for managed HPC**. It should remain narrower than AGT’s full repository scope and narrower than cloud agent platforms.

### 7.2 Capability decision matrix

| Capability | Decision | CAF owns | Reuse/integrate | AGT role |
|---|---|---|---|---|
| CAF run/call contract | **Build** | IDs, operation envelope, status/error semantics, versioning | JSON Schema/open formats | Learn from ACS; do not make ACS the public CAF contract initially |
| Runtime adapter SDK | **Build** | Minimal SPI for selected tools, inference, context, outcomes | Runtime extension APIs | Evaluate AGT adapter/ACS embedding patterns |
| Runtime admission | **Build** | Manifest, effective tool surface, bypass limits, conformance tests | CI, signing, scanners | Reuse selected test concepts; keep CAF criteria authoritative |
| Pi integration | **Integrate, no fork** | Thin Pi adapter | Pi reasoning/runtime | Pilot AGT only if Pi interception is complete and maintainable |
| Execution profile | **Build portable core; host resolves/enforces** | Requested intent classes and resolved-profile reference | Site policy and launcher-specific profile | AGT may consume context but must not own host resolution |
| OCI composition and launch | **Reuse with CAF profile** | Image labels, runtime/adapter compatibility declaration | OCI tooling, Apptainer or site-selected runtime | No primary AGT role; host owns admission and isolation |
| Policy engine | **Do not build** | Vendor-neutral request/decision envelope | Host OPA/Cedar/other PDP | ACS may be an optional PDP provider |
| Identity and credentials | **Do not build** | Opaque fields/references and correlation | Site IdP, SPIFFE, secrets/PAM | AGT DID/delegation can be optional context, not authority |
| Image trust/admission | **Host-owned** | Required CAF manifest claims | OCI, Sigstore, host allowlist/admission | No primary role |
| Workspace/file operations | **Build adapter only** | Normalized request/result and evidence | Site storage/filesystem controls | Possible pre/post operation policy hook |
| Scheduler operations | **Build CAF facade** | Submit/status/cancel/result vocabulary; idempotency; run/job linkage | Slurm or other scheduler | Possible pre-action policy; host scheduler remains authoritative |
| MCP/tool transport | **Adopt optionally behind CAF semantics** | CAF identity, decision, outcome, scheduler linkage, evidence obligations | MCP or runtime-native tools | AGT MCP modules are candidates; MCP must not become the CAF contract |
| Inference routing | **Build adapter only** | Correlation and permitted metadata | Site inference gateway/model service | Optional pre/post model hooks |
| Application evidence | **Build schema/emission** | CAF semantics, causality, scheduler linkage, redaction class | OTel/exporters/SIEM/storage | Reuse patterns or exporters only after schema mapping |
| Isolation and resource control | **Do not build** | References to host decisions | OCI runtime, Apptainer, Kubernetes, gVisor/Kata, site controls | Defense-in-depth only; never the hard boundary |
| Retention/GRC/IR | **Do not build** | Exportable evidence references | SIEM, GRC, SOAR, retention systems | Compliance mappings may help but are not authoritative |
| Developer experience | **Build thinly** | Validate, launch, inspect capabilities, explain failures | Existing portals, shell, notebooks, CI | Avoid importing AGT dashboard/control-plane scope by default |

### 7.3 What CAF should uniquely build

CAF’s differentiated intellectual property should be limited to:

1. A runtime-neutral managed-operation envelope whose MVP core contains run/call identity, requested operation, host decision reference, normalized outcome, and external workload references; actor, delegation, approval, and attestation data remain optional opaque host references until proven necessary.
2. A minimal runtime adapter SPI for replacing selected tool and inference paths without owning the reasoning loop.
3. A runtime admission and conformance kit that proves interception coverage, effective tool surface, fail behavior, evidence emission, and known bypasses.
4. HPC-specific provider facades for workspace, inference, scheduler, and launch/profile resolution.
5. Application-level evidence semantics that link agent operations to scheduler jobs and returned outputs without collecting host telemetry.

CAF should not build a new policy language, identity provider, secrets vault, scheduler, inference server, telemetry backend, GRC suite, workflow engine, or sandbox.

### 7.4 AGT evaluation decision

CAF should neither adopt nor reject AGT based on repository breadth. It should run a narrow comparison against a minimal OPA/Cedar provider behind the same CAF-owned interface. The proof should determine whether AGT reduces implementation and maintenance cost without weakening CAF's portability or host authority.

#### Pilot scope

Use one pinned AGT/ACS version behind a CAF policy-provider interface for the Pi MVP. Test only:

- `pre_tool_call` as the execution gate and `post_tool_call` as outcome capture/returned-data filtering for `read`, `write`, `edit`, and `bash`;
- selected inference pre/post metadata hooks if Pi exposes a reliable seam;
- strict default-deny startup behavior;
- allow, deny, and transform outcomes; plus liftable denials carrying approval metadata and host-side approval resolution;
- export of policy decision references into the CAF evidence envelope;
- offline operation with no Azure dependency;
- bounded overhead at expected HPC tool-call rates.

#### Acceptance criteria

AGT is a good CAF dependency only if:

1. Every selected Pi action path reaches the policy hook before side effects.
2. Direct or alternate paths are either blocked by the host or documented and tested as CAF gaps.
3. CAF owns the public operation/evidence schema; AGT-specific fields stay in a namespaced extension.
4. Policy absence, load failure, timeout, and malformed decisions fail according to CAF’s contract.
5. AGT can use host identity and policy context without becoming the authoritative identity store.
6. Decision events export to host-controlled storage with CAF run/call correlation.
7. A fixed version can be supported without following main-branch churn.
8. Removing AGT or replacing it with OPA/Cedar directly does not require changing the runtime-facing CAF contract.

#### Reject or defer AGT if

- Pi interception requires a fork or invasive coupling;
- the sidecar remains bypassable under the accepted host profile;
- cross-language/runtime semantics cannot be normalized;
- the dependency materially expands the image, attack surface, or operational control plane without reducing CAF code;
- AGT’s event and identity schemas begin to replace CAF’s product contract;
- the product team would need to maintain broad AGT modules unrelated to the MVP.

## 8. Strategic recommendation

### 8.1 Near-term

Proceed with CAF’s current thin architecture. Freeze four versioned seams: runtime SPI, host provider interfaces, evidence export, and admission/conformance. Keep Pi pinned and unforked. Implement or complete the smallest end-to-end managed path before adding governance breadth.

Run a time-bounded AGT/ACS spike in parallel with a simpler OPA/Cedar provider baseline. Compare code size, interception coverage, failure semantics, performance, maintenance burden, and evidence integration. The decision is not “AGT versus CAF.” It is whether AGT reduces the implementation cost of one replaceable CAF policy/interception layer.

### 8.2 Next architectural proof

After the Pi MVP, admit a materially different second runtime. This is more important than expanding Pi features because it tests whether CAF’s contract is truly runtime-neutral. Then validate a second host profile or scheduler integration. The same CAF core, provider interfaces, and evidence consumers should survive both tests.

### 8.3 Longer-term position

CAF should position itself as the managed-HPC integration layer that can consume governance services rather than compete with them. This preserves customer choice and allows sites to use Microsoft AGT, OPA, Cedar, Entra, SPIFFE, existing HPE services, or customer-native equivalents.

A defensible ecosystem message is:

- CAF makes selected agent operations identifiable and governable at the application boundary.
- The host remains authoritative for identity, resource access, isolation, scheduling, telemetry, retention, and response.
- Governance engines and services are replaceable providers behind published CAF contracts.
- CAF adds the HPC-specific runtime, scheduler, and evidence semantics that generic agent-governance products do not provide.

## 9. Evaluation and procurement checklist

Any agent-governance component considered for CAF or a host profile should answer:

1. What exact action boundary does it govern, and how is bypass prevented?
2. Does it preserve user → agent → sub-agent → tool delegation and causality?
3. Can it authorize the exact tool, resource, arguments, purpose, budget, and data class?
4. Are credentials short-lived, audience-bound, scope-limited, and outside model context?
5. What happens when policy, network, telemetry, or approval services fail?
6. Can high-risk actions require scoped, expiring, separation-of-duty approval?
7. Does it isolate the agent process, tool server, filesystem, network, and secrets—or only inspect traffic?
8. Are allowed and denied decisions exported with stable IDs and policy versions?
9. Can sensitive content be omitted while preserving forensic usefulness?
10. Do evaluations gate releases/actions or merely populate dashboards?
11. Are compliance claims mappings, operational evidence, independent attestations, or certifications?
12. Can responders revoke identity/credentials, stop work, quarantine components, preserve evidence, and recover?
13. Is the deployment viable offline or in a disconnected HPC environment?
14. What open-source and commercial features, licenses, SLAs, and upgrade obligations apply?
15. Can the component be removed without changing CAF’s public contracts?

## 10. Risks and unresolved decisions

- **Mediation gap:** CAF and AGT govern only routed operations. Host controls must constrain direct shell, network, credential, and scheduler alternatives.
- **Policy split brain:** CAF must not maintain policy that conflicts with host authority. Host decisions and references are authoritative.
- **Evidence overclaim:** CAF records application-level requests and returned results, not every downstream effect of a shell command or scheduled job.
- **Schema capture:** AGT, MCP, Slurm, Pi, or a specific SIEM must not define CAF’s durable core schema.
- **Preview dependency:** AGT’s velocity is promising but increases pinning, conformance, support, and security-review costs.
- **Disconnected deployment:** Every external identity, policy, package, and telemetry dependency needs an explicit offline profile before it becomes an HPC product claim.
- **Human approval:** The MVP can defer a full workflow engine, but the request/decision model should leave room for approval-bound obligations.

## 11. Final decision

CAF should **build** its small product-defining semantic layer and **reuse** established infrastructure for every generic mechanism. Microsoft AGT should be treated as a high-potential optional implementation for runtime policy and governance primitives, tested behind CAF-owned interfaces. It should not become CAF’s architecture, identity authority, evidence contract, or hard security boundary.

This approach avoids two bad extremes: rebuilding mature governance infrastructure inside CAF, or outsourcing CAF’s product identity to a fast-moving third-party toolkit. It preserves CAF’s thin, replaceable, developer-first design while giving it a credible path to consume stronger governance capabilities as the market and standards mature.

## Selected primary references

- Microsoft Agent Governance Toolkit: https://github.com/microsoft/agent-governance-toolkit
- Microsoft AGT architecture (reviewed commit): https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/ARCHITECTURE.md
- Microsoft AGT limitations (reviewed commit): https://github.com/microsoft/agent-governance-toolkit/blob/c63c51e881c442fbc060705f7e211f29993f2c1b/docs/LIMITATIONS.md
- Microsoft AGT policy engine (reviewed commit): https://github.com/microsoft/agent-governance-toolkit/tree/c63c51e881c442fbc060705f7e211f29993f2c1b/policy-engine
- AWS AgentCore: https://aws.amazon.com/bedrock/agentcore/
- Google agent governance: https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern
- Microsoft Entra Agent ID: https://learn.microsoft.com/en-us/entra/agent-id/what-is-microsoft-entra-agent-id
- Docker MCP Enterprise Gateway: https://www.docker.com/products/mcp-enterprise-gateway/
- Stacklok ToolHive: https://github.com/stacklok/toolhive
- Descope Agentic Identity Hub: https://docs.descope.com/agentic-identity-hub
- Open Policy Agent: https://www.openpolicyagent.org/docs/latest/
- SPIFFE/SPIRE: https://spiffe.io/docs/latest/spiffe-about/overview/
- OpenTelemetry: https://opentelemetry.io/docs/
- Model Context Protocol: https://modelcontextprotocol.io/specification/latest/basic/authorization
- A2A specification: https://a2a-protocol.org/latest/specification
- NIST AI RMF: https://www.nist.gov/itl/ai-risk-management-framework
- ISO/IEC 42001: https://www.iso.org/standard/42001
- EU AI Act overview: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
- OWASP Agentic Top 10: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/