Design Tenets for Agent Identity Management Systems

Useful set, and tenet 02 already has a counterpart in a published standard. The tenet says scopes attenuate so downstream entities can never claim more authority than the parent. OWASP AISVS 9.5.7, version 1.01, level 2, requires that authority derived through delegation never exceeds the delegating agent's current authority. Same requirement, already written as a testable verification item. I contributed to C9, so treat that as a pointer rather than an independent citation.

Two neighbours in the same chapter have no counterpart among the ten. In version 1.0, 9.2.3 asks that each high-impact action carry a trusted reversibility classification, from read-only through irreversible, and 9.2.4 asks that the runtime enforce it by blocking, gating or restricting. Tenet 05 initiates human review when risk thresholds are reached, without saying what sets the threshold. Those two are one published answer, and there may well be better ones.

Thank you for this framework. One gap worth considering: tenets 2, 5 and 6 depend on the human at the root of the delegation chain to sign mandates and approve escalations. But today’s strongest human credentials, passkeys and device-bound keys, often live on the same device or browser where the agent runs. If an agent can reach the key that signs a mandate, the chain of trust ends at a device, not a person.

I’d suggest a complementary tenet: the human’s authority must not be reproducible by the agent. High-impact approvals should require a fresh human response, bound to the action, that nothing in the agent’s environment can generate. A separate device, out-of-band confirmation, or methods based on human memory could all meet it. It would also strengthen tenet 5’s point on consent fatigue.

Disclosure: I’m the founder of newauth, which works on human-centered authentication.

Thank you for these tenets. Tenets 6, 7, 8 and 10 are a useful anchor for teams working on agent controls in financial services.

One question we’d like to see covered as the series continues: what changes when the mandate issuer, the agent’s operator and the party enforcing the decision are different organisations? A common example is a consumer’s AI agent asking a bank to make a payment or change a limit. The bank doesn’t control the agent, can’t inspect its harness, and receives a mandate it didn’t issue.

In that setting, what should the receiving organisation rely on to decide whether an in-scope-looking request is within the mandate? And how should a refusal be evidenced so the other parties can verify it later? Any guidance on cross-organisation delegation, or a financial-services use case for the NCCoE project, would be very welcome.

Is there any plan to provide guidance on implementation of authentication workflows with x.509 derived credentials? Many AI systems/Agents need to call tools, databases, or external APIs. In best practice, the runtime should use a short-lived identity instead of keeping a long-lived API key in its configuration. For example, OpenAI documents exchanging a SPIFFE JWT-SVID for a short-lived OpenAI access token.

Thank you for publishing these. Two observations from someone who worked on commercial DNS in the NSFNET era and then spent two decades in enterprise IAM.

First, on Murray Clode’s cross-organisation question (a consumer’s agent asking a bank to act): the receiving party’s problem is identical to the one the early web solved with a neutral namespace. The bank cannot inspect the agent’s harness, but it can verify a signed mandate chain from the agent back to a root human authority if that chain is anchored in a registry no single vendor controls. Tenet 02’s attenuation rule only helps the receiver when the parent’s authority is itself verifiable from outside the issuing platform. Without a neutral anchor, each large platform will issue its own agent identities and portability dies at the first boundary.

Second, on tenet 04: revocation should be evidenced independently of the agent’s cooperation. A receipt that proves “this agent’s authority was revoked at time T, and a later request was refused” belongs in the tenet 10 evidence chain, so the human principal can demonstrate they pulled the plug even if the agent is compromised or still running.

Both would strengthen the consumer-facing case you flag in tenet 02.

Thank you for putting these forward. Two questions worth looking at further are:

1. What would the framework look like to restrict agents from accessing separate systems that don't fundamentally meet certain minimum standards to preserve minimum levels of security?

2. How tenet 10 is accomplished when there is no enterprise involved to enforce those standards (for example, certain open source agents created by individuals), and whether immutable is akin to accessible?

An insightful perspective on the growing importance of agent identity management in modern cybersecurity frameworks. At TECHOM Systems, we recognize that as AI agents, automated systems, and machine identities become more prevalent, organizations must adopt strong identity governance, authentication, and access control practices to maintain security and trust. Designing identity management systems with scalability, accountability, and security at their core is essential for reducing cyber risks and supporting responsible innovation. Thanks for sharing valuable guidance on this critical aspect of the future digital ecosystem.

These are important tenets, particularly distinct cryptographically verifiable agent identities, cryptographic linking, architectural separation of policy from reasoning, deterministic enforcement, and immutable evidence.

One additional architectural requirement becomes critical when these tenets are applied beyond a single administrative domain: Agentic Knowledge Isolation.

Economically meaningful agents will routinely operate across personal, organizational, infrastructure, jurisdictional, and international boundaries. If an agent’s identity, keys, execution, credentials, and protected knowledge ultimately depend on the administrative domain in which it operates, the agent inherits that domain’s trust boundary, including its privileged operators and infrastructure. Those dependencies then become part of every relying party’s trust decision and accumulate as agents compose across organizations and digital supply chains.

A trustworthy Agentic Internet therefore requires agents to have their own cryptographically rooted trust boundaries, with identity, authority, verified execution, provenance, information, and actions cryptographically linked and independently verifiable across domains. The agent’s sensitive knowledge must remain isolated within that same verified boundary, rather than becoming accessible to each infrastructure provider or administrative domain it traverses.

At Hushmesh, we have implemented this model across humans, organizations, agents, workloads and AI models. The result is a common trust model that can extend across entire ecosystems while minimizing required trust, privileged-insider exposure, and attack surface.

We believe cross-domain verifiability and Agentic Knowledge Isolation should be explicit requirements as these tenets move into NCCoE demonstrations.

With regard to #8, I believe that authentication itself should best be thought of as being a confidence score rather that a binary yes/no, particularly as we enter an age when it is becoming less and less possible to distinguish between a human access and that of a software agent claiming to be acting on behalf of that human.

Thank you for distilling these well-considered tenets. Three clarifications would strengthen their treatment of identity continuity, accountability and historical evidence.
On tenet 01, an agent's persistent identity should be distinguished from its credentials and runtime instances. Credentials rotate, and workloads, environments and approved configurations can change. A logical agent should have one persistent identity to which its credentials and deployment-specific identities are verifiably linked. The identity model should distinguish changes that preserve that identity from those that create a new agent.
On tenet 02, the task authorizer, agent operator and entity accepting accountability may be different parties. A signed mandate can evidence delegated intent without necessarily establishing who accepted accountability for the agent. In Murray Clode's bank example, the receiver needs to verify that acceptance, not infer it from the mandate issuer or hosting platform. Shared trust infrastructure should support verification across organizational boundaries without requiring bespoke identity integrations between counterparties.
On tenet 10, historical evidence should remain verifiable after credential rotation, expiry or agent retirement, without requiring the agent to remain online. A later reviewer should be able to establish which agent acted and who accepted accountability at the time. Current validity and historical attribution are separate questions. Evidence should cover what the agent creates as well as what it does, including code, documents, messages and specific artifact versions. An identifier attached to an artifact does not prove provenance; evidence must bind the artifact to its producer. Evidence of denied or out-of-scope attempts should preserve any attribution established at the time.
For the NCCoE demonstrations, the accompanying assessment should state what the evidence establishes, what verification relies on, and which claims remain unsupported. "Not established" is a useful answer.