[RFC] Agent Credentials

[benhylau]

Agent Credentials

Authors:

• @benhylau – Benedict Lau, EQTY Lab
• @ksingh299 – Kapil Singh, IBM
• @imran-siddique - Imran Siddique, Microsoft
• @akolekar-zs - Abhijeet Kolekar , Zscaler
• @rithikha - Rithikha Rajamohan, EQTY Lab
• Sarah Evans, Dell/AGNTCY
• Teryl Taylor, IBM
• Poorna Rajaraman, Cisco

Summary

AI agents need a portable, verifiable way to present claims about themselves — identity, capabilities, security posture, runtime context — so that gateways, policy enforcement points, and other agents can make access-control and delegation decisions. Today, claims are expressed inconsistently across packaging formats (W3C Verifiable Credentials, JWTs), with different identifiers (X.509, SPIFFE/SVIDs, DIDs), and credential schemas (OASF, Agent Card, attestation evidence), and there is no shared classification of what kinds of credentials exist or how they relate. This forces every issuer and verifier into bespoke integrations and blocks cross-enterprise interoperability.

The CoSAI Agentic Identity and Access Management paper addresses agent identity and access to resources. In 3.1 Agents as first-class identities, it provides a high level purpose for these agent credentials:

[...] each agent MAY carry a set of informational attributes as claims that
inform access-control decisions. These claims encompass:

• Static attributes: code hash, model version, toolset, skill set, knowledge bases, and configuration parameters.
• Dynamic context: operating environment, current task, in-memory state, risk tier, and behavioral state.
• Delegation information: the principal on whose behalf the agent acts and the scope of that delegation.
  Enterprise policies MAY designate certain claims as mandatory.

This proposal builds upon the description of "claims that inform access-control decisions" through further specification, covering the following.

Definitions & Classification

• Agent credential vs. agentic credentials / access credentials
• Long-term vs. short-lived credentials
  • How often shall we refresh different types of credentials
  • Who should host revocation servers
  • Scaling of credential management
• Public vs. secret credentials, including selective disclosure features
• Requirements and recommendation around credential attributes
• Claim vs. Credential (signed claim)
• Taxonomy of agent credentials
  • Agent metadata
  • Ownership
  • Capabilities
  • Software
  • Configurations
  • Tools/Skills
  • Security clearance (e.g. malware scan)
  • Policy compliance (e.g. HIPAA, CoSAI AI RMF)
  • Runtime environment
  • How environment measurements & attestations (e.g. from TDX) relate to this type of credential
  • Intent
  • Risk/Trust evaluation score
    • SLSA Security Levels
    • Reversing Labs SAFE Level
• Existing standards for each layer
  • Agent identity (X.509, SPIFFE/SVID, DID)
  • Identifier for components (e.g. Model Signing for model version, hash of toolset, skill set, knowledge bases configuration parameters)
  • Credential packaging formats (W3C Verifiable Credentials, JWTs)
  • Common credential claim schema (e.g. OASF, EQTY Governance Schema)

Use Cases & Threat Models

• Describe common agent deployment patterns and identify gaps that agent credentials address
  • Agent-to-agent vs. other scenarios, how are credentials passed around
  • Multiple IdPs and other distributed approaches
  • MCP tool use and guidelines for identity use
  • Scenarios where a security scan makes a claim that an agent passed the vulnerability scan with its software image
• Validation flow at enforcement points with sample policies (e.g. CoSAI Agentic Identity and Access Management – F. Gateway and web ecosystem patterns)
• Cover topics including
  • Credential binding
  • Issuers and delegation chaining
  • Task scoped & attenuated scope
  • Runtime bound
  • Policy bound
  • Proof of possession
  • Revocation
• How to link agent with its operating environment and software image through credentials
• Relation to OpenID Connect and Oauth2 Token Exchange (RFC 8693), RFC 9396, RFC 9449 , RFC 8705
• Interoperations and portability (e.g. SPIFFE federation, DID, WIMSE)

The output of this project is a classification system for agent credentials, a description of each layer and standards available, and reference architectures and implementations for agent credential use cases.

Priority

• P0: This is critical to include in the next release from this workstream.
• P1: This is important to include in the next release from this workstream.
• P2: This is nice to have, but can wait until a future release.

Level of Effort

• Small: This will take a few days to document.
• Medium: This will take a week or two to document.
• Large: This will take several weeks to document.

Drawbacks

Some of the classification and definition work may be opinionated, because we are proposing a level of definition that would allow us to build interoperable reference systems. For example, while the Verifiable Credential specification allows portability of a credential, an enforcement point cannot make assumptions about the schema of the claim in the “credentialSubject”.

This paper will select use cases and draft claim schemas to enable the use cases.

Alternatives

Without standardization around agent credentials, we risk:

• Inconsistent definitions and classifications of agent credentials
• Lack of recommendations around lifecycle management (long-term vs. short-lived) and scope, so issuers have too many options to choose from, and validators (e.g. enforcement gateways) have no common set of expectations from clients
• A fragmented agent credential ecosystem

Reference Material & Prior Art

There are specifications for some of the use cases.

• Metadata: Google Agent Card
• Capability: AGNTCY OASF Agent Badge
• Compliance: EQTY Lab Compliance Credential
• Environment: EQTY Lab Environment Credential

Unresolved questions

1. When you think about the term Agent Credentials, are there aspects that are not covered in the current RFC. Are there things that you feel are out of scope?

2. Are there established or emerging standards, reference material or prior art, you are aware of that has not been mentioned in this RFC?

3. Do you have an interest in the outcome of this group? For example, you or your company is building a credential issuance system, or an enforcement engine that would accept agent credentials.

[sarahnovotny]

@benhylau from our previous meetings. and for your consideration working through this RFC - #47 #48 #49

[imran-siddique]

Great RFC — agent credentials are one of the missing pieces for cross-enterprise agent interoperability. A few thoughts on the unresolved questions:

Prior art not yet cited:

The Agent Governance Toolkit (AGT) implements several patterns directly relevant to this RFC at the runtime enforcement layer:

• Agent identity via SPIFFE SVIDs — each agent gets a verifiable SPIFFE identity bound to its runtime environment, used for mTLS in agent-to-agent communication
• Policy compliance credentials — runtime policy evaluation results (OPA/Rego-based) that could be packaged as verifiable claims
• Delegation chain tracking — cryptographically linked delegation records capturing who authorized what, with attenuation at each hop
• Tamper-evident audit logs — hash-chained event logs that serve as evidence of agent behavior, useful as input to trust/risk scoring
• MCP Security Gateway — an enforcement point that validates agent identity and policy compliance before tool invocation, relevant to the "validation flow at enforcement points" section

These are runtime-level implementations, but the credential schemas and lifecycle patterns may be useful reference material for the classification work.

Gaps / suggestions:

1. Confidential computing attestation as a credential layer — the taxonomy mentions "environment measurements & attestations (e.g. from TDX)" but this deserves deeper treatment. Hardware attestation (TDX, SEV-SNP, SGX) can provide a root of trust that binds agent identity to a verified execution environment. This is especially relevant for multi-party agent scenarios where no single party controls the infrastructure.

2. Credential lifecycle in delegation chains — when Agent A delegates to Agent B, how are credentials attenuated, and what's the revocation model for delegated credentials? AGT's delegation chain model tracks this but doesn't yet use VCs as the packaging format.

3. Runtime behavioral credentials — the taxonomy covers static attributes and security clearance, but runtime behavioral claims (e.g., "this agent has maintained a 99.5% policy compliance rate over the last 7 days") could be a distinct credential type worth classifying. These are dynamic, time-bounded, and useful for progressive trust establishment.

Interest: Yes — I'm working on confidential computing platforms for AI workloads, where hardware-attested agent credentials are a core building block. Happy to contribute to the reference architecture work, particularly around TEE attestation integration and credential binding to confidential execution environments.

[billbrietstout]

One of the problems we saw at a large SaaS company was the inability to invalidate credentials held by the agent. Say you integrated a SaaS app to Azure (Microsoft Entra), your SaaS agent stores a private key which is not frequently rotated. That expands the trust domain, and creates a juicy target for hackers.

The fundamental problem applies to all agents: agent shares a trust boundary with every secret stored on the system

Credentials should never be stored within the agent, there should be a separate secret storage from agent execution.

Challenges to consider:

• Refresh token race conditions are catastrophic for agents because in a shared secret environment someone is going to hold a stale
• Agents persist longer than the credential rotation window

[benhylau]

This NVIDIA agent capabilities certificate is what I would consider a "Skill Credential". An agent should be able to present to another party that it (1) has the skill (2) is using this skill as part of this session. The NVIDIA signer of the certificate is a skill credential https://docs.nvidia.com/skills/signing-agent-skills/#signature-layout

[douglasborthwick-crypto]

A useful classification to pin down.

On unresolved question 2 and the taxonomy: most of the classes describe attributes an agent asserts about itself — capabilities, software, configuration, scanner results, runtime measurements. Your taxonomy has an Ownership cell, but the cells are all framed as credentials the agent packages and carries. There's an adjacent shape none of them capture: a verifiable claim about the agent's external on-chain state — e.g. "the wallet this agent controls satisfies condition X" (funded ≥ a threshold, holds a specific NFT, carries a given EAS attestation). In agent-to-agent commerce that's frequently a decisive access-control input, and it's neither a self-asserted attribute nor a scanner verdict.

It's worth distinguishing as its own shape, because it sidesteps the problem @billbrietstout raised. Rather than the agent holding a long-lived credential it must store, refresh, and revoke, an issuer reads the external state, evaluates it against an explicit condition, and returns a per-request signed boolean — met: true/false plus a hash of the condition evaluated, signed ECDSA P-256, verifiable offline against a published JWKS. Nothing is stored on the agent, so there's nothing on the agent to invalidate or steal; freshness is a TTL on the attestation, not a revocation server. It maps onto your proof-of-possession / runtime-bound / short-lived axes, but the claim source is external state, not the agent's own assertions.

Prior art for the question-2 list: there's an IETF individual submission specifically on this shape — draft-borthwick-wallet-state-attestation-00, "Signed Booleans about On-Chain State." On question 3: I issue this attestation type today (P-256, public JWKS, 37 chains), so the interest is as an issuer of this claim shape — not an enforcement engine; the access decision stays with the relying party. I'd flag it mainly so the classification leaves room for read-at-decision-time state claims alongside the carried-credential cells, rather than collapsing everything into the VC/JWT packaging model.

Douglas

[Mayur021]

Hi all, joined CoSAI WS4 earlier this week and reviewing the Agent Credentials RFC alongside the June 4 triage. Sharing architectural context relevant to Section 5 (Credential lifecycle & enforcement).

Convergent prior-art landscape:

OWASP AISVS C9.2.6 + C9.2.7 (proposed for v1.01, merged in C09 research chapter) names a verification-side primitive: manifest-declared action class evaluated by a deterministic gate, with the chain's worst-case action class governing composed multi-step sequences.

CSA NHI v1.0 peer review surfaced a 6-property chain-level audit schema, proposed jointly with Mallikarjunarao Sunke: chain id linking composed steps, declared worst-case action class at chain start, gate decision and justification, per-step API record, originating principal, and immutability of the originating principal.

Related work by other contributors: AARM (Jason Keirstead, moving to CSA), ILION Gate + SRM (Adrian Chitan, arXiv 2603.13247 and 2603.22350), AuthR v0.1 (Steve Tout), ZeroID (Kunal Kumar), NSA AISC CSI on MCP Security, NIST NCCoE concept paper on AI Agent Identity and Authorization, 5 Eyes guidance on Careful Adoption of Agentic AI Services, arXiv 2605.18991 Agent Security is a Systems Problem.

Adjacent WS4 surfaces with overlapping architectural concerns: Issue #61 Per-Decision Accountability (Y.C. Chang's Evidence Pack pattern), PR #91 AI Gateways Design (Gheorghina, enforcement-point patterns).

Three Section 5 sub-components with direct prior-art mappings worth flagging:

1. Capability attenuation (scoping sub-agent to subset of capabilities) maps to AISVS C9.2.7 worst-case action class chain rule.

2. Validation flow at enforcement points with sample policies (CoSAI Agentic IAM Section F gateway and web ecosystem patterns) maps to AISVS C9.2.6 deterministic gate at chain start.

3. Attestation guarantee, trust score, and acceptance threshold at the decision point maps to the 6-property gate decision and justification field.

On the RFC questions:

Aspects not covered in the current RFC: chain-level audit schema for composed-action authorization, worst-case action class chain rule, originating principal immutability under agent-to-agent invocation, chain-id binding of the originating principal.

Standards and emerging prior art worth referencing: AARM, ILION Gate and SRM, AuthR v0.1, ZeroID, NSA AISC CSI on MCP Security, NIST NCCoE concept paper, 5 Eyes Careful Adoption of Agentic AI Services, arXiv Agent Security is a Systems Problem, Visa Trusted Agent Protocol, ERC-8004 (referenced in Agentic IAM Section F), WIMSE (Workload Identity in Multi-System Environment).

Interest in outcome: yes, as a vendor-neutral architectural contributor.

Happy to contribute cross-walk language to Section 5 sub-components if useful.