# Standards, Specifications, and Governance Frameworks for AI Agents

**Research memo — current as of 15 September 2026**

## Executive conclusion

The market has many useful layers but no complete agent-governance standard. Laws and management frameworks govern organizations and AI systems; identity standards authenticate workloads and delegate API access; MCP and A2A standardize tool and agent communication; policy engines enforce local rules; observability and supply-chain specifications record selected facts. None provides an interoperable, end-to-end control plane that binds a human or organizational mandate to a particular agent instance, constrains recursive delegation, authorizes each consequential action, and produces portable, tamper-evident evidence of intent, policy, execution, and outcome.

For an enterprise governance architecture, the practical approach is compositional:

1. use the EU AI Act and sector rules as legal obligations, and ISO/IEC 42001 or NIST AI RMF as the governance spine;
2. assign workload identity with SPIFFE/OIDC and represent delegation with OAuth token exchange, Rich Authorization Requests, or GNAP where applicable;
3. put an executable policy decision/enforcement point in front of every tool, API, agent-to-agent, and computer-use boundary;
4. emit correlated OpenTelemetry data plus signed action receipts and software/model provenance; and
5. preserve human approval, policy decision, credential scope, model/tool version, inputs, outputs, and external effects as evidence.

The distinction matters: a **normative framework** states what an organization or implementation should/must do; **executable tooling** can evaluate, enforce, or verify a machine-readable rule or artifact. A framework does not become continuous enforcement merely because a product maps controls to it, and telemetry does not become audit evidence merely because it is retained.

## 1. Regulatory and risk-governance layer

