Aethyr Research — Comment on NCCoE Concept Paper: Software and AI Agent Identity and Authorization

Dear NCCoE Project Team,

Aethyr Research appreciates the opportunity to comment on the concept paper "Accelerating the Adoption of Software and AI Agent Identity and Authorization." We are an AI infrastructure company building a sovereign agent operating system with production post-quantum cryptographic identity for AI agents. Our comments below address each category of questions raised in the concept paper, informed by our experience building and deploying these systems.

We would welcome the opportunity to participate as a technology collaborator in the NCCoE demonstration project.

1. General Questions — Demonstration Use Case

What enterprise use-cases are organizations currently using agents for?

Our production deployments span field service management (81 MCP tools for job scheduling, estimation, and invoicing), CRM automation (53 tools for contact management, deal pipeline, and communication logging), and document intelligence (48 tools for semantic search across organizational knowledge bases). The common thread is agents operating across multiple enterprise systems on behalf of users, requiring delegated authority with auditability.

What risks worry you about agents?

Three risks dominate our conversations with enterprise customers:

1. Identity confusion — No reliable mechanism to distinguish agent actions from human actions in audit logs. When an agent creates a record in HubSpot or sends an email via Gmail, the audit trail shows a shared API key, not a specific agent identity.

2. Authority creep — Agents accumulate tool access over time without systematic review. An agent authorized to read a calendar gradually gains access to send emails, modify CRM records, and execute financial transactions — often through implicit permission inheritance rather than explicit grants.

3. Quantum vulnerability of credentials — Every agent identity system deployed today uses RSA or ECDSA signatures. CNSA 2.0 mandates post-quantum cryptography for all new national security systems by January 2027. Agent credentials issued on classical crypto today will need complete re-issuance when PQC mandates take effect, creating a costly and disruptive transition.

What support are you seeing for new protocols such as Model Context Protocol (MCP)?

We operate a production MCP server with 440+ tools across 14 enterprise integrations (HubSpot, Gmail, Google Calendar, Google Drive, ServiceTitan, SharePoint, Outlook, Zapier, and others). MCP is the de facto standard for agent-tool interaction. However, MCP currently relies on OAuth 2.0/OIDC for authorization, which presents two gaps:

• OAuth tokens are bearer tokens — they prove possession, not identity. An intercepted token grants full access regardless of the interceptor's identity.
• OAuth does not address post-quantum requirements. Token signatures use RSA or ECDSA, which are quantum-vulnerable.

We recommend the NCCoE project address how MCP authorization can be extended with verifiable agent credentials that are cryptographically bound to a specific agent identity.

In what ways do agentic architectures introduce identity and authorization challenges? How do AI agents differ from other forms of software agents? How are agentic architectures different from current microservices architectures?

AI agents differ from microservices in three ways that fundamentally change identity requirements:

1. Non-determinism. A microservice receives a request and produces a predictable response. An AI agent receives a goal and autonomously decides which tools to invoke, in what order, with what parameters. The action space is not known at deployment time — it emerges from the model's reasoning. This means static authorization policies (allowlists of endpoints) are insufficient. Authorization must be evaluated dynamically, per-invocation, against the agent's credential.

2. Dynamic tool acquisition. Microservices are deployed with a fixed set of capabilities. AI agents discover and acquire tools at runtime via protocols like MCP. An agent authorized for CRM operations may, mid-task, discover a financial tool and attempt to use it. Identity infrastructure must handle capability boundaries that shift during execution, not just at deployment.

3. Autonomy and chaining. A microservice executes a single operation and returns. An AI agent chains multiple operations across multiple systems in a single turn — read a calendar, draft an email, check CRM, send the email — with each step informed by the previous one's output. The identity system must maintain a coherent authorization context across this chain, not just verify a single request.

These differences mean that identity approaches designed for microservices (service mesh mTLS, SPIFFE/SPIRE workload identity) address the transport layer but not the authorization semantics. An agent needs both: a verifiable identity (who am I) and a verifiable set of capabilities (what am I allowed to do, as judged per-action).

What standards exist, or are emerging, to support identity and access management of agents?

We note a significant gap in the standards referenced in Section 2: none of them address post-quantum cryptography, and none reference W3C Decentralized Identifiers (DIDs) or Verifiable Credentials (VCs) as agent identity mechanisms.

We recommend adding:

• W3C Decentralized Identifiers (DID) v1.0 — Provides a framework for globally unique, self-sovereign identifiers that do not depend on a central registry
• W3C Verifiable Credentials Data Model 2.0 — Provides a standard format for cryptographically signed capability attestations that can be verified offline
• NIST FIPS 204 (ML-DSA) and NIST FIPS 203 (ML-KEM) — Post-quantum signature and key exchange algorithms that should be considered for agent credential issuance given CNSA 2.0 timelines

2. Identification

How might agents be identified in an enterprise architecture?

We have implemented and deployed agent identification using W3C Decentralized Identifiers (DIDs) with the following structure:

did:aethyr:<namespace>:<BLAKE3-hash-of-verifying-key>

Each agent receives a unique DID at registration, derived deterministically from a master seed using BLAKE3-KDF key derivation with domain-separated context strings. The DID identifier is the BLAKE3 hash of the agent's ML-DSA-65 verifying key, ensuring the identifier is cryptographically bound to the agent's signing capability.

What metadata is essential for an AI agent's identity?

Based on our production experience, the minimum viable agent identity metadata includes:

• DID — Globally unique identifier, cryptographically derived
• Verifying key — Public key for signature verification (1,952 bytes for ML-DSA-65)
• Capabilities — Explicit list of authorized operations (e.g., tool:hubspot_create_contact, data:read)
• Issuer — The organization that vouches for this agent
• Issuance date and expiration — Temporal validity bounds
• Proof — Cryptographic signature over the above, enabling offline verification

This metadata is packaged as a W3C Verifiable Credential, signed with ML-DSA-65 (NIST FIPS 204).

Should agent identity metadata be ephemeral or fixed?

Both. We use a key hierarchy with both permanent and ephemeral keys:

• Permanent: Identity key (m/0'), signing key (m/1'), DID key (m/2') — persist across sessions, define the agent
• Ephemeral: Session keys (m/4'/n) — per-connection, expire after 15 minutes, used for transport-level encryption

This mirrors how human identity works — your driver's license is permanent, but your session token is ephemeral.

Should agent identities be tied to specific hardware, software, or organizational boundaries?

We support agent migration between hardware nodes while preserving identity. An agent on a datacenter server can be serialized (including its cryptographic identity, capabilities, and cognitive state), transferred to an edge device, and restored — same DID, same credentials, same authorized capabilities. The identity is bound to the cryptographic key material, not to the hardware.

Organizational boundaries are enforced through the credential issuer chain. An agent's Verifiable Credential names the issuing organization. A receiving system verifies both the credential signature and the issuer's authority.

3. Authentication

What constitutes strong authentication for an AI agent?

We implement ML-DSA-65 (NIST FIPS 204) post-quantum digital signatures for agent authentication. Our benchmarks on commodity hardware:

• 9,700 verifications/second (ML-DSA-65)
• 36,940 key generations/second (ML-KEM-768)

An agent proves its identity by signing a challenge nonce with its private signing key. The verifier checks the signature against the agent's verifying key (published in its DID Document or Verifiable Credential). No network call to a central authority is required — verification is entirely offline.

This is critical for DDIL (Denied, Degraded, Intermittent, Limited) environments where agents must authenticate without connectivity to a central identity provider.

How do we handle key management for agents? Issuance, update, and revocation?

We use a BIP32-inspired key hierarchy derived from a single 256-bit master seed:

Master Seed (256-bit, encrypted at rest)
 ├── m/0' IDENTITY    (ML-DSA-65) — Root identity
 ├── m/1' SIGNING     (ML-DSA-65) — Action signatures
 ├── m/2' DID         (ML-DSA-65) — DID operations, VC signing
 ├── m/3' BACKUP      (ML-KEM-768) — Credential recovery
 └── m/4'/n SESSION   (ephemeral) — Per-connection keys

Key derivation uses BLAKE3-KDF with domain-separated context strings, ensuring cryptographic independence between key paths.

For key rotation, we implement KERI-style pre-rotation: at identity creation, a commitment to the next public key hash is made. When rotation occurs, the DID remains stable — the new key matches the pre-committed hash, providing cryptographic continuity without re-issuance of all credentials.

4. Authorization

How can zero-trust principles be applied to agent authorization?

We implement zero-trust authorization at two layers:

Credential-level (implemented in our verification library): Our open-source verification library (@aethyrai/ssi-verify) provides capability-based authorization using glob-pattern matching against Verifiable Credential claims:

Agent credential grants: ["tool:hubspot_*", "data:read"]
Agent requests: "tool:hubspot_create_contact"
Result: ALLOWED (glob match on "tool:hubspot_*")

Agent requests: "tool:stripe_charge"
Result: DENIED (no matching grant)

Execution-level (implemented in our agent platform): Every tool invocation passes through a four-tier execution gate based on operation classification:

No implicit permissions. No inheritance from the deploying user's permissions unless explicitly delegated through a consent flow.

Can authorization policies be dynamically updated when an agent's context changes? How do we determine sensitivity levels of data when aggregated by an agent?

Yes — and this is one of the most underappreciated risks in agentic systems. We implement an execution gate that re-evaluates authorization at every tool invocation, not just at session start:

• Execute-tier tools (read calendar, search knowledge base) proceed without additional confirmation beyond credential verification
• Propose-tier tools (create CRM record, modify document) trigger a confirmation check: the proposed action is presented to the user with full context of what the agent has accessed in the session so far, including whether the aggregated context elevates the data classification
• Preview-tier tools (delete records, destructive operations) require user review with full context before execution
• Block-tier operations are forbidden regardless of credentials or context

The key architectural decision: authorization is not a gate you pass once at the start of a session. It is a check that runs on every tool invocation. The execution tier is determined by the operation type, and propose/preview actions include the full session context for the human reviewer. An agent that was authorized for a tool at the start of a session may still require user confirmation if the operation classification warrants it.

How do we establish "least privilege" for an agent?

We implement four orchestration strategies that constrain agent tool access by phase:

In plan and deep strategies, the agent operates in read-only mode during exploration and planning phases. Write access is only granted during the execute phase, and only after the human has approved the plan. The agent cannot escalate from read-only to full access without transitioning through an explicit approval gate.

How might an agent convey the intent of its actions?

We implement a plan mode where agents generate a structured execution plan before taking any actions. The plan includes: which tools will be invoked, in what order, with what expected inputs, and toward what goal. This plan is presented to the authorizing human before any tool execution begins.

The plan serves two purposes for intent communication:

1. Pre-execution transparency. The human sees not just "the agent wants to send an email" but "the agent read the calendar, found a conflict, drafted a reschedule email, and wants to send it to these recipients for this reason." Intent is visible before the action occurs.

2. Post-execution auditability. The plan is persisted alongside the signed action records. Forensic review can compare what the agent planned to do versus what it actually did, identifying cases where the agent deviated from stated intent — which may indicate prompt injection, model hallucination, or authorization issues.

Plan mode is mandatory for high-risk actions. For low-risk actions, the agent can act autonomously but still logs its reasoning chain alongside each signed action.

How do we handle delegation of authority for "on behalf of" scenarios?

We implement an explicit delegation consent flow:

1. Agent requests delegation: "I need tool:gmail_send to reply to this thread"
2. Request is presented to the authorizing human with context (what capability, for which agent, why)
3. Human approves or denies
4. If approved, a grant is recorded with: capability, granting authority, timestamp, expiration
5. Full audit trail maintained — every delegation decision is logged

No implicit delegation. No background orchestration the user hasn't authorized. This is enforced architecturally, not by policy.

How do we bind agent identity with human identity to support "human-in-the-loop" authorizations?

We implement this at two levels today, and propose a third for the reference architecture:

Currently implemented — consent-based delegation: When an agent requires elevated capability, the system presents the request to the authorizing human with context (what capability, for which agent, why). The human approves or denies. If approved, a grant record is created with: capability, granting authority, timestamp, and expiration. Every delegation decision is logged in a persistent audit trail.

Currently implemented — agent credential binding: Each agent holds a W3C Verifiable Credential issued at registration that enumerates its authorized capabilities. The issuing organization is named in the credential. The credential is signed with ML-DSA-65 and can be verified offline.

Proposed for the reference architecture — cryptographic delegation grant: We believe the NCCoE demonstration should explore a two-credential model where human-to-agent delegation is itself a signed Verifiable Credential:

DelegationGrant {
    delegator_did: "did:aethyr:user:<human-hash>",
    delegatee_did: "did:aethyr:agent:<agent-hash>",
    capabilities: ["tool:gmail_send", "tool:hubspot_*"],
    purpose: "Reply to scheduling conflicts for Q2 planning",
    expires: "2026-04-01T18:00:00Z",
    signature: <delegator's ML-DSA-65 signature>
}

This would create a cryptographically verifiable chain: organization issues agent credential, human issues delegation grant, agent signs action. A verifying system could answer: "Was this agent authorized by this specific human, for this specific capability, at this specific time?" — with post-quantum non-repudiation at every link. We are actively developing this capability and would welcome the opportunity to demonstrate it as part of the NCCoE project.

5. Auditing and Non-Repudiation

How can we ensure that agents log their actions in a tamper-proof and verifiable manner?

Our SSI library provides infrastructure for signing individual agent actions with the agent's ML-DSA-65 signing key (m/1' path), producing non-repudiable records:

SignedAction {
    payload: <action data>,
    signature: <ML-DSA-65 signature, 3,309 bytes>,
    signer_did: "did:aethyr:agent:<hash>",
    timestamp: "2026-03-31T12:00:00Z"
}

The signing and verification functions (signAction, verifyAction) are implemented and exported from our SSI library. The signature is post-quantum — it cannot be forged even with a quantum computer. The signer's DID links the action to a specific agent identity. The Verifiable Credential links that identity to a specific deploying organization. Integration of per-action signing into the agent execution pipeline is in active development.

How do we ensure non-repudiation for agent actions?

Our architecture provides the building blocks for an unbroken non-repudiation chain:

1. Implemented: Deterministic key derivation from master seed (same seed = same keys = same DID)
2. Implemented: ML-DSA-65 signature infrastructure for actions (post-quantum non-repudiation) — signAction and verifyAction exported from our SSI library
3. Implemented: W3C Verifiable Credential binding agent to issuing organization, signed with ML-DSA-65
4. Implemented: Delegation audit trail linking authorization to human decision (consent flow with persistent logging)

When fully integrated, this creates a chain from human authorization to agent action to cryptographic proof. No entity in the chain can deny their participation. The individual components are production-ready; integration of per-action signing into the execution pipeline is in active development.

6. Prompt Injection Prevention and Mitigation

What controls help prevent both direct and indirect prompt injections?

While prompt injection is primarily a model-layer concern, identity infrastructure contributes to mitigation:

• Capability-scoped tool access — Even if an injection successfully hijacks agent reasoning, the agent can only invoke tools its credential authorizes. An injection cannot escalate privileges beyond the credential's grants.
• Action signing infrastructure — Our SSI library supports signing tool invocations with the agent's post-quantum key. When integrated into the execution pipeline, post-hoc forensic analysis can distinguish between authorized agent actions and injection-induced actions by examining the prompt chain that led to each signed action.
• Delegation consent — High-risk actions (sending emails, modifying records, executing transactions) require human-in-the-loop approval regardless of how the agent arrived at the decision. Injection cannot bypass the consent gate.

Offer to Participate

Aethyr Research offers the following as a potential technology collaborator:

1. Production PQC agent identity implementation — ML-DSA-65 signatures, ML-KEM-768 key exchange, BLAKE3-KDF key hierarchy. Open-source verification library (@aethyrai/ssi-verify) with minimal runtime dependencies (two audited cryptographic libraries: @noble/post-quantum and @noble/hashes).

2. W3C DID + VC 2.0 reference implementation — Agent registration, credential issuance, offline verification. TypeScript, Python, and Rust implementations with shared cryptographic specifications.

3. MCP integration — 440+ enterprise tools across 14 integrations with credential-aware execution. Demonstrates how agent identity maps to real-world tool access patterns.

4. DDIL/air-gapped deployment — Agent identity that works without network connectivity. Verification is entirely offline — critical for defense and regulated environments.

5. Published benchmarks — ML-DSA-65 at 9,700 verifications/second, ML-KEM-768 at 36,940 key generations/second on commodity hardware (Criterion.rs benchmarks, verified, reproducible).

We believe our implementation addresses several gaps in the current standards landscape referenced in the concept paper, particularly around post-quantum readiness and decentralized agent identity. We would welcome the opportunity to demonstrate our technology and contribute to the NCCoE project.

Respectfully submitted,

R. Demetri Vallejos CEO and Chief AI Officer Aethyr Research dvallejos@aethyrresearch.com Salt Lake City, UT