| Instrument | Status and scope | Normative or executable? | Relevance and limit for agents |
|---|---|---|---|
| **EU AI Act, Regulation (EU) 2024/1689, as amended by the 2026 AI Omnibus** | Binding EU law using a risk-tiered model. The Commission states that GPAI rules have applied since August 2025, transparency rules apply from August 2026, specified stand-alone high-risk use cases from 2 December 2027, and high-risk systems embedded in regulated products from 2 August 2028. High-risk duties include risk management, logging, documentation, human oversight, accuracy, robustness, cybersecurity, and post-market monitoring. [Commission overview](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai); [legal text](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689). | **Normative and legally enforceable**, not an enforcement engine. | Applies based on the AI system, role, use case, and risk—not because software is called an “agent.” Its logging, oversight, technical-documentation, and incident duties are an important control baseline, but it does not define a portable agent identity, delegation token, or action-receipt format. |
| **NIST AI Risk Management Framework 1.0 and GenAI Profile (NIST AI 600-1)** | Voluntary, cross-sector risk framework organized around **Govern, Map, Measure, Manage**; the GenAI profile adds generative-AI risks and actions. [AI RMF](https://www.nist.gov/itl/ai-risk-management-framework); [GenAI Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence). | **Normative guidance**, voluntary; profiles and playbooks are not runtime controls. | Strong organizational vocabulary and lifecycle structure. It must be translated into system-specific controls, tests, policy rules, evidence, and owners. It is not agent-specific authorization or protocol governance. |
| **NIST AI Agent Standards Initiative (2026)** | A standards-coordination, gap-analysis, open-protocol, identity research, and evaluation program. NIST explicitly describes voluntary guidelines and industry-led standards work. [Initiative](https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative); [NCCoE agent identity concept paper](https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization). | **Program and draft work**, not yet a control standard or implementation. | Strategically important because it targets secure interoperability and agent authentication/identity. It confirms that agent identity and authorization remain an active standardization gap rather than a solved layer. |
| **NIST Cybersecurity Framework 2.0 and draft Cyber AI Profile (NIST IR 8596)** | CSF 2.0 is voluntary cybersecurity risk guidance; the Cyber AI Profile was still an initial preliminary draft and covers securing AI, using AI for defense, and thwarting AI-enabled attacks. [CSF 2.0](https://www.nist.gov/cyberframework); [NIST IR 8596 draft](https://csrc.nist.gov/pubs/ir/8596/iprd). | **Normative guidance**; machine implementation requires a control catalog and policy/evidence layer. | Useful bridge between AI governance and cybersecurity. Draft status means it should not be represented as a final agent standard. |
| **ISO/IEC 42001:2023** | Published international requirements standard for establishing, operating, maintaining, and continually improving an AI management system using a Plan-Do-Check-Act approach. [ISO](https://www.iso.org/standard/42001). | **Normative management-system requirements**, auditable/certifiable through conformity-assessment arrangements; not executable policy. | Best candidate for an enterprise AI-governance spine. It governs organizational processes rather than defining per-action technical enforcement for agents. |
| **ISO/IEC 23894:2023; ISO/IEC 42005:2025; ISO/IEC 5338:2023; ISO/IEC 25059:2023** | Respectively: AI risk-management guidance; AI system impact-assessment guidance; AI lifecycle processes; and an AI-system quality model. [23894](https://www.iso.org/standard/77304.html), [42005](https://www.iso.org/standard/42005), [5338](https://www.iso.org/standard/81118.html), [25059](https://www.iso.org/standard/80655.html). | **Normative guidance/specifications**, primarily documentary and process-oriented. | Together they cover impact, lifecycle, and quality better than a single agent checklist. They do not specify agent delegation, inter-agent trust, or a runtime evidence envelope. |
| **IEEE/ISO/IEC 24748-7000:2022** | Active international standard defining processes for addressing ethical concerns and tracing values into requirements and design. [IEEE](https://standards.ieee.org/ieee/24748-7000/11098). | **Normative process standard**, not executable. | Useful for value-sensitive requirements and stakeholder traceability, but not operational authorization. |
| **OWASP Top 10 for Agentic Applications 2026; OWASP LLM Top 10 2026; MITRE ATLAS** | Community risk taxonomies and threat knowledge. OWASP’s agent list includes agent-specific attack classes such as goal hijacking; ATLAS is a living knowledge base of tactics and techniques against or using AI. [OWASP Agentic Top 10](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/), [OWASP LLM Top 10](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/), [MITRE ATLAS](https://atlas.mitre.org/). | **Normative/advisory taxonomies**, not compliance standards or enforcement engines. | Valuable for threat modeling, red-team coverage, and control testing. A “Top 10 compliant” claim is weaker than evidence that controls were implemented and tested. |
| **CSA AI Controls Matrix (AICM) v1.1 and Cloud Controls Matrix (CCM) v4.1** | AICM is a vendor-neutral cloud-AI control framework with 247 objectives across 18 domains and is a superset of CCM v4.1; CCM assigns cloud provider/customer responsibilities and supports CSA STAR assurance. [AICM v1.1](https://cloudsecurityalliance.org/artifacts/ai-controls-matrix-v1-1), [CCM](https://cloudsecurityalliance.org/research/cloud-controls-matrix). | **Normative control catalogs and assurance mappings**, not runtime enforcement. | Strong for cloud/shared-responsibility control coverage. Agent-action enforcement and evidence still require technical implementation. |
| **U.S. interagency model-risk guidance SR 26-2 / OCC Bulletin 2026-13** | Replaced SR 11-7 in April 2026. It retains risk-based model development, validation, monitoring, governance, and third-party principles, while expressly stating that it is non-enforceable guidance; the OCC notes novel generative and agentic AI models. [Federal Reserve SR 26-2](https://federalreserve.gov/supervisionreg/srletters/SR2602.pdf), [guidance attachment](https://federalreserve.gov/supervisionreg/srletters/SR2602a1.pdf), [OCC release](https://occ.treas.gov/news-issuances/news-releases/2026/nr-occ-2026-29.html). | **Sector supervisory guidance**, not executable and not a general AI standard. | Important for banks: independent validation, inventory, change control, monitoring, and vendor governance should cover agentic models where material. It does not define agent identity or action authorization. |

## 2. Agent identity, delegation, and authorization

### Mature building blocks

- **OAuth 2.0 Token Exchange (RFC 8693)** standardizes security-token exchange, including impersonation and delegation across domains. [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693)
- **OAuth 2.0 Rich Authorization Requests (RFC 9396)** carries structured, fine-grained `authorization_details`, which is better suited than flat scopes to transaction-specific constraints. [RFC 9396](https://www.rfc-editor.org/rfc/rfc9396)
- **GNAP (RFC 9635)** standardizes negotiation and delegation of authorization to software, including APIs and subject information. [RFC 9635](https://www.rfc-editor.org/rfc/rfc9635)
- **DPoP (RFC 9449)** sender-constrains OAuth tokens to reduce replay; **Shared Signals Framework 1.0/CAEP 1.0** carries continuous risk and access-change events. [DPoP](https://www.rfc-editor.org/rfc/rfc9449), [SSF](https://openid.net/specs/openid-sharedsignals-framework-1_0-final.html), [CAEP](https://openid.net/specs/openid-caep-1_0-final.html)
- **SPIFFE** defines workload identities and SVID credentials for dynamic infrastructure; **SPIRE** is its executable reference implementation. [SPIFFE overview](https://spiffe.io/docs/latest/spiffe-about/overview/), [ecosystem/SPIRE](https://spiffe.io/docs/latest/spiffe-about/ecosystem/)
- **W3C Verifiable Credentials Data Model 2.0** is a Recommendation for tamper-evident issuer-holder-verifier claims. It can carry qualifications, organizational assertions, or mandates, but it does not by itself define agent authorization semantics. [W3C VC 2.0](https://www.w3.org/TR/vc-data-model-2.0/)
- **OpenID AuthZEN Authorization API 1.0** standardizes the interface between a policy enforcement point (PEP) and policy decision point (PDP), while deliberately leaving policy language and state management out of scope. [AuthZEN 1.0](https://openid.net/specs/authorization-api-1_0.html)

These are **normative technical specifications**. They become executable only through implementations such as an authorization server, SPIRE, PDP/PEP, credential verifier, or token service.

### What remains agent-specific and immature

The OpenID Foundation’s 2025 agentic identity white paper concludes that existing OAuth patterns work for simpler single-domain, synchronous cases but identify gaps in cross-domain/asynchronous operation, explicit on-behalf-of identity, recursive delegation, multi-user agents, consent fatigue, browser/computer-use agents, and continuous verification. [OpenID white paper](https://openid.net/wp-content/uploads/2025/10/Identity-Management-for-Agentic-AI.pdf)

NIST’s 2026 NCCoE paper is still a **concept paper for a potential demonstration project**, not an issued architecture. Several IETF documents on agent identity and authorization—including an agent identity framework, OpenA2A Agent Authorization Protocol, and authorization-integration framework—were Internet-Drafts in 2026, not IETF standards. [IETF agent identity draft](https://datatracker.ietf.org/doc/html/draft-sharif-agent-identity-framework-00), [OpenA2A AAP draft](https://datatracker.ietf.org/doc/html/draft-fane-opena2a-aap-00), [authorization integration draft](https://datatracker.ietf.org/doc/html/draft-liu-ai-agent-authorization-integration-00). Internet-Drafts are proposals and must not be treated as stable standards.

## 3. Agent protocol security and governance

### Model Context Protocol (MCP)

MCP standardizes the host/client/server interaction that exposes tools, resources, and prompts. The current 28 July 2026 authorization specification uses OAuth-based discovery, client registration, resource indicators, issuer validation, scope challenges, and step-up authorization for HTTP transport. However, authorization remains **optional for MCP implementations**; STDIO implementations are directed to obtain credentials from the environment rather than use the HTTP authorization profile. The security guidance forbids token passthrough and covers confused-deputy attacks, SSRF, audience binding, token theft, and scope minimization. [MCP authorization](https://modelcontextprotocol.io/specification/latest/basic/authorization), [MCP security guidance](https://modelcontextprotocol.io/specification/latest/basic/security_best_practices)

MCP is therefore a **normative protocol specification with SDKs/servers as executable implementations**, not a governance framework. It does not decide whether a requested tool action is lawful, safe, within a user’s mandate, or adequately evidenced. Local/STDIO credential handling also leaves a material enforcement boundary outside the protocol.

MCP moved into the Linux Foundation’s Agentic AI Foundation (AAIF) in December 2025, giving the project neutral open-source governance alongside goose and AGENTS.md. [Linux Foundation announcement](https://linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation)

### Agent2Agent (A2A)

A2A 1.0 standardizes agent discovery through Agent Cards, messages, stateful tasks, streaming, push notifications, and multiple bindings. It treats agents as enterprise applications: Agent Cards declare security schemes; credentials are acquired out of band; server authorization remains implementation-specific. Agent Cards may carry JWS signatures, but signing is optional. Most importantly, A2A’s in-task authorization state does **not** define the scope, representation, validity, or revocation semantics of the resulting authorization, although it permits authorization requests to propagate through task chains. [A2A specification](https://a2a-protocol.org/latest/specification)

A2A is a **normative interoperability protocol and SDK ecosystem**, not a complete trust/delegation standard. Google contributed it to the Linux Foundation in June 2025 for vendor-neutral project governance. [Linux Foundation announcement](https://www.linuxfoundation.org/press/linux-foundation-launches-the-agent2agent-protocol-project-to-enable-secure-intelligent-communication-between-ai-agents). Its deliberate reliance on external identity and authorization leaves cross-organization trust, scope attenuation, revocation, and accountable recursive delegation unresolved.

### Discovery/schema initiatives

The AGNTCY **Open Agentic Schema Framework (OASF)** defines machine-readable agent metadata, capabilities, and relationships, with validation tooling; its directory uses content-addressed records. [OASF](https://docs.agntcy.org/oasf/open-agentic-schema-framework), [record validation](https://docs.agntcy.org/dir/records-validation). This is useful executable schema infrastructure, but a validated record proves schema conformance—not that capability claims are true, safe, currently authorized, or independently certified.

## 4. Audit, evidence, provenance, and assurance

| Standard/tool | Type | Agent-governance use and boundary |
|---|---|---|
| **NIST SP 800-53 Rev. 5** | Normative security/privacy control catalog. [Source](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) | Audit/accountability, identity, access control, system integrity, assessment, and supply-chain families provide control requirements. They do not define an agent event schema. |
| **OSCAL** | Machine-readable NIST models and schemas in JSON/XML/YAML. [Source](https://pages.nist.gov/OSCAL/) | Makes catalogs, profiles, implementations, assessments, and results exchangeable. It is executable data plumbing for compliance automation, not proof that a control operated effectively. |
| **OpenTelemetry (OTel)** | Normative telemetry specification plus executable SDKs, Collector, and exporters. [Specification](https://opentelemetry.io/docs/specs/otel/) | Correlated traces, metrics, and logs are a practical substrate. GenAI/agent semantic conventions remain in a separately evolving repository, so cross-vendor semantic stability is not yet equivalent to an audit standard. [GenAI conventions notice](https://opentelemetry.io/docs/specs/semconv/gen-ai/) |
| **W3C PROV-O** | W3C Recommendation for provenance representation. [Source](https://www.w3.org/TR/prov-o/) | Can model entities, activities, agents, derivation, attribution, and delegation. It does not prescribe signatures, retention, authorization semantics, or mandatory agent fields. |
| **in-toto Attestation / SLSA v1.2** | Normative artifact-attestation and software supply-chain specifications with executable producers/verifiers. [in-toto](https://in-toto.io/Statement/v1), [SLSA](https://slsa.dev/spec/v1.2/) | Strong for proving how deployable artifacts were built. They do not natively prove why an agent took a runtime action or that the action stayed within a mandate. |
| **CycloneDX AI/ML-BOM; SPDX 3.0.1 AI and Dataset profiles** | Machine-readable BOM specifications with tooling. [CycloneDX](https://cyclonedx.org/capabilities/mlbom/), [SPDX AI profile](https://spdx.github.io/spdx-spec/v3.0.1/model/AI/AI/) | Inventory models, datasets, configurations, dependencies, and provenance. BOM completeness and runtime binding remain implementation responsibilities. |
| **Sigstore/Rekor** | Executable signing and append-only transparency-log tooling. [Overview](https://docs.sigstore.dev/), [security model](https://docs.sigstore.dev/security/) | Useful for signing software, policies, Agent Cards, or receipts and making signing events auditable. A valid signature proves integrity and signer control, not semantic truth or authorization. |
| **IETF RATS / Entity Attestation Token** | RATS architecture is Informational; EAT (RFC 9711) is Standards Track. [RATS](https://www.rfc-editor.org/rfc/rfc9334), [EAT](https://www.rfc-editor.org/rfc/rfc9711) | Can convey evidence about a workload/runtime state to a relying party. It does not attest model intent, correctness, or compliance with a user mandate. |
| **C2PA** | Normative content-provenance technical specification with implementations. [Specification](https://c2pa.org/specifications/specifications/2.0/specs/C2PA_Specification.html) | Appropriate for provenance of media generated or transformed by agents. It is not a general action ledger. |
| **SCITT architecture and AI-agent action-receipt profile** | IETF work in progress, not RFCs as of the memo date. [SCITT architecture draft](https://www.ietf.org/archive/id/draft-ietf-scitt-architecture-08.html), [agent receipt draft](https://www.ietf.org/archive/id/draft-noa-scitt-ai-agent-receipt-00.html) | Directly targets signed, tamper-evident agent action receipts, making it strategically relevant. Draft status and ecosystem maturity preclude treating it as a settled interoperability standard. |

The central audit lesson is that **observability, provenance, attestation, and audit are related but different**. OTel says what instrumentation observed; provenance says how artifacts or data relate; attestation binds signed claims; audit evidence must additionally establish control objective, actor, authorization, time, integrity, completeness, and reviewability.

## 5. Cloud-native executable policy standards and tools

- **Open Policy Agent (OPA)/Rego** is a general-purpose, declarative policy engine that accepts structured input and returns decisions. [OPA](https://www.openpolicyagent.org/docs/latest/)
- **OpenID AuthZEN** standardizes PEP-to-PDP calls, allowing an agent gateway to avoid coupling to one policy language or vendor. [AuthZEN](https://openid.net/specs/authorization-api-1_0.html)
- **Cedar** is an open-source authorization policy language and evaluation specification for principal-action-resource-context decisions, with analyzability and a production engine. [Cedar](https://www.cedarpolicy.com/)
- **Kubernetes ValidatingAdmissionPolicy** executes CEL expressions in-process at Kubernetes admission. [Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/)
- **Gatekeeper** executes OPA policies for Kubernetes validation/mutation and audit; **Kyverno** executes Kubernetes-native policies and produces policy reports. [Gatekeeper](https://open-policy-agent.github.io/gatekeeper/website/docs/), [Kyverno](https://kyverno.io/docs/introduction/how-kyverno-works/)

These are **executable policy mechanisms**, not agent-governance standards. They can enforce limits only at instrumented PEPs and only when supplied trustworthy context. Kubernetes admission governs deployment/configuration, not each runtime tool call. OPA or Cedar can decide an action, but neither provides the missing agent identity, delegation chain, user intent, risk classification, or evidence fields automatically.

## 6. Market gaps

1. **No canonical agent principal and mandate.** SPIFFE identifies a workload; OAuth identifies a client, subject, token, and scopes; A2A describes an agent; none universally binds operator, owner, software/model version, runtime instance, represented user or team, purpose, allowed effects, and expiry in one verifiable object.

2. **No mature recursive delegation standard.** RFC 8693 and GNAP supply powerful primitives, but agent-to-agent chains need monotonic scope attenuation, task/purpose binding, hop limits, downstream disclosure, revocation propagation, and accountability. The most direct agent proposals remain drafts.

3. **Protocol-level security is not semantic authorization.** MCP protects transport/API access but does not determine whether a particular tool call matches the user’s intent. A2A explicitly leaves authorization policy and in-task authorization semantics to implementations. Computer-use agents can bypass API PEPs entirely.

4. **Discovery claims lack a common trust and assurance model.** A2A signatures are optional; OASF validates structure. There is no widely adopted federation for independent capability certification, safety posture, policy compatibility, incident history, current revocation, and signer trust.

5. **No settled, portable agent action receipt.** The market lacks a broadly implemented schema that binds request and interpreted intent; principal and delegation chain; input/output hashes; policy and decision; model, prompt, tool and environment versions; approvals; external side effects; timestamps; and cryptographic integrity. SCITT’s agent profile is promising but still draft.

6. **Telemetry is not yet audit-grade by default.** OTel provides transport and correlation, but agent semantic conventions are evolving, sensitive prompts complicate retention, sampling can destroy completeness, and ordinary logs lack non-repudiation and independent time/integrity proofs.

7. **Textual-control-to-runtime gap.** EU, NIST, ISO, OWASP, MITRE, and CSA provide obligations, processes, or risk taxonomies. There is no standard compiler that converts them into portable OPA/Cedar/CEL policies, test cases, and evidence requirements without organization-specific interpretation.

8. **Nondeterministic behavior assurance remains weak.** Conventional IAM answers whether a principal may call an operation; it does not verify whether an agent’s evolving plan remains aligned with intent. Continuous behavioral evaluation, policy-aware planning, simulation, canarying, and rollback are not standardized across runtimes.

9. **Long-running and asynchronous control is incomplete.** Agent tasks may outlive user sessions and access-state changes. Standards exist for risk signals and token revocation patterns, but durable consent, mid-task reauthorization, checkpoint approval, cancellation propagation, and post-revocation compensation are not consistently defined across MCP/A2A ecosystems.

10. **Assurance claims are fragmented.** ISO 42001 certification, SOC-style attestations, CSA STAR, OWASP mappings, model validation, red-team results, and protocol conformance answer different questions. The market lacks an agent-specific assurance profile that tests both organizational governance and enforceable per-action controls.

## 7. Implication for an agent-governance control plane

A credible control plane should not invent replacements for these standards. It should normalize and bind them:

- a stable agent/workload identity plus explicit human or organizational delegation;
- a canonical action request (`principal`, `on_behalf_of`, delegation path, purpose, action, resource, context, risk, expiry);
- PDP/PEP enforcement at every consequential boundary, using AuthZEN with OPA/Cedar or equivalent;
- policy versioning and control mappings to EU/NIST/ISO/CSA requirements;
- short-lived, audience-bound credentials and step-up approval for high-risk effects;
- correlated runtime telemetry and a signed, append-only action receipt;
- model/tool/data/component inventory tied to the exact runtime execution; and
- continuous evaluation, revocation, incident response, and evidence export through formats such as OSCAL, in-toto/SLSA, CycloneDX/SPDX, and emerging SCITT profiles.

This composition is implementable now. The principal product opportunity is the missing binding layer between governance intent, identity/delegation, protocol operations, executable policy, and audit-grade evidence